Matthias Wessendorf wrote:
Werner,
thanks for your feedback, During the weekend I'll look more at that.
Yes the putting the ui component to the context is fine. thanks (was
late... ;))
I'll keep you updated for *news* on that.
Yes really neat stuff.. as I said I have used Velocity based techniques
in two old projects in my last company
(one being a portal which was sitting on top of apache jetspeed which
used velocity, the other one a mini end user wiki/cms which used turbine
, the base of jetspeed and velocity)
We got pretty good results renderingspeedwise, but the main difference
was, we used Velocity as a page render mechanism and basically used
Velocity macros for the componentization.
The speed of this was excellent, but the main difference I see here is
that you basically have to go through a load render cycle basically for
every Velocity based component in the form, which might become
problematic in the long run because Velocity does a lot in the backend.
So a speedtest might be necessary before you follow the route extensively.
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.
Werner
