Struts does not select a DAO! There are some good DAO's standard or not and some bad ones. How many use the standard JDO? What if Struts shiped with JDO by Castor(and Castor proved slow for example, as it did)?
Struts could get out of View (very slowly move tags to jakarta taglib) and be agnostic on view. Pick your poison. I think a lot of people (my clients all do) use display tag (and Struts menu), but it does not ship with Struts, no big deal.
And Struts could down the road then dish out XML, ala SOA, or Axis. XML could then be rendered by any view I can think of, like the X tag. Maybe require the request processor element in struts-config.dtd to nudge people.
Struts core is controller and with that focus maybe better release cycle.
.V
David Graham wrote:
--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
What problems would be solved by repackaging into seperate jars?
There is a perception among some people that Struts only supports JSP in the view layer because it provides JSP tags. While this is not true, it would be clearer if there was a separate taglib jar. Velocity users wouldn't have to lug around the JSP tags but, more importantly, the tags could have their own release cycle. A *large* percentage of bugs are reported against the tags so it makes sense to decouple them from the "core".
Also, as JSF becomes the standard view technology, there won't be a need for the Struts specific html taglibs (JSTL has already largely replaced the bean and logic taglibs). So, it makes sense to separate the Struts "core" from the view layer technology because there are many choices out there besides the Struts JSP custom tags.
I don't see any benefit to separating out other parts of Struts besides the custom tags.
David
Steve
-----Original Message----- From: Etienne Labont� [mailto:[EMAIL PROTECTED] Sent: July 2, 2003 7:46 AM To: 'Struts Developers List' Subject: RE: [PROPOSAL] Modular Struts Examples
I propose (quite informally) a new packaging:
Struts.jar (core logic only) Struts-taglib-rt.jar Struts-taglib-el.jar (from current contrib/struts-el.jar) *Struts-tiles.jar *Struts-upload.jar *Struts-validator.jar Struts-jsf.jar
Jars preceded by * are optional. I see no problem with leaving those closer to the core.
Perhaps heavier on the backs of release managers, but more intuitive
in my
sense. Someone using Struts with velocity could use only the core
part.
Someone doing JSP will know the difference between EL and non-EL. Does this make sense to you?
Etienne
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
