My concept for ticket #2602 was not to provide total API backwards compatibility. With things like the HDF objects, the rough mechanism is the frontend would check what system the plugin wanted (via a variable or method), and if the value is 'clearsilver' it would pass the request object to something like ClearsilverPlugin.populate_req. This would allow each templating system to maintain its own variables for rendering.
--Noah On Wednesday 18 January 2006 01:05 pm, Matthew Good wrote: > On Wed, 2006-01-18 at 08:23 -0800, John Hampton wrote: > > Emmanuel Blot wrote: > > >> (Moving to the other list:) Was a decision made on what template > > >> language? > > > > > > Yes: > > > http://projects.edgewall.com/trac/milestone/0.11 > > > > > > Kid has been chosen. > > > > I know someone mentioned it in #trac (mgood?) but would something like > > buffet (http://projects.dowski.com/projects/buffet) be feasible? > > Coderanger brought up the topic and entered ticket #2602 for it, but > this will need some discussion. I mentioned Buffet earlier, though it > would be better to work directly with this spec from TurboGears (which > Buffet implements): > http://www.turbogears.org/docs/plugins/template.html > > Ticket #2602 seems to focus on backwards compatibility, which is > actually a more complicated issue than providing a pluggable templating > system. Refactoring the template system would get rid of the HDF data > structure used by ClearSilver, which would be an API change that would > break current plugins, so the templates are not the only problem here. > It may be possible to create a compatibility layer for old plugins, > though it's hard to tell what this will require. > > I'm still not sure how beneficial it would be to provide a pluggable > templating system, since this will certainly complicate things if a > bunch of plugins choose different templating engines requiring users to > install each one for the plugins they choose. > > Part of the hope with a template engine like Kid is that since it for > manipulation of the DOM it would be possible to provide more flexible > ways for plugins to insert different pieces of the UI. Trying to add > this flexibility in a way that would support many different template > systems could also add a lot of complexity and confusion. > > I've also experimented with Nevow's Stan templates recently, which are > interesting though there are parts of it that are still a little > uncomfortable. I'm not sure if there are some tricks that I haven't > discovered yet, or if some of these limitations are more inherent to the > library. _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
