On Mon, 30 Dec 2002, [UTF-8] Rickard Ă–berg wrote: > Joseph Ottinger wrote: > >>* Validation. Clunky design, and not enough loosely coupled to the action. > > > > I personally *like* how webwork currently handles validation. This is one > > of Struts' weakest points, and webwork's solution rocks. How would you > > suggest it be done? > > There needs to be a way to separate the validation from the action, so > that different validation rules can be applied to an action, and also > implemented with different strategies (using formproc or regexps or > whatever).
Well, Struts has a separate validation step, and it SUCKS. You can use whatever validation mechanism you want in the form beans, and it's retarded. Webwork's lifecycle validation needs documentation, and since it's a simple method (that relies on side-effects) it's trivial to use. Maybe the side-effect issue could be fixed - and the return value could be customized. But honestly, the approach is right. IMHO. > >>* Chaining. IMHO this needs a big rethink, and most of all we need to > >>check: what are the usecases to be implemented. > > > > Hmm... Having looked at an enterprise-scalable chaining mechanism myself, > > I'm not sure webwork's chaining is that bad. The only aspect to it that's > > inobvious is still the VS being available, and that's a documentation > > issue, not a code issue. Again: what issues make it need a rethink? > > Not quite sure yet. It just feels wrong. I think there needs to be a > separation between the action being executed and the side-effects of > that action (and the examples I've seen so far indicate that this is > what chaining is used for mostly). Somewhat like the separation of > servlets and servlet filters. This would tie in with the interceptor > handling too. I'll wait for more on this. I really don't like the idea of webwork focusing more on doing it "correctly" than "doing it" - webwork's trivial to use and very clear once you grok it's mindset. > >>* View code. The old taglib contained code that was to some extent > >>duplicated for the Velocity view. This needs to be refactored so that > >>views can share such implementations. > > > > Grr, I ask and ask and ask, and you never give me what I want. > > You mean you ask for the above, or..? I was saying I agreed with you. That's what I was bringing up when I was talking about formtags being refactored to be more WW-friendly - abstracting everything out so that the "tags" were reusable in different view technologies. > >>These are the major things I think. Any comments on this? Any other part > >>that needs a rethink? > > > > I'd like to make sure the client code is not bound to the servlet > > lifecycle - by writing a Swing client, for example, or AWT (in my case.) > > Not sure what you mean... can you expand? We have a huge client app in > Swing that uses WW actions through the ClientServletDispatcher. So it doesn't require a servlet engine at all? Docs, docs, docs. --------------------------------------------------------- Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.com IT Consultant ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
