On the contrary - I think it is highly relevant to this thread. In fact, the component tree should be built in the same way as each component is built up. Isn't a component in itself something like a tree?
There are three approaches which seem to make sense here: - doing an XML like thing different from the JSP world (a.k. Shale Clay) - doing an XML like thing very similar to the JSP world (a.k. Facelets) - use velocity, a known and loved template language if we use velocity though, we should also use velocity to build up the component tree! regards, Martin On 7/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I was thinking about maybe using the "Facelet" approach for the > > component creation as well - this is basically exact the same stuff as > > defining the components by using JSP. I don't know how to do loops and > > stuff like that then, though... > > The Clay component under Shale is another example of using an alternative > method of adding components to the component tree. There is an example in > the uses cases for using xml and runtime composition. An HTML layout use > case is coming soon. > > I originally had considered Velocity integration. The concern that I had was > that if you could not create JSF components and associated listeners, > converters and validators, you really only have a sophisticated outputText > component and your really missing out on allot of what JSF has to offer over > Velocity. > > The approach that I was taking was to merge a document using Velocity and > reparse it building a JSF component tree. Craig was not comfortable with > this dual processing and David ended up steering us to the Tapestry like > views. > > Not that it's directly relevant to this thread…. but I thought I would share > our experience. > > Gary > > > > > > regards, > > > > Martin > > > > > > > > On 7/6/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > Werner, > > > > > > > One thing I could see with your approach would be a generalized velocity > > > > renderer, which checks if the component has the binding attribute > > > > template and then it loads the template from that attribute and > > > > pushes the component in... > > > > that way you dont even have to define anything in the renderer at all, > > > > just the tags, the component which is bound to the velo renderer and the > > > > template which has to be put into the velo search path... > > > > That would make things much much easier for the component implementors > > > > for non compound components. > > > > > > > > > yes I was think of something like a *velocity renderer framework*, > > > since my 10 minutes test/play was fine ;) > > > > > > Thanks for your feedback and on problems I'll let you know ;) > > > > > > -Matthias > > > > > > > Werner > > > > > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > >
