Craig R. McClanahan wrote:
On Thu, 3 Jul 2003, Vic Cekvenich wrote:
My point was a shade on the other side. Yes Struts can show integration to do 100's of things out there. But at its core, Struts is a controller framework.
Right now, it's in particular a "front controller" framework, in design pattern terms. That's one of the areas I would personally like to see us do some innovation.
Action Event Object execute signature- instead of the execute signature with 4 arguments, have a single object containing the 4 objects. This reduces people new to Struts creating properties in action, and allows same execute signature for TilesAction, etc. The code looks a lot cleaner. bP does this (as I think does Expresso)
No matter how technically worthy such an idea might be, this isn't going to happen in a 1.x train, due to backwards compatibility expectations. This is part of the responsibility that goes with being a widely deployed and utilized framework -- we have to protect the investment of people who have built on top of the existing architecture. If we only had a few users, we would be more free to do stuff like this. But according to the Apache web site stats (unofficial, but seem like they're pretty accurate) we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.
If we're willing to look at changing the fundamental APIs (and I think we are in a 2.x train), there is a lot more we can do to make Struts better than just this kind of change -- I'd rather look at the overall architecture more holistically, instead of incrementally, when making decisions like this. For example, I will shortly be done with a pretty radical proposal for the "decomposing the request processor" conundrum that has been discussed a lot lately on STRUTS-DEV.
Incremental change is great for improving implementations. It's not so great for modifying fundamental APIs. To do the latter well, you need to be prepared to think outside the box, and even re-invent yourself on occasion.
It is a simple change, like perform and execute signatures.
protected List _list in FormBean. As Husted's book points out (and bP implements), it is nice to store data in a protected _list. (I am sure I took it out of context) People mostly work with a tabular recordset, rows of columns, eg: List of Maps. There are many ways of getting DAO data to FormBean, but a good idea is to store the rows as a _list. People that extend the ValidatorFormBean can then write their own getValue, setValue and beann getters/setter, it nuges people in right direction to store data agnosticly. (Ex: MQ gets results, remaped via magic to formBean, and stores in a list). Things like indexed properties become easier then ... and best view in JSP world is display tag, works with collection. Note that I would not implement the methods, just leave it like that, protected _list, a place to plug into.
As you well know :-), you and I don't totally share a vision of what a form bean is for, and what it's not for :-). However, the recent progress on JavaServer Faces clearly indicates that Struts's form bean approach, and total lack of any real UI component model, needs to be addressed.
Yes. But we do agree that FormBeans have nothing to do with how the data comes in. (And I have adjusted my designs a lot since)
I'd actually rather address it by focusing on the controller (as you suggest), and let all the view-layer considerations be separated as well. I think that form beans, by themselves, are too limiting as a long term abstraction for server-side view state.
Just as an example of this, look at where JavaServer Faces is today, with respect to the concepts behind form beans and actions:
* You can use one form bean per page, or more than one -- your choice.
This I think is a mistake on JSF part. A formBean should map a form (JSP). If JSP is nested, so formBean should nest beans.
The major benefit is that one can unit test the formBean outside of the JSP for CRUD, etc. Modular! Else you are integrating in the JSP and that is just no good, now we need Container debugging, since less of a unit test.
* You can combine the form bean data with your "action" class (the way that WebWorks does it) or keep them separate -- your choice.
* You can ask for ANY bean to be automatically instantiated on demand, not just form beans.
Hey, now that is a security problem potentialy. It should map to the form(JSP). And then what about bean.populate() and if there is no data found or ...
Model 1!
The technology train is passing us by. We're not going to be able to catch up with simple incremental changes.
Maveric instead of Ant for build. My argument is this. CVS out CommonsSQL and use Maverick to build it. Sexy! It auto downloads all the other jars it needs. People can target any thing very easily. The build process becomes simple and fun. (I do not have this code, but could)
In the Apache world, Maven provides similar sorts of capabilities, and does not require you to give up the ability to use plain old Ant (Maven can generate a build.xml file for you). If we're going to switch, I'd rather go that direction (if the Maven folks would ever ship a final release, at least).
Improving the build process is definitely needed, but that's mostly for us as developers, not for users.
That is what I meant on Maven. OK, if you developers need users to do some of the leg work.
Required in DTD of sturts-config the request processor element. - This nudges expert users in extending Struts in the right place, it exposes the right place overlooked.
In the "workflow" component of jakarta-commons-sandbox, one of the things I really liked was using XML namespaces as an extensibility mechanism. It seems like a natural way to let people integrate extensions of their own into an existing standard configuration file format.
However, DTDs are not powerful enough to allow for this -- you have to go to XML Schema (or something equivalent) to support it (the way that all the deployment descriptors in J2EE 1.4 are going), or else give up on the idea of validation at all. That's too big a price to pay. And, as long as we're based on Servlet 2.2 / JSP 1.1, we can't really get away with requiring schema support, so it's tough to move forwards on this one in the short term.
Reduce number of actions and formbeans in Struts. It could be consolidated.
I can see what you're saying on form beans, but what do you mean by "reduce the number of actions"?
DisptachAction, LookupDispatchAction, ForwardAction, Switchaction (even tilesaction if you change the execute signature) If they can be consolidated, good I think
DAO - OK, here I walk a fine line. Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is the most popular J2EE framework. No one outside of Struts-dev can fix this. If there can be an interface (I know, if you change it.... bla, bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate, RowSet, MQ, etc. etc. It would enable people to easily plug and play a model. I do not care what the signatures of this DAO are other than it must allow ANY DAO implementation to be used and shoud be unit testable for CRUD. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java Craig, I realy realy think that only you can make this happen. (That registration of DAO for JSF I did not like, interface is KISS)
There is more than one "right" way to integrate persistent data and business logic into a web application, DAOs being only one of them. There is more than one "right" way to design DAOs, depending on your particular requirements. Whatever we do in Struts needs to recognize that it is not going to be possible to shoehorn everyone's requirements into a single pattern.
For the particular case of tabular data, we should also be paying
attention to recent innovations in JDBC RowSet Implementations (JSR-114)
that just went to Public Review Draft in the JCP process.
Yes, as you know I was one of the early chapions of RowSet for a long time ( and worked on fixing many of the bugs in the early release into open source pg driver.)
I would expect
to see early access RI code for this stuff shortly, and it will be interesting to see how well those folks did on a standardized abstraction to rows and columns, with much stronger support for disconencted operation cases.
But rows and columns doesn't cover all of the world's needs either ....
If there are any signatures to which we can agree as DAO that would work... that would be great for J2EE.
We do not need to see RI of RowSet since we know the API now.
Yes OMG model should be supported, maybe just return Object in DAO interface? (datagrid, did I say that enough?)
Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view agnostic. But Display tag commiters are trying to make it updateable AFAIK. Download the display tag war and run examples. This is the colosest thing to DataGrid in JSP. Put it in Struts to get focus (and then slowly move to taglibs).
I am not personally interested in being in the proprietary custom tag development business at all any more ... JSP 2.0, JSTL, and JavaServer Faces have made (or will make, in the latter case) further innovations on non-standards-based tag libraries a waste of long term time. We need to maintain and enhance the existing implementations, and fix the things that are wrong with them -- but the future is going to be based on the standard APIs, if we want to continue to be a mainstream platform. We need to continue to welcome and integrate the new technologies (as we've done with JSTL and Faces so far).
Display tag is Apache license, and open source.
DataGrid like is very important and there is nothing like that. Maybe based it more on JSTL or JSP2.0?
Recast the display taglib (or anything else in the same space) as
JavaServer Faces components and I'll be interested in it. Incorporate JSF
component libraries from your favorite development tool or open source
project, and I'll be interested in it. Suggest that we create some of our
own value-added components based on Faces (so that we're not limited to
just JSP, and not limited to just rendering HTML), and I will be
interested in it.
JSF (as you know :-( ) I personaly consider propriatory. Once I see the real production license in 1.0 release by Sun or others, I will re-consider.
2nd, JSF makes some architectral mistakes that remind me of EJB. I could write another long letter to the JCP, but too late, the comitte is locked. Short story is that Java Everywhere plan will *not* work for GUI, UI must be browswer, not Java, and not by a Java Developer but by graphic artist. (As proof, I could show you some sites I designed the GUI for :-) ). Also, I sincerley, but maybe naivley, think that JSF push by Sun will push Java Developers into .Net. Nothing in version 1.0 will fly, look how Struts was allowd to grow in 0.6 in a shade. If my clients balk at JSF, I have no choice. Diverting Apache Struts users to Sun JSF is not a great idea.
Continue to innovate on top of the current form bean
architecture, and I'm probably not going to be interested in it for the long term.
Other Struts developers, of course, can speak for themselves.
I think JSTL is a great direction, and JSP 2.0 is great (KISS). If a data grid was based on JSTL more, would that suffice?
Agree, more medium examples vs few big examples.
Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security example, multi row updates, events - like action changed event for session clean up)
There are undoubtedly some ideas from bP (and other things built on top of Struts) that can be harvested in a 1.x time frame, now that we got 1.1 out the door. A lot of resistance to this in the past has been based on wanting to get that (1.1) done, not by concerns about technical merit or suitability for inclusion.
(Regarding examples, having lots of small-to-medium examples seems better than having few huge ones; but that's a topic for the other thread.)
My only concern goes back to the comments about DAOs above -- when there is legitimately more than one approach to dealing with a particular issue, you want to be careful about baking in one-and-only-one approach into the fundamental architecture. And, when there are standard APIs in the same space of endeavor, you ignore them only at the risk of becoming non-mainstream in the long run.
Target servlet 2.3 and JDK 1.4. - There are now dependencies on 2.3 and more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like more fun. People that want 2.2 or 1.3 could rebuild, or they can keep using solid 1.1. A small KISS step. By the time 1.2 comes out....
For Struts 1.2, we have already agreed to stay with Servlet 2.2 / JSP 1.1, but change our release cycle to do incremental releases much more often (the way that Tomcat and the HTTPD server do it nowdays). Besides a continuied commitment to backwards compatibility in APIs, this puts restrictions on how frisky we can get with changes to old stuff (adding new stuff actually becomes easier with the new release cycle approach).
For Struts 2.0, I think we should actually skip Servlet 2.3 / JSP 1.2, and
go straight to Servlet 2.4 / JSP 2.0 / JSTL 1.1 /
Great!!!!
JavaServer Faces 1.0
-1
JSF needs to be more open, scaleable, rich UI (right now not even Javascript support).
I think Struts should stay View agnostic.
(Why not add EJB to Struts? same argument, it is contraversial, ex: Bitter EJB) JSF could become an anti-patern.
So lets say this is what JSF is, simplified as a faces tag: http://jakarta.apache.org/ecs/index.html That is all JSF is, Java GUI.
Why not do Tapestry or 10 others as a view. ( I am using Flash more and more, since it can also talk to C# via XML)
Jstl 1.1 is Apache license. What if JSF RI has run time fees, or can you state now for a fact that Sun RI will not have any run time fees?
as
the base platform. Because of the lengthy gestation period for J2EE 1.4 as a whole, it won't be long after 1.4 goes final that we'll have lots of containers available to host such apps. It doesn't make sense to do any fundamental architectural improvements in the core Struts APIs without recognizing that this will be the commonly deployed platform by the time we get done.
Servlet 2.4's changes (request lifecycle listeners, and the ability to
execute filters on RD calls) are not earth-shattering, but they are
useful.
JSP 2.0's changes, on the other hand, are very fundamental (if
you're using JSP as the basis for your view technology)
Yes, 2.0 rules.
, and eliminate the
need to use Java code for lots of things where it is used today. For example, a page author can point at a chunk of JSP code and say, in essence, "please make a custom tag out of this for me". And, of course, EL expressions are evaluated anywhere in the page (even static text), so tags like <bean:write> basically lose their reason to exist. And, for the cases where custom tags written in Java are still required, the new SimpleTag API is *substantially* easier to write aganst than the current Tag/BodyTag stuff.
I will do the legwork on any of these, if a single dev is interested in applying the diff., but most are trivial and do not need man hours. The last one I hope makes it for the 1.2 release
Nobody can decide whether or not to apply a specific change without seeing precisely what you're proposing to modify. A lot of the things you've suggested in this email would break backwards compatibility, and thereby earn a -1 for implementation in 1.2, but might well make sense in a 2.0 world.
Thanks. .V
.V
Craig
V
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
