I agree with Michael. The component-oriented approach is in no way that I can see incompatible with the action-oriented model of things.
In fact, grafting at least the basics of a component model onto Struts wouldn't even be especially difficult. Especially with Struts 1.3, adding a command or two into the processing chain to reconstitute a component tree stored in session, and then rendering its HTML in response to a given tag being encountered on the page isn't even especially difficult, and it's not even particularly new or exciting. Then it isn't much more than creating an interface for a "component" to implement, and writing the code to make sure you get the correct components on a given page with the correct state. Frankly, an enterprising person or two could create a rather robust component model layer on top of Struts without losing anything Struts gives you now. Michael has already shown in practice that it's possible. Oh, wait, that's basically what the Struts JSF integration library is, no?!? :) As long as you like the way JSF has done it, there you go! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Mon, December 5, 2005 1:19 pm, Michael Jouravlev said: > On 12/5/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote: >> There are two web application architecture out there co-existing and >> competing >> >> 1) Component-Oriented >> >> 2) Action-Oriented >> >> >> If you can bridge these two then you're probably onto a winner, but it >> is >> very unlikely > > Depends on your definition of component. If you can agree with the > following definition... > > "A web component can be defined as a stateful server-side object that: > * handles client events and input data, > * renders itself according to its state, > * has a certain lifecycle, > * can be embedded into a composite portal-like page" > > ...then components can be easily built on top of existing Struts 1.2.x > codebase. Check out this link (all you need is the first page): > http://www.superinterface.com/mailreadercmp/HomeAggregate.do > The description of what is happening there is here: > http://marc.theaimsgroup.com/?l=struts-user&m=113331626504668&w=2 > > BTW, this approach works really well with coarse-grained AJAX, when > the component's view is [re]rendered using separate request. I prefer > to call this coarse-grained component rendering as Reloadable Page > Fragments (RPF), because they differ from Ajax-only IPU (In-place > updating). The component code for AJAX and non-AJAX is the same. > > Michael. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
