2008/1/22, Eelco Hillenius <[EMAIL PROTECTED]>: > On Jan 21, 2008 4:48 PM, James Carman <[EMAIL PROTECTED]> wrote: > > Eelco, > > > > I will take a look at it, but I'm not big on Groovy or Grails. I decided > > to write the Wails framework as an exercise in learning Wicket and if it > > turned out to be something folks might like, then they could feel free to do > > so. I was somewhat active in the Tapestry (4.x versions) community for a > > while and Wicket has interested me for quite some time.
I'm in the same spot, looking to learn more wicket (groovy - not so much). It would be fun to try to collect some editors (and in my case read-only displays) for specific classes. I guess that it would be a good idea to try to narrow that scope a bit. What I am after is in the end two applications, one "delivery"-side which is the site with published content. The other is the administrative site where you publish content. So far nothing special apart from that the look and feel should be consistent for display and editor components. I would like to have a registry of editors and display-components. The framework selects which editor or display to use based on the type of content. I guess this is where you actually get some benefit from such a framework. The dynamic selection of components based on type information. For my case it is enough to register editors with a key based on a java class at application start up. I guess that James might have another tack on how this should work (I haven't looked at Trails that much). Also, I would be perfectly happy to have a specific java class hierarchy representing the domain (perhaps rooted in some interface like 'Content' and ' PersistentContent'. I guess this is a bit different scope from Wails and stuff like Wicket Web Beans (http://wicketwebbeans.sourceforge.net/) So, to narrow the scope, I'm interested in creating a Component that looks at some (request) parameter to decide which content to look up in a backing store. It would select an appropriate editor or display based on the type of content. The editors should have a (somewhat) consistent Look and Feel. Judging from this mailing list there seems to be other people working on CMS-like frameworks. Perhaps others (apart from me and Mr. Carman) might be interested in something like this also? Cheers, Johan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
