> Sorry, looks like we have all misunderstood what you meant. not hard to misunderstood things in this threat
> > So you also recommend that a uicomponent should contain any "business > logic" specific to that component, and that the renderer just contain > the "presentation logic"? But in that case, many uicomponent classes > will have code in them that differs from other uicomponent classes and > cannot be auto-generated, so this also means that a "template" will have perhaps Trinidad is a bit different than Tomahawk. In Trinidad all components (and their renderers) follow the same development line. Easy to group etc. Not checked Tomahawk since years, but I think that the comps there are a bit different (even in case they might have some common lines to share). > more stuff in it, and need to be more often debugged, ie that the > suckiness level of generating uicomponent classes again goes up. I see that in some cases it might be the case, that you need (to many) templates. Perhaps a large refactoring is required before moving to a "generator" based approach ? > > I had thought you were recommending simple "dumb" uicomponent classes - > which would indeed be better candidates for code-generation. I provided a simplified example, perhaps that helps. > > What point were you originally wanting to make about the Trinidad > approach? I don't know, what you are referring to ? Perhaps that the plugin (as it is today) is fine for us (Trinidad)? > > Regards, > Simon > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
