--- Nathan Bubna <[EMAIL PROTECTED]> wrote: > Steve Raeburn said: > > David Graham said: > > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > > > I'm still happy to be in the view business, but I do think that > > > > decoupling > > > > the controller from the view would be A Good Thing. > > > > > > The controller has no dependency on the view. The taglibs are > dependent > > > on what the controller stores in the various scopes. You could > develop an > > > app without using the html taglib at all (XML, Velocity, etc). > > > > Agreed. It's almost unthinkable, but you can even develop an app > without > > Struts :-) But I was focussing on JSP which is still the most common > view > > technology. At the minute it's not practical to create a JSP Struts > app > > without the html taglib so, in my view, Struts as an application > framework > > is dependent on that taglib. > > that's ridiculous. i've been working on Struts apps for nearly a year > and i > have *never* once used the html taglib. if you wanna say Struts is > "dependent" on it, you've got the funkiest definition of "dependent" > that i've > heard in a long while. following that logic i could say that the > internet is > dependent on Internet Explorer because it's the most common means of > using it. > > > > FWIW, JSF has much richer view support than Struts does. It > supports > > > features that Struts users have wanted like binding form data to > native > > > data types on beans that don't implement any particular interface or > > > extend a certain class. > > > > Yup, that's a possible (probable?) way forward. I'm not ignoring other > view > > technologies or JSF, just focussing on what is commonly in use now. > > focus is fine. tunnelvision is not. > > > For discussion, here's my view of how things might progress: > > > > - Short term: continue to separate the taglibs from the Struts core > into > > their own cvs/build/distribution. > > continue? i didn't know the taglibs had even begun to be moved to a > separate > cvs, build, or distribution. and if i'm wrong on this one, i'd love to > be > corrected :).
The goal is to have the taglibs distributed in their own jar with their own release cycle. We're actually close to acheiving this; we just need to setup the build correctly. > > > - Medium term: drop support for the old taglibs and move the el tags > up to > > the core distribution (or their own distribution if that's what is > decided). > > I understand that breaks support for JSP 1.1 and I'm personally OK > with that > > but I do appreciate that may not be the general consensus. > ... > > i don't believe any taglibs or other view technology should be part of > the > core distribution. the question of "where" these View libraries are > developed > is secondary. i'm definitely with Ted on this one. develop it wherever > there's a community interested in developing it, but please give the > taglibs a > separate release cycle. > > over in VelocityTools, we've tried hard to dispel this notion that > Struts is a > JSP technology. Thanks, that seems to be a popular misconception. I've never quite understood why people don't like JSPs (especially with JSP 2.0 just around the corner) but Struts certainly is *not* dependent on any view technology. > i think we've had a little success with that, but > you're not > really helping here. while it's true that other view technologies can > use > Struts, as long as the Struts developers treat JSP as the "standard" > view and > distribute the two together, i believe you are significantly limiting > the > potential of Struts as a framework/controller for applications (web and > otherwise). The Struts homepage describes our exact views on where Struts fits in. It even mentions Velocity :-). David > > Nathan Bubna > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
