First and foremost, thank you for responding. Further comments below. > Here is why I believe that the code is > of interest to the Struts community:
There are many extensions of interest to the Struts community, and we maintain a resource page to help people find them. In practice, when an extension becomes very popular within the community, and it's obvious that there will be people around to maintain the extension, then someone has added it to the core. The Validator, Tiles, and Nested, all came about this way. So, the people to lobby aren't so much the Committers, but the Users. If a good number of people in the community, which includes the Committers, start using an extension like this, then it will probably find its way into the distribution. Darwin decides. --- Fair enough. If you're refering to the functionality offered. Your response fits the original unanswered first and second posts to perfection. Thank you very much. Apologies to all for lobbying at the wrong doorstep. The implementation characteristics of the approach are developer issues and are relevant to this discussion. ---John A. Sessler Personally, I believe in keeping the core distribution as light as possible. That's one reason I still haven't made my own Scaffold package part of the core. It's also the reason we started places like Struts SourceForge. --- Fair enough. Proposed functionality may or may not make it into the core. But back to this thread and developer issues. The implementation tecnique requires a minimal footprint on the core and addresses controller issues discussed here. My previous post mentions these points. ---John A. Sessler -Ted. john sessler wrote: > Hello, > > I get the distinct feeling that the committers point of view on the controller > component of Struts is quite similar to Henry Fords point of view on the color of > his cars. ...The controller component can be based on any arqitecture at all as long > as its Command Chains... > > I realize that at some point a path must be choosen and code written. Ideas and > conjecture about how many design patterns could be applied to the problem are > insufficient. Craig has written code and Ted likes it so a path has been choosen, > code written. No problem. Life is good. > I don't doubt the proof of concept or the reasoning behind it. I am concerned about > the acceptance of other ideas and other code (I have already said ideas are not > enough). > > Prior to this extensive thread I have submitted code which fits squarely inside the > controller component of the Struts MVC arquitecture. I requested comments on the > code and received none. > I might have expected constructive criticism, obsevations or even recognition of > merit... but needed. But indifference was quite surprising. In light of the > discussion within this thread I see the problem. My code contribution doesn't fit > the expected pattern. Yes, that's a play on words. > > Indulge me for just a few more minutes. I formally request that a committer look at > the code/doc I have contributed. Yes, I understand that you are volunteers and that > you have no obligation to do so. If someone should decide to respond I thank you in > advance. This is also my last request for comments. Here is why I believe that the > code is of interest to the Struts community: > > * The approach requires an absolute minimum amount of integration with existing > Struts code. The approach requires an essentially trivial refactoring of the > RequestProcessor. I repeat, REFACTORING, not a new or modified behavior > RequestProcessor. Since even refactoring would not "be doing the right thing". In > lieu of that, a Coomand adapter can probably be used. > > * Much has been said about coupling between actions. I claim that there is no > coupling between actions using the approach. Comments are welcome. > > * Much has been said about mixing business logic with actions. I claim that the > approach does not mix business logic with actions nor does it encourage it. Comments > are welcome. > > * The approach does not require a developer to choose this approach over other, > differing approaches. Mixing and matching is fine. > > * The approach is aimed toward reusable Struts controller components. Here, I'm > refering to the MVC controller in the general sense not to the Struts servlet > controller. Comments are welcome. > > Here is the link to the code and documentation. > https://www.sistemas-jasper.com/indexStrutsActionWrappers.htm. > > > John A. Sessler --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
