[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-dev
Subject:    Re: Standard HTML Tags (was Extending Standard Tags ...)
From:       "Nathan Bubna" <nathan () esha ! com>
Date:       2003-09-29 19:11:40
[Download RAW message or body]

Steve Raeburn said:
> Nathan said:
> > Steve said:
> > > 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.
>
> It's not ridiculous if you actually read what I wrote. I specifically and
> carefully said, "a JSP Struts app". I know that there are other view
> technologies but the fact is that JSP *is* the most prevalent and as such I
> think it is a good and important thing that Struts supports it "out of the
> box".

the phrase that irked me was "in my view, Struts as an application framework
is dependent on that taglib."   sorry, but i don't parse that as "it is...
important... that Struts supports it 'out of the box' ".  those are
significantly different.  if you'd said it the latter way the first time, i'd
not have complained.

> > > 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.
>
> Indeed. I was attempting to explain that my comments are limited to Struts
> in a JSP context, not that Struts should only support JSP or that other
> technologies like JSF (or Velocity) should be ignored. I thought the phrase,
> "I'm not ignoring other view technologies or JSF", explained that.
> Obviously I was unclear.

i don't think you were unclear.  i believe i understood, and my statement that
"focus is fine" was in agreement with you.  the "tunnelvision" comment was
merely a caution.  i suppose i came across unclear in my succinctness, sorry.

> > > 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 :).
>
> You are wrong. David & Rob have been working on reducing the coupling of the
> tag libraries to the Struts core, introducing TagUtils to take over some of
> the work that RequestUtils was doing for the tag libaries. The purpose being
> to reduce the inter-package dependencies allowing the taglibs to be
> distributed in their own jar with their own release cycle.

yes, i had noticed this and have appreciated the work.  i guess i just didn't
construe it as a "moving to a separate build."  if i'd thought further about
it...  ah, but it was late and you got me pretty riled up with the "dependent"
comment.  :-/

> > > - 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.
>
> If there's a community outside the Struts project itching to develop and
> maintain a Struts JSP tag library, please let me know.
>
> All I meant was that I would be happy to drop legacy support for the JSP 1.1
> taglibs in favour of JSTL and the Struts-EL tags FOR JSP BASED APPLICATIONS.
> At the moment the el tags are languishing in the contrib directory and I
> think they should be the primary Struts taglib FOR JSP BASED APPLICATIONS.

ah.  well, you were talking about moving the el tags into "the core
distribution."  i was arguing against that (the "core," to me, is the
framework) and pushing for your parenthesized suggestion of putting them in a
separate distribution "if that's what is decided."  if i misread that, then
sorry, but it wasn't made clear enough.

> See above regarding a seperate release cycle.
>
> > over in VelocityTools, we've tried hard to dispel this notion that Struts
> is a
> > JSP 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).
>
> I believe over at Struts, people have also been doing the same. Right at the
> top of the Struts home page it says, "For the View, Struts works well with
> JavaServer Pages, including JSTL and JSF, as well as Velocity Templates,
> XSLT, and other presentation systems." I also recall several occasions on
> the struts-user mailing list when Struts committers have corrected the
> misconception that Struts is in any way bound to JSP. In fact, I'm pretty
> sure I've said it myself.

actions speak louder than words.  as long as the taglibs are bound up in the
same release cycle, jar, and distribution as the core, then i believe the
misconception will persist.

> I don't quite understand why I am not helping. I'm in favour of repackaging
> the taglibs and giving them a seperate release cycle.

hmm.  from your previous email that seemed to be your second choice, but ok,
i'm glad to hear it!

> I want to reduce the number
> of Struts specific libraries in favour of the the general purpose and
> standard JSTL. And I think it's great that users have a choice of view
> technologies.
>
> The only thing I disagree with you about is that I think the Struts taglib
> is fine where it is and should be included in the distribution whereas you
> would have us remove it and ship a framework that can't actually do
> anything.

again, i have no problem keeping the tags in the Struts project if the
community wants them there.  but the framework does plenty for me without the
tags, so IMHO, they don't *need* to be in the same distribution.  or at least,
not in the same jar (we agree there, right?)

> How would you suggest we include example applications without including at
> least one view technology?

you could just put the taglibs jar in the WARs for the example app(s) that
need it, just like you would with any other library the example apps are
dependent on.  for instance, one of the VelocityStruts example apps Gabe made
demonstrates using Struts with *both* Velocity and JSP.  once the taglibs are
separated, we will include the taglib jar in the WAR for that app, but not
have it in the rest of the distribution.  if you included a VelocityStruts app
in the Struts examples, would you argue that VelocityTools should be
distributed with Struts besides being in the example app's WAR?

> And if we're going to bundle support for a
> view technology, shouldn't it be the most widely used, widely understood and
> standard (as in JCP, not as in the standard for Struts) one?

as long as the core and the taglibs have separate release cycles and are in
separate jars, i won't be too picky. :)   if you want to ship them together,
go for it.  though personally, i think the 16MB size of the Struts 1.1
distribution could use a little paring down somewhere.  there's already a ton
of jars (mostly duplicates) between the lib, struts-el/lib, and the example
WARs.  but i digress, that is another matter. :)

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]