I am starting a new project using Symfony2. I am adding some basic twig templates like my CSS template (with assetic to trigger sass -- nifty) and my header/footer template. My question is, should this sort of thing go into app/Resources or into Acme/MainBundle/Resources?
I am sure I can do either if I really wanted to, but I'd like to know what the correct way to do it is.
app
Resources
<A. here?>
src
Acme
MainBundle
Resources
<or B. here?>
It's really a matter of preference. I tend to keep global views in app/Resources. Does your MainBundle contain anything else besides views? If not, I think that's more reason to use app/Resources and avoid unnecessary bundle pollution.
Related
The directory structure for bundles specifies that views should be stored in <your-bundle>/Resources/views. But then the best practices for template locations says that, actually, I should store them in app/Resources/views. I can see the conveniences of doing the latter, but I don't understand:
If I am organizing things into bundles, aren't I reducing the bundles' portability by "de-bundling" the views?
The examples show that index.html.twig is easier to write than AcmeDemoBundle::index.html.twig, but what if I also have FooBundle::index.html.twig? I still need a way to specify which index.html.twig I want, right?
The documentation is correct. Store reusable bundle's templates in <your-bundle>/Resources/views and your project's templates in app/Resources/views. There is no conflict.
If you decide to create a bundle make sure it can be reused (that's the main purpose of the bundle). Otherwise keep using your AppBundle. AppBundle will not have two /index.html.twig's.
While we are using Assetic with Twig templating, we want to delay the actual processing until the last moment for various reasons. So instead of using the javascripts, css tags of assetic we created something like this
{{ add_asset (['public/js/prototype-handler.js', 'public/js/shipping-method.js'], 'js') }}
Anyhow, the idea is that at the end of the response event we will process and inject all assets to the content. However, right now I'm stuck at how to add these assets to assetic so they can be processed and returned with the result file(s).
I have checked some other bundles and what they are doing right now is to render the assets via twig like this:
AssetManagementBundle
However, it doesn't seem to be an optimal approach to this. I wonder if there is a better way or not?
For people who may encounter this same need, you want to use createAsset of the AssetFactory.
Then you can loop through the created assets and do what you want with them.
For more information and working code, please check our bundle here
I'm not sure to completely understand your needs but you could be interested by the AsseticInjectorBundle, it allows you to tag your resources files in a configuration file and add it by adding the tag where you want in your assetic markup, in your layout.
I don't think dealing with resources in php is a great idea and it's better to do this directly in your layout coupled with some configuration file.
Regarding ASP.NET 4.5's new System.Web.Optimization / Microsoft.AspNet.Web.Optimization:
Can anyone explain the difference in the use of bundling resources using the BundleConfig.cs class file as opposed to the bundle.config xml file?
I've seen some articles showing bundling both js and css in BundleConfig.cs, while others showing bundling js in BundleConfig.cs and css in bundle.config.
I guess I don't understand #1) why you wouldn't just do them both one particular way for simplicity - and #2) why anyone would prefer to hard-code resources like that in a class file? It seems like a much more dynamic approach to just put them in an xml file that can be changed on-the-fly if necessary.
It seems like more articles actually lean toward using BundleConfig.cs than anything else. Is there some particular pro or con that encourages this?
Also, if there is any real documentation on System.Web.Optimization, I would love to know the location (because I sure can't find it).
Thanks-
As far as I can tell, the accepted answer doesn't actually answer the question at all. It discusses the benefits of the bundling framework, but not how using the BundleConfig.cs is different than using the bundle.config file.
A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.
For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.
However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.
My personal philosophy is to use bundle.config unless I need to do something with the bundle that's not possible that way. However, I do agree that having them all in one place is ideal. If I decide I need to use the class, then I'll use that for all of my bundles of that type (I do sometimes put my JS bundles in the class and my CSS bundles in the .config file, though). I'm sure some completely reasonable people would disagree with that process, though.
this documentation explains it all better than I ever could
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
One of the nicest things is this:
The bundling framework follows several common conventions such as:
Selecting “.min” file for release when “FileX.min.js” and “FileX.js”
exist.
Selecting the non “.min” version for debug. Ignoring “-vsdoc”
files (such as jquery-1.7.1-vsdoc.js), which are used only by
IntelliSense.
Can anyone explain the difference in the use of bundling resources
using the BundleConfig.cs class file as opposed to the bundle.config
xml file?
The difference is that you would have to read, parse and load the content of the bundle.config at runtime. Hence, using BundleConfig.cs class file could be simpler.
1) why you wouldn't just do them both one particular way for simplicity
Totally agree.
2) why anyone would prefer to hard-code resources like that in a class file?
Simply put: easy to understand.
It seems like a much more dynamic approach to just put them in an xml
file that can be changed on-the-fly if necessary.
Yes, but you have to write more code to detect when changes happen and then add/remove/replace existing setup. If done poorly, it could lead to UI issues at runtime.
Also, if there is any real documentation on System.Web.Optimization, I
would love to know the location (because I sure can't find it).
Already answered above, but I would repeat: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
I'm (still) a beginner with Symfony and have been reading about three-level inheritance with Twig.
If you define blocks in your bundle their names might be bundle specific and not match block names defined in your app base.html.twig or other bundles, or even the names could be the same but the usage could be different.
Has anyone found this to be a problem?
Are there ways to manage this, will overriding templates under app/ help?
Are there any conventions for block names or anything else that will minimise maintenance problems?
Block names should have some sort of relation to whats going to place within the block. so if you have css styles within a block you would call it Stylesheets, and for javascript files call it JavaScript. As far bundles, create a layout.html.twig within the views folder and extend the base.html.twig.
I want to make an application based on a main bundle leaving the possibility for other developers to make their own bundles to implement other features.
Symfony 2.0 seems a good choice for that however I cannot figure out how to let the bundles to work together while preserving the decoupling.
In the MainBundle I will create a Controller which generates a Users-List like the one below:
user1 edit remove
user2 edit remove
....
How to let third-parties bundles to add their custom buttons to this list?
For example an AvatarBundle may want to add a button to upload of the Image, a SendEmailBundle my want to add a button to send an email to the user and so on.
How to preserve the bundle independency? How can I do that?
Thanks a lot,
Massimo
As far as I know, there are only two ways of changing/adding functionality in provided bundles.
Change the code
Overriding the template/controller
In this case, the second seems far preferable.
The ways to override a template are:
Define a new template in app/Resources
Create a child bundle and override the template
If you also want the override controllers, the second way is the only way to go.
It's also my personal preference, since it's cleaner then putting specific stuff in the general app-folder, in my opinion.
Anyway, it is far better explained in the documentation of the FOSUserBundle:
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/overriding_templates.md
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/overriding_controllers.md
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/overriding_forms.md
And ofcourse, this cookbook article:
http://symfony.com/doc/current/cookbook/bundles/inheritance.html
Hope this helps,
Dieter
If you know which parts of your bundle will be extended, you can use services (in the same way the tiwg bundle is using them for adding new templating filters/tags/helpers).
Your bundle will then 'scan' the services defined in the DIC (which have a defined tag) and then call them to get informations (button definitions in your case).