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

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.

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



Reply via email to