On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> Date: Thu, 03 Jul 2003 17:22:21 -0400 > From: Vic Cekvenich <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Modular Struts Examples > > > 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. Simple for developers to implement if we chose to. Disastrous for Struts users, because it would break 100% of the Action and ActionForm implementations in the world, unless you provide backwards compatible hooks that continue to support the existing APIs -- and that just makes life more complicated, not less. > > > > > >>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. Forgot to mention one other crucially important factor ... JavaServer Faces does not require the back-end bean to extend any particular subclass, or implement any particular interface (how's THAT for a way to avoid the whole class-versus-interface debate about ActionFom? :-). > > > > > * 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. No more so than Struts ... it's all defined by a configuration file that maps names to classes. In Struts that's only done for form beans, in JavaServer Faces its done globally when you evaluate a value reference expression. > It should map to the > form(JSP). And then what about bean.populate() In JavaServer Faces, each component maintains a value reference expression pointing at the back-end model bean property (if any) that should be updated if validation succeeds, or should be the source of dynamically displayed data at render time. There is no need for anything like BeanUtils.populate(), although reflection is still used on the individual fields as value reference expressions are evaluated. > and if there is no data > found or ... > Model 1! Like it or not, there are a whole lot more developers in the world that are familiar with Model 1 than there are familiar with Model 2, especially in the Microsoft arena, but certainly not limited to there. In order to make the Java platform appealing to these folks, we've got to provide easier ways to convert than the "give up your stupid architecture and start over" spiel that has been the primary message these people here from us Model-2-ites. > > > > > 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 Actually, I think consolidating things often makes them more complicated, rather than less. Consolidation was the philosophy that led to a monolithic RequestProcessor that is hard to customize in multiple ways inside the same application. DispatchAction and LookupDispatchAction could perhaps be consolidated, but neither has much to do with what ForwardAction and SwitchAction do. > > > > > > >>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? As I said at JavaOne, a high quality UI component supporting DataGrid is a release driver for JavaServer Faces 1.0 to be viable. It wasn't ready for the last EA release, but will be soon. For more general purpose use (such as in the business tier), doesn't RowSet already do everything you need? I've heard it argued that this can be the standarized DAO interface you are talking about. > > > > 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. It's under exactly the same terms as the Servlet API, or JSP -- for example, you cannot ship a Servlet 2.4 container today, because Servlet 2.4 is not yet final. Yet, we all know that it *will* become final, so we can plan ahead on how to leerage it when it's released. > 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. Your argument is pretty ironic, given that even Microsoft provides mechanisms to programmatically create and modify UI components (using VB or C# or whatever), so obviously there are at least a few people in the world who differ on "UI must be browser". :-) > > > 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? No. JSP and JSTL exist only at rendering time (what JavaServer Faces calls the "render response" phase of the request processing lifecycle). That does not provide any opportunity to perform event processing and/or server side validation, which any robust UI framework needs to support. Further, page authors need to be able to think of a DataGrid as a single "thing" they can manipulate, and concentrate on look-and-feel issues, without worrying about things like the iteration and result set scrolling that would have to be explicitly dealt with if you're doing it the JSTL way. Sure, you can create something like the Pager tag library that makes this kind of thing possible today, but still exposes lots of the plumbing. > > > > >>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.) > > > Agree, more medium examples vs few big examples. > > > 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 thought you said that Struts should *not* have a UI at all, and concentrate on the controller tier? Make up your mind :-). > 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. No matter how much people like you like to diss EJB, it's been the basis for more than a few successful application deployments in large scale, high availabililty, production environments. Whether you like it or not doesn't matter much to me ... there's enough people that do to have built an entire app server software industry around it. It wouldn't bother me at all for JavaServer Faces to have the same kind of effect, and it still won't matter much to me whether *you* like it or not :-). It's clear already that more than a few vendors are taking it seriously enough to build product around. It's clear already that lots of users like the direction. There's already a SourceForge project (MyFaces) pretty far along at an open source implementation. There's already more than a few books underway that will help developers understand how to use JavaServer Faces. And we're not even to Proposed Final Draft yet. I will take "anti-patterns" that are that successful any day of the week :-). > > 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) With most web applicaton frameworks (and, to my limited understanding of Tapestry it follows this model), whatever UI component support they have is generally NOT available stand alone; instead, it is integrated into, and assumes the use of, the rest of the framework as well. Being view agnostic works great when you're talking about not dictating whether to use JSP or Velocity or FreeMarker -- it doesn't work so great at the component level in a page where the components assume infrastructure on the server side as well. > > Jstl 1.1 is Apache license. One particular implementation of JSTL is Apache licensed. It's not the only one in the world. That's the nice thing about specs that can be implemented by multiple folks who compete on quality but have to ensure compatibility. > 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? The RI for JavaServer Faces will be redistributable and usable in commercial environments once the spec goes final. Further, JavaServer Faces is on the list of JSRs for which Sun has guaranteed support, and even scholarships, for non-profit organizations that want to implement JavaServer Faces and then test their implementation for compatibility with the TCK (again, just like Servlet, JSP, JSTL, and others). So can we stop with the FUD about licensing now ? > > 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. But you can't use it yet -- it's still an EA license, and nobody can ship a final product that claims to implement it. Guess we should wait until JSP 2.0 goes final to decide whether we want to use it in Struts :-). > > , 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 Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
