On Fri, 10 Jan 2003, [UTF-8] Rickard Öberg wrote: > All, > > Since quite a few of you disagreed with my resignation as XWork > architect, I've given some thought to how it would be possible to merge > my requirements with those that you have. It might be possible to do it, > and if so I would reconsider re-starting my work on XWork. I'd like to > begin with defining the core concepts that XWork would have, and also > briefly list my requirements, and see what your thoughts on them are.
As an aside, before I start slicing most of this post out to save space, I'd like to add that I was one of those who wasn't happy with that decision. I'd also like to say that THE most important thing that can be done at that stage is THIS EMAIL - which actually goes down the road of defining requirements and scope. I was going to post these to the wiki, but the wiki's not up for me at the moment. > The core concepts that I think must be included are the following: [SNIP!] I agree with these. All very nice. I'm still trying to figure out configuration on my own just to see what *I* think, but I'm not getting anywhere with it enough for my own satisfaction. > These are the core concepts that I can think of. Now, for my own > portlet-ish needs (which I hope will be more common for others too in > the future) the following applies: > * Actions and Components, and their resulting views, are ALWAYS called > through a servlet include. This means that the URL in a browser NEVER > reveals that XWork is used. For example, an admin app would consist of Perfect for a portlet - less perfect for other things. Are you saying that XWork will *disallow* direct invocation? An XWork page will be invoked via a .jsp (for example), and call the dispatcher, which will call ANOTHER .jsp for view, which might include many form components? This isn't a show-stopper, mind you, but might be something to go softer on. > the CardPane works in WebWork. Essentially, XWork would include this > kind of state machine as a built-in concept instead of as an "add-on" > like CardPane, since this is such an important and common case. It needs > to be as simple and flexible as is possible. When a component renders > its view it also creates URL's that define what the possible next states > are. This means that the URL's in the generated HTML are shortlived > (i.e. after one of the URL's have been clicked they are all invalid), I *dribble* on this idea. (That's good.) I'd like to see how it works, still - does this force session state on an application? (Is this a new thing, to force session on an application?) > * The execution of a Component (and maybe Action's too) needs to be > split into two phases. The actual execution of an action is done at the > *beginning* of a page render, and the rendering is done at the time of > the include. Why? Because the action may influence what is shown on the > page, and may also result in a redirect to another page. If the action > execution is done at the point of the include it's too late to do a > redirect, and other portlets may have rendered state that is then > changed by the action execution. (This thinking, by coincidence, mirrors > well how the portlet API will work) I thought this was normal for webwork. Ah, I see the problem - this is related to the "actions are only included" statement above. > * When rendering URL's, the parameters need to be namespace'd in order > to allow several portlets to happily live together on a page. I.e. > instead of having ?foo=bar one could have ?1.foo=bar&2.foo=bar. The > XWork servlet dispatcher would then at execution filter out those > parameters which does not apply to the action/component/portlet being > executed, and only the remaining parameters are applied using the setX() > initialization code. This requires the rendering code to use either a > taglib (in JSP) or some JavaBean (in Velocity) which can do this > encoding. I know that for *some* applications this will be overkill, but > for those of use who are going beyond very simple web apps it is a > definitive must. And here, we're back to webapps. Is there any way to architect this so that it's not bound to the web? > Off the top of my head, those are the concepts and requirements I have > in order to be able to use XWork in our portal/CMS application. So, what > do you think? Read above. Excellent stuff. --------------------------------------------------------- Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.com IT Consultant ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
