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]>
