Craig R. McClanahan wrote:
Yes, no monolithic best practice. It also changes over time, what was best done with logic can now be done via C tag, etc. etc. So just keep adding more better examples ... and then when something is way to old, just stop carrying the war. Sites like struts.sf.net and others have more examples .... plus what Craig said, many different approaches, Camino, Expresso. Else all would be using basicPortal :-)
SNIP>
We definitely need examples of modules, and all of the other individual features. I am not a believer that "one big example app" is the right way to approach that -- the sheer scale of such a thing would be a barrier to entry. It's better in some cases (say, illustrating the different ways you can use some of the tags) to have single-page illustrations (like what we do in struts-exercise-taglib, but focused on, and documented as, being examples rather than pseudo-unit-tests).
Also, there's no way that one could ever hope to illustrate *all* possible best practices in a single application anyway, because there are legitimate application-specific needs to choose between various alternatives at every design point. The fact that you choose one particular strategy for user authentication (say, to use SecurityFilter instead of container managed authentication) does not automatically make all other choices "bad" or even "not best" -- they are just "different".
I think struts-upload could be deprecated (along with bean and logic tags). People can do file upload out of commons, or using Jason Hunter's COS upload. etc. Upload is not a Struts core value and could go back to commons.
Have you been paying attention, Vic? The Struts file upload implementation uses commons-fileupload already :-).
More seriously, though, file uploading functionality really has two parts:
* The generic part that can be (and is) used in any web application framework, and/or stand alone (as is the case with commons-fileupload, which is used by Turbine and Tapestry as well as by Struts).
* The part that integrates the generic library into your particular framework (for our purposes, that's things like the <html:file> tag that is Struts-specific, and not appropriate for the generic library). It's entirely reasonable to have adapters like this; every other framework will do the same.
We did the right thing by factoring out the common part of fileupload and
sharing it -- just like we did with validator.
GREAT!!!!!
But it is silly to suggest
that Struts should give up the custom integration part of that, simply because the fundamental logic is generic.
I have no problem beeing silly. :-)
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.
So the "value" of MVC upload is a bit of a gray area.
If we kind of agree (ahh agree) that Struts is model agnostic and view agnostic, I was just implying that upload is not a core value of Struts. People that want upload can upload, and Struts is agnostic. So if struts-dev decides to slolwy move tags to jsptaglib, one think that can be marked for moving out (and solidifying core) is upload integration.
I do not feel strongly about it at all, to say that Struts can redcue it's scope a bit. So no + or - 0.
I would like for 1.2 to ... (can someone set up a "wish list" wiki please?) is repackage into 2 jars: Struts core, and other (taglibs), a few patches and a quick release. Also maybe Mavenize Struts build.
As Ted says, the Wiki is available for everyone to make their own proposals. So is the STRUTS-DEV list :-). In either case, though, specific proposals (with specific action plans) are generally more likely to have useful effects, rather than generic suggestions.
And, don't forget, patches often speak louder than words :-)
I have 18 months ago worked with a few people(clients) to post patches to Struts with diff in bugzila and ... nothing happened. And I have seen this with other things in bugzilla.
So the things I propose I can post code to (since I use/tested already on site), if a commiter is willing to work with me to put in CVS. So after I propose, if a dev says.... oh, thats sounds fun, I, Vic, will do the CVS diff. after there is at least tiny interest of a specific dev member.
Ex:
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)
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.
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)
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.
Reduce number of actions and formbeans in Struts. It could be consolidated.
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)
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).
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)
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....
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
.V
V
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
