Brian Kirkbride wrote: > Thomas Klausner wrote: >> Hi! >> >> On Wed, Mar 21, 2007 at 04:47:15PM -0400, Christopher H. Laco wrote: >> >>> Or more to the point... have app supplied templates, and be able to user >>> user customized templates in combination with the app >>> templates...without have to worry about sources, merging, upgrade, >>> etc... >> >> I usually (using TT) do something like: >> >> INCLUDE_PATH: [base_framework_stuff app_stuff] >> >> All the templates go into base_framework_stuff >> All modifications needed for an app (or maybe even a sub-area of an >> app) go into app_stuff. >> >> You just need to break your templates into enough smallish components. >> In the end, it feels a lot like OO templates, where you can "override" >> the "base implementation". >> > > > I'm glad to see someone else doing this! I've found it works well for > my projects and does feel very "OO" indeed. As Thomas said, it is > mostly about finding the right granularity. Not so small as to make it > hard to understand a template's function at a glance, but small enough > that an override wouldn't step on something you plan to update in a new > revision.
Plus, it's an incentive to keep templates small and sane. It it's hard to use your /template/foo instead of /base/template/foo ... then I guess that's a good pointer to something being wrong. THe only part of that that feels dirty is that it's still an either-or situation, rather than an base_mine situation. That could be solved by TT plugins, but that's nasty at some level. -=Chris =-Chris
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/