>Another area I am not keen with at all with wicket which is mentioned is >having to build the object tree code the same way the html page is. With >element Ids, I am a little confused as to why we cant simply insert the >component using the element id and let wicket figure out where to stick it >on the page. To me, as it scans the html page for wicket ids, it should be >able to pluck wicket component/objects from a Map using the same ID and put >it where it needs to be.
We do exactly what you say with Wicket now (since 1.4.x and with 1.5.x). We have a Wicket based CMS and we really needed to be able to dynamically build pages from components - even at run time (and therefore obviously without restructuring Java object hierarchies and without requiring a rebuild) - just by adjusting HTML. We run Wicket in debug mode in production (breakin' all the rules - but no performance problem is detectable) so that changed HTML files are detected by Wicket and reloaded in the Markup repository. The trick that allows this to occur is a custom implementation of the IComponentResolver interface. Doing this you can daisy chain responsibility for instantiating components from the page, down to the components and then child components - it all works scary well ;) In 1.5 the component resolver is refined to make implementations even easier than 1.4. Regards, Chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
