----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]> Sent: Wednesday, March 16, 2005 4:48 AM
> I'm not sure I see the reasoning / benefit of POJOs as Actions. The > implication is that some method that wasn't designed to be invoked as > a command / action can do something useful without knowing about the > request, mapping, form bean, etc. (If it has to know about those > things, then it might as well be a Command or an Action anyway. It's > certainly not a POJO at that point.) That seems so unlikely as to be > not worthwhile supporting. I find that most of what goes into my actions is simply wiring up and most of those actions fit one of a limited number of templates. All thats needed is the data from the form and a method in the model. I rarely interact directly with the Request/Session (most of thats in some "standard" code) and the flavours of forwards associated with mappings is limited - (e.g. sucess or failure). One scenario would be to have an IoC container create a POJO and inject whatever resources it needed, populate it from the form data and execute a method. The only thing remaining is having a mechanism to determine where to forward. > Actually, this type of overloading already leads to hard-to-track-down > problems in other parts of Struts. For example, we overload the 'path' > attribute of <forward>s so that it can be a path or a tile. If, for > some reason, your Tiles definitions don't get loaded at startup time, > the first time Struts tries to use a <forward> with a tile value, the > user gets a weird error about illegal path syntax. > > In short, I'd discourage overloading attributes for multiple purposes, > because it will make it hard to determine what goes wrong when there's > a problem. I agree this would be an issue, but could probably be resolved with better error handling / diagnostics. Apparently Tapestry has customized digester to report the position in a config file for an error - sounds like errors/debugging is one of its strengths and maybe something we could improve on. > -- > Martin Cooper --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
