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. > > 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. 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. * 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. 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. > 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"? > > 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. 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 .... > > 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). 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. 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. > > 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 / JavaServer Faces 1.0 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), 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. > > .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]
