>From what I know about template/CSS writers, we always need custom HTML. Defaults are never good enough, even for small HTML parts like the login form element. In my current bundles, templates are just examples, designed to be completely overwritten at application level.
We could provide more granular partials to make small parts reusable, yes. For some bundles it may make sense. On Oct 20, 1:38 pm, Lukas Kahwe Smith <[email protected]> wrote: > On 20.10.2010, at 12:14, Fabien Potencier wrote: > > > > > > > > > > > On 10/20/10 11:40 AM, Lukas Kahwe Smith wrote: > >> Hi, > > >> Bundle best practices for templates : > >> ------------------------------------------------- > > >> So we are looking at making use of DoctrineUserBundle, but feel like > >> there is a bit of work to do in order to make the default controller > >> and templates. > > >> First up by copying the default templates over into my Application > >> dir, I can overload templates. However for this to be useful, it > >> would be a good idea to separate extends from the rest. For example: > >>http://github.com/knplabs/DoctrineUserBundle/blob/master/Resources/vi... > > > A template can use a layout (to be able to reuse things), but it must not > > extend a layout that defines the main HTML structure. > > > For this specific case, and probably for many more, I think the bundle > > should not provide a default template. It should provide a way to configure > > the template you want to use instead and perhaps provide a small example of > > a simple template in the documentation (to show the mandatory fields, > > names, ...). We can also imagine that a command can generate this default > > simple template in one of your bundle to get you started faster. That way, > > it's up to the end-user to cook the HTML the way he wants. > > well i think in many cases you want to totally customize things. then again > with the form framework and css and css based javascript event attachment, in > many cases you can make due with default templates just fine. > > since you can easily overload templates by copying the structure in your > application directory, i am not sure if we really need configurable template > names. seems like it just adds a lot of work to Bundle authors. but what is > important imho, and which you seem to agree with, is that one needs to split > things up in sensible "units" that you can easily pick and choose what you > want to use. > > so the above template should for example be more like (again not yet 100% > familiar with the macro system, but this could be useful here i guess): > > {% extends "DoctrineUserBundle::layout.twig" %} > > {% block content %} > {# ideally we can easily pass the entire context here > (seehttp://github.com/fabpot/Twig/pull/147) #} > {% include "DoctrineUserBundle:Session:new_form.twig" with ['form' : form] %} > {% endblock content %} > > And then the current content without the extends call would be inside > new_form.twig > > > If the template will be complex to create, the bundle should then provide > > macros, helpers, partials, ... to ease the integration. > > as stated above, ideally we can use some macro's since AFAIK these should be > less overhead than includes? > > regards, > Lukas Kahwe Smith > [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
