Joe, Yes, the idea is that the developer can just work through the ActionForm beans and not have to deal with the HTTP request directly. The framework provides a way to get at the request and response, but this is for completeness and rarely used.
The aspect of the incoming response is a virtual URI which is registered with the controller. The URI is part of the Action Mapping, which is a Decorator for the Action classes. This lets you reuse the same Action class over and over again by reconfiguring it through the mapping. Ideally, the Actions should not contain any real business logic and should just be used as a "stepping stone". I rarely write "custom" Actions myself, but rely on a set of standard framework Actions which instantiate a business object, pass up the inputs, and pass back the outputs. This can be handled through the Struts config, but a more comprehensive XML application could work much better. Craig in fact proposed such a creature last year -- see the Workflow component in the Commons. I think this would jive well with what you have outlined. -Ted. Joe Cheng wrote: >Wow, what a great response! Thanks for all your thoughtful comments. It's >been very helpful already. > >I can't respond to all the points raised (all excellent ones). But let me >try and jot some thoughts down. > >First of all, I don't mean to imply that there is anything out there that is >better than Struts, nor am I saying I don't see great value in the Struts >framework. The Struts paradigm is certainly among the cleanest I've seen in >web design. And the view-related stuff looks pretty ingenious. > >Secondly, tell me if I have this right. Generally your Action class doesn't >need to get parameters from the response at all. You're just getting values >from an ActionForm, whose values have already been populated and validated. >Is that right? If so, I wasn't aware of that, and that goes a long way >towards satisfying my concern about meaningless methods; since as long as >you're using the correct ActionForm you automatically get some compile-time >type protection. > >Third, let me just put forth what I am building, and set aside the topic of >Struts for a moment. As Craig said, a Web Controller performs the following >functions: > >* Accept a request > >* Convert the input request parameters/cookies/headers/et al to > something your programming language can deal with > >* Based on some aspect of the incoming request, decide what > transaction to perform. > >* Call the appropriate business logic (and if you prefer a > single switch statement with 738 branches, we can stop talking > now ... you'd be considered hopeless :-). > >* Transform the result of performing some business transaction > into a response that either shows the user what happened and/or > sets up their next activity. > >My goal was to be able to do all of this from outside the Java code, leaving >only business logic in Java. Please check out the accompanying XML file... >this is what the "language" looks like. > >The "tagdefs" at the top simply provide a mapping between the tags in the >XML with the Java classes that back them. For most uses you could leave >them as-is. But if you wanted to write your own classes, or rename the >tags, you could do so right there. The only tag that the framework is >coupled to is TargetTag, there is some special handling there. Otherwise, >the rest of the syntax is implemented as plug-ins. > >Each "target" represents a logical URL. The target for a request would be >determined by the request's path_info. > >Within each target, you can declare variables. These variables are strongly >typed (use any Java type) and only exist within the scope of the target, >unless you explicitly save the result to the request, session, or servlet >context. You can populate these variables using any value from request >params, or r/s/sc attributes. I'm envisioning that along with type, you can >also (optionally) specify a validator, such as for phone number or e-mail, >which will be a subclass of a base Validator class. > >Using these variables, you can theoretically call any method from any Java >class, including static methods, constructors, what have you. The Java code >that loads and interprets this XML will enforce type safety on your method >calls. > >The "register" target I just stuck in there to show examples of validation >(which I haven't written yet). The rest of it actually works (toy example >that it is), you can see it at: > >http://hush.joecheng.com:8180/webcontrol/main/index > >Notice, the fact that you can call any method means that if you bump up >against a situation where the XML is not expressive enough and you don't >feel like extending the language, you can write a custom class for that use >case and just pass it the request/response (a la 738 objects). > >I see the benefit to this approach being that your Java codebase can remain, >for the most part, blissfully ignorant of HttpServletRequests and whatnot. >There can be literally just the model. > >Writing in XML gives you some niceties, such as being able to declaratively >validate your incoming parameters. That's mostly a benefit vis a vis >servlets, since Struts seems to take care of such things for you, so I won't >dwell on it. > >So... the code/logic represented by the XML isn't object oriented at all. >But neither is it as hard to maintain as a big if/else chain, since all the >targets are completely independent of each other (in fact, they can be >lazy-loaded). Since I doubt most people use much inheritance in their >Actions anyway, I think it's OK. Also, you get some niceties such as hot >reloading (though I guess a lot of servlet containers do that now anyway). > >Gosh, sorry this is so long. I better get cracking on my day job... ;) > >Any feedback, positive or negative, is GREATLY appreciated. Also, let me >note that I'll probably build this anyway, even if there's no value in it, >just cause I've learned so much about language interpretation while doing >it. > >-jmc > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
