I have a symfony application with two different applications (frontend, backend) but there is one action in common. Now I have duplicated its code in both apps but I don't like that at all.
Is there a way to reuse an action in multiple symfony applications?
The easiest way would be to make an actions base class in lib with the shared methods/actions. Then the modules that need to use this functionality can just extend that base class instead of sfActions.
You could also probably just use an event listener on method_not_found of sfComponent. But that may not work as expected if the method is an actual action (and it would also be available in all modules and all components without some special detection logic).
The most complicated way would be to make a Plugin. Of course that would require making the logic that works with any models dynamic so it can be configured or isolating the relevant parts of the schema to the plugin's schema.
Two more options:
1) if your are on Linux, make a symlink to your actions.class.php or even whole module, if you share the same templates.
cd apps/backend/modules/name
ln -s ../../frontend/modules/name name
2) if you have not gone too far in development, re-factor your project to have only ONE application (my favourite).
If you want to share a module (and hence also it's actions), the proper way is to create a plugin.
Related
I am trying to migrate from log4j1 to logj2.
I have a WLS server with two ear files. Ear1.ear and Ear2.ear. Both have similar code and for logging, they use the same logger name. In log4j1, there were two different config files loggingconfigEar1.xml and loggingconfigEar2.xml writing to ear1.log and ear2.log respectively.
I am trying to implement the same in log4j2, but not able to find an easy way out. Is it possible to have two different ears with same logger name have its own individual log files. Right now, I am initialising the config file through the System Property log4j.configurationFile and it does not work.
The only other option that I can think of is, have separate logger names for the two ears. But that would involve code change in quite a few places and I want to have it as a last resort option.
FYI, there was a lot of customisation done for log4j1 which I have avoided in the migration either by scrapping the functionality or by rewriting code. I am not sure how exactly this separate logging was achieved in log4j1.
I would like to write a Zend Framework 2 vendor module, hosted on github, installable via composer and given to the world at large!
Now while I have no problems writing modules, where I am struggling is the mechanics around this.
My initial instinct would be to do something like this:
Set up a zend framework 2 skeleton app
Add my module as a normal module
Navigate to the module folder and create a git repo
Work on the module and update the module to my gitto...
Now logic tells me this is not the right way to go. So I am thinking, maybe I write the module as a stand alone outside of the skeleton app, push to the gito, and then pull from the gito to a working applicaiton...
If you can direct me to a tutorial, please let me know or if you can confirm or deny my proposed thinking that would be great too.
You probably need some app around your module to check if it works, however that shouldn't affect the way you create that module.
When it comes to Zend Framework 2 integrating modules, all you really need is a class that is called SomeNameSpace\Module which must be autoloadable via Composer. Note that there is NO requirement to place this file at a certain location. ZF2 will detect that you are using it with Composer and simply check with class_exists() instead of trying to locate a file, include it and then check for the class.
This class should reveal some configuration info about your module in the way ZF2 expects modules to do this, i.e. add bootstrap event listeners, return configuration data via getConfig() etc. It need not return anything for getAutoloaderConfig(), because that's what Composer is for.
To add the module to the ZF2 application you add the SomeNameSpace name to the file config/application.config.php:
return array(
'modules' => array(
'OtherStuffForTheDemoApp',
'SomeNameSpace' # this enables your module in your demo app
# and anywhere else where it's being used
),
ZF2 will see the module mentioned, try to instantiate SomeNameSpace\Module, ask it about all the configuration you defined, possibly calling the hook functions like onBootstrap() you provided there - and that's about it. Your module is responsible for doing the rest, i.e. provide a service manager configuration, provide controllers etc. All classes are autoloaded by Composer.
I believe the question of how to expose resources like images of a module hasn't been answered by Zend itself - at least I saw these questions being raised, but unanswered in the most current version of the documentation: http://framework.zend.com/manual/current/en/modules/zend.module-manager.intro.html
The organisation of files inside your module is completely up to you, although it seems common practice to place the source in a folder named src, tests probably go into tests.
Background
We have an existing webapp, built with Struts 2 and Freemarker, of which I’ve created a variation by copying some of the code and templates. Kludgy, but manageable. We will however soon be making quite a few other variants (which need to be individual WARs), making copying untenable. My thought is to instead put all the shared stuff into a jar included with each webapp: the common files could be maintained in one place, and even better a given webapp could override files from the classpath. So far I've been able to do this with the code, but the Convention plugin is making it difficult to do the same for the Freemarker templates.
Problem
Thus far our webapp has relied on Convention to find the Freemarker “action results” (i.e. templates) for actions at application start-up, saving us from having to tediously annotate each of them. If I've traced things correctly, the class DefaultResultMapBuilder is responsible for finding the actions results; in particular, the method createFromResources looks in the webapp and then on the classpath for template files matching our actions.
This is exactly what I want – except that we put our templates under /WEB-INF to protect them from outside access (using the struts.convention.result.path constant in our Struts configuration). This has worked fine until now, with ALL template files located under /WEB-INF, but it’s not working with files also on the classpath. DefaultResultMapBuilder can certainly find files on the classpath, but only when webapp templates are under the context root directly, as any classpath templates have to be in a package structure equivalent to the directory structure of templates under the context root. For action results to be found when “struts.convention.result.path" starts with “/WEB-INF/” would require a root package called “web-inf” – but of course hyphens are not allowed in package names.
(Note that this issue is independent of the TemplateLoader classes that are later used to actually grab the template files. The loading process is readily configurable to look in many places – but the app never gets that far if the ‘action results’ are not found at startup. It would be nice if both processes used the same configuration...)
Solutions?
So… I could move all our templates outside of /WEB-INF but really I’d rather not. Or I could provide specific annotations for each action class, and again I’d rather not (and indeed it might suffer from the same issue).
Or I could make my own implementation of ResultMapBuilder by copying and very slightly changing DefaultResultMapBuilder (every member in the latter is private, so I can't extend the class and change just the relevant parts – alas!), and then figure out how to override the "struts-plugin.xml" Struts config file (to change the org.apache.struts2.convention.ResultMapBuilder bean), and thus I could get Convention to ignore "/WEB-INF" when looking on the classpath. Or perhaps better, to always prefix the path with "/WEB-INF/" when looking in the ServletContext.
But maybe there's an easier way? Some undocumented bit of configuration magic?
My idea is that it's much easier to edit related code when it sits in single "work" file. E.g. in Rails application when you implementing some functionality you may edit 1 function per file in the following files: integration test, controller test, controller, model, controller helper. So if it would be possible to 1) mark this code fragments 2) automatically collect them in "work" file 3) edit them togather 4) the tool synchronizes (puts back) the changes; it could simplify development process in many cases. Especially if you need to go through many tweek-and-try iterations.
Vim works fine for this. Install the Rails.vim(1) plugin and with the command :AV you can open a vertical split with the accompanied tests/specs, or :RV to open related files like migrations and views (depending on whether you're viewing model or controller). When you're workspace becomes to cluttered, use :only to go back to one file. Splits are the best way to manage multiple related files IMHO. You can even open the same file twice to see two parts of the same file. It's not exactly the same as you are describing, but it comes close.
1: http://rails.vim.tpope.net/
Just open up Vim and open some windows. What's the problem?
What is the best way to load seed (initial or test) data into grails application. I'm considering 3 options
Putting everything in *BootStrap.groovy files. This is tedious if the domain classes and test data are many.
Write custom functionality to load it through xml. May not be too difficult with the excellent xml support by groovy, but lot of switch statements for different domain classes.
Use Liquibase LoadData api. I see you can load the data fairly easy from csv files.
Choice 3 seems the easiest. But, I'm not familiar with Liquibase. Is it good in this scenario, or only used for migration, db changes etc. If anyone could provide a better sol, or point to an example with Liquibase, it would be great help..
Another answer would be to leverage grails run-script. This would allow you to move what you might put in bootstrap and keep it where you want on your file system (possibly outside of the codebase). Similarly, you could install the console plugin and load code through that on a running application.
Depending on your data needs, check out the great build-test-data plugin as well.
I'm using the Fixtures plugin to load test/initial data, it works for me.
http://www.grails.org/plugin/fixtures
look at http://www.dbunit.org/ and http://www.grails.org/DBUnit+Plugin
look into SeedMe plugin:
https://github.com/bertramdev/seed-me
seed = {
author(meta:[key:'name'], name: 'David', description: 'Author Bio Here')
}
One way I have generated seed data is using a service. I created a class, lets call it SeederService. I can inject this service in the Bootstrap.groovy and call whatever method I would want.
The beauty of SeederService is that you can also use the same service in your unit-tests. Simply inject the service class in your unit test and generate your seed data.