On Sat, Jan 11, 2003 at 09:29:33AM +0100, Rickard Öberg wrote: > Peter Kelley wrote: > >The other thing we might want to address is > >whether or not XWork will be somewhat seperated at the core from the > >web. > > This is a very difficult question. Separating it from the javax.servlet > API should be possible, but overall I have the feeling that trying to > make a *too* generic solution might be crippling. > > A little poll: > *) How many have actions that are used with more than one kind of > dispatcher? > *) How many are using WebWork in Swing apps? > *) How many are using WebWork for RPC style stuff? (the > ClientServletDispatcher and friends)
I'll use xwork for "classic" web apps, not portlet style like Rickard does. Additionally I'll use it for RPC style stuff, mainly automatic Mail handling. I admit that the latter will only be used by a minority of the current user base. But let me describe the experiences with my home grown action framework i made in ruby. The core framework is seperated from any web stuff. It has the concept of actions, dispatchers and views. Interceptors are not supported, I didn't have the need to. The Who is who in my framework: Action behaves like in webwork: execute() is called by the dispatcher and returns an object describing the view. Dispatchers are the bridge between the execution environment (e.g. CGI or eMail) and the actions. The dispatcher handle an incoming request, determines which action the execute, extracts the request parameters from the environment and passes them to the action, then it prepeares the right view depending on the result of Action.execute() and tells the view to execute(). View defines a methods execute(Action result) and get all necessary objects from a ViewContext set up by the dispatcher. For the CGI dispatcher, this would be the output stream, for the MailDispatcher the sender of the mail and the mailserver settings. Additionally, I have a bunch of helper classes, that render Action results to an output stream: a XSLT-Renderer and a Regex-Rendere, e.g., whose main method is Renderer(Stream stream, Action action). Theese renderes are used by the Views. >From my experience, this separation leeds to very clean a implementation of the actions, views and dispatchers. As a conclusion I request to keep on working on keeping the core xwork framework separated from the Servlet environment. Based on my ruby work I can tell that this means insignificant additional cost, leeds to cleaner design, makes xwork more useable and does not affect the developer who uses xwork in a sole servlet environment. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 ------------------------------------------------------- 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
