I'm starting with Symfony 3.4.4 + SonataAdmin Bundle.
Everything works correctly for me.
I already have entities generated and in the integration of entities within SonataAdmin bundle by means of "php bin/console sonata:admin:generate" entities are generated in "src/AppBundle/Resources/config/services.yml
And that file is not integrated into my bundle.
I have read that using Dependency Injection is the most correct way to load that file, but I do not know how it is done.
Can someone explain to me how to install dependency injection and that this file be loaded correctly by means of the "good practices" of symfony?
I think you are confusing something.
Dependency injection is a principle in software development to decouple a classes dependency from other classes by not setting properties inside a class directly. Instead you give it for example to the constructor or set it afterwards by a public setter method. With this your classes are replaceable and thats beneficial especially for testing your source code.
So you cant install a software development principle.
And your entities are not generated in your services.yml. Your services are defined here and your entities normally going to src/AppBundle/Entity.
Symfony/Sonata is using dependency injection by defining services in the services.yml and telling them, which parameters they will get.
For example
services:
mailer:
class: Mailer
arguments: ['%mailer.transport%']
Here the mailer.transport parameter will be injected to the Mailers class constructor.
There are many yml files in your app/config folder, but the all are united in the config.yml
So if you have no instruction like
- { resource: "#AppBundle/Resources/config/services.yml" }
in your app/config/config.yml your services will never be loaded.
Related
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.
I am currently working on creating a web service using Spring -WS.
I want to make the request reach my own Message Dispatcher Class. So I made the necessary configuration changes to web.xml and also my sping-congfig.xml file.
I am seeing an error when spring loads beans for my Message Dispatcher,
it tries to look for a properties file in my package which has the Dispatcher Class. for Example if my class is AccountMessageDispatcher, it looks for AccountMessageDispatcher.properties file in the package where I have created the class, I can get it running by keeping the properties file there, but I want to keep the properties file under my resources directory which has other property files needed by my application.
Can any one help me or point me in the right direction as to what I am doing wrong?
If we take a look to the default MessageDispatcher infrastructure, we'll that it reads appropriate proerties file - org.springframework.ws.server.MessageDispatcher.properties.
As you see this file is located at the same package as the original MessageDispatcher class.
According to your concern, you are right: that file should be located at the resources dir for sources. But if you use normal build system like Maven or Gradle, all your resources are packaged to the target jar alongside with classes.
To achieve your requirements you just need to create the same dir tree in the resources as your original AccountMessageDispatcher.
Actually any Java package is a dir in the end jar.
In my grails 1.3.7 project, I have put all of my classes in com.mycompany.myapp, as you do. So this goes for services, controllers, domain classes. I have a filter that goes in its own package. My app works fine.
However, when I run grails doc, grails decides to create two pages for every class:
one in its right comp.mycompany.myapp package that has all the right Groovy Doc
the other takes all the above classes and pretends as if those also live in the default package.
So, target/docs contains two directories: 'DefaultPackage' and 'com', with DefaultPackage holding a copy of everything that lives under com/
Consequently, my groovy doc looks messy because there is two copies for each class.
How can I solve this?
It has been documented as a bug at GRAILS-6605. There is no workaround listed there for the bug.
I too faced the same issue and so created a plugin "Grails Runtime Docs" ( http://grails.org/plugin/grails-runtime-docs ) that solves this issue and generates both Java and groovy docs properly only 1 copy per class. It's grails aware and categorizes the classes into Controllers, Commands, Domains, Services and Tag Libraries. The groovy documentation is actually generated from runtime so as to include the dynamic methods also, adding "Dynamic Method Summary" & "Dynamic Method Detail" in the generated html docs, that provide their source information. Hope you find it useful.
I am developing a Grails application (with Grails 1.3.7). In service layer, I did not use the command 'create-service' to create my service but do it manually.
As the result, my service was not auto initialize in controllers and other services, and it did not handle transaction.
But I do not know where is the differences from create service by command with by manual? Because I do not see any configuration file which figure out this? (I mean in traditional Spring, we always have some configuration files which specify all beans in applications, but in Grails is not).
I want to fix this issue and commit to SVN server my fix, but I do not want to delete the old service and commit the new one which is created by Grails command. So could you please help me:
1. explain what is the differences from create service by command with by manual?
2. how to change the the service created by manual to service created by command without replacing the old one?
Thank you so much!
explain what is the differences from create service by command with by manual?
Assuming you put your service in grails-app/services and followed the naming convention using a postfix of Service The only difference is that you get a nice template that looks like
class SomeService {
boolean transactional = true
def someMethod() {
}
}
and it automatically creates a unit test with the name SomeServiceTests. That is it. BTW transactional defaults to true if you do not include it.
how to change the the service created by manual to service created by command without replacing the old one?
There is nothing to do assuming you followed the conventions. If you did follow the conventions and you are still experience problems please update your question with more details such as how are you trying to use your service and a example of your service.
As long as you put your class in the grails-app/services directory, it should act just like any other service (and work as a spring bean).
If you put it in src/java or src/groovy, it's not considered a service (and not loaded as a service artefact by grails). It could still be a spring bean, but you'd have to manually add it to the resources.groovy file.
Also note that the Grails autowiring of the beans must be exact, so if you have MyService and you want to use it in the controller, make sure you have "def myService" or "MyService myService." If you would prefer different names of your member variables, you can also use the Spring Autowired annotation directly, though I've only tried autowiring grails types (e.g. a grails service) autowired to a bean I declared in resources.xml
If you put services, or any other bean in the resources.xml or resources.groovy files, they will also be autowired intro controllers, other services, etc.
It's best to think of Grails as "rapid Spring", so the autowiring, transactions, etc all are backed by Spring configuration and such.
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?