You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Chris Gastin <ch...@gastin.com> on 2003/09/25 07:29:23 UTC
Editable Fields V/S Static Text
Has anyone considered a feature which toggles between an editable form
element and read only text / static text.
I find myself developing JSPs where depending on the Use Case "fieldA"
could be an editalbe text box (<input name="fieldA" value="My Text Value"
/>) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2
(My Text Value) on the same jsp. Presently I am using the
<logic:equal></logic:equal> tags. Which get really messy. Here is some
sample code.
<logic:equals name="actionForm" property="myFieldEditable" value="true">
<html:text name="actionForm" property"myField" />
</logic:equal>
<logic:equals name="actionForm" property="myFieldEditable" value="false">
<bean:write name="actionForm" property"myField" />
</logic:equal>
It would be nice to add an attribute to the current tag libraries, which is
a boolean, and does this toggling for you. Here is what I am envisioning
If actionForm.myField = "My Text Value"; This tag <html:text
name="actionForm" property"myField" readOnlyText="true"/> would output "My
Text Value".
Where <html:text name="actionForm" property"myField" readOnlyText="false"/>
the following tag would output
<input name="fieldA" value="My Text Value" />
As you can imagine this would not be a huge undertaking to add this feature
to the current tag libraries in struts. I could use this feature, and I am
sure other could too. I am willing to contribute my time to the development
effort. I am not stuck on the attribute name "readOnlyText", and would
welcome suggestions. Does this sound like a good idea, and if the answer is
yes, what is the next step.
Chris Gastin
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Robert Leland <rl...@apache.org>.
Chris Gastin wrote:
>Rob:
>I am not an contributer, but I am a young developer. I am willing to step up
>and support these abilities in the struts tags
>
>
Great !
I have come to believe that young/single developers & older/grown
kids/empty nesters developers are better
situated to be Open Source developers. The guys with a families don't
seem to have as much free time.
So do what you have time for and enjoy the process, you'll learn allot !
>Chris Gastin
>
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Chris Gastin <ch...@gastin.com>.
Rob:
I am not an contributer, but I am a young developer. I am willing to step up
and support these abilities in the struts tags
Chris Gastin
----- Original Message -----
From: "Robert Leland" <rl...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Thursday, September 25, 2003 9:43 PM
Subject: Re: Editable Fields V/S Static Text
> David Graham wrote:
>
> >--- Sgarlata Matt <sg...@bah.com> wrote:
> >
> >
> >>OK, here's another idea. I searched the archives for it and couldn't
> >>find
> >>it.
> >>
> >>How about two simple changes:
> >>1) Add a new renderExtraAttributes() method that gives people the chance
> >>to
> >>throw non-standard HTML into their tags that extend from Struts tags.
> >>
> >>
> >
> >I am -1 on the Struts tags supporting any non-standard HTML including
> >providing the suggested hook method. Like Java itself, Struts aims to be
> >a cross-platform tool. Adding support for non-standard HTML undermines
> >that goal and promotes non-interoperability.
> >
> >
> Is it really the Struts tag library's mantra to dictate that the tags
> should not be modified
> externally to gain needed functionality ? By not providing hooks,
> wheather these are the
> correct ones or not, isn't very developer friendly. A framwork can be
> developer friendly,
> and well designed at the same time.
>
> And It's not that the tags would be producing non standard HTML 4.01,
> it's that they would/could
> add composite functionality over and above standard HTML that would
> still be 4.01 compliant.
>
> I agree with what several other committers, that if developers want to
> step up
> and show that they will help support those tags I'll vote for the
> ability to support these abilities,
> inside the struts tags not just the hooks.
>
> -Rob
>
>
>
> >I can't count the number of times I've been frustrated by webapps that
> >require a particular browser that I'm not using. I absolutely don't want
> >one of my favorite tools to support that kind of development.
> >
> >
> >
> >>Here
> >>is a snippet from BaseFieldTag.java:
> >>
> >><snip>
> >>results.append("\"");
> >>results.append(this.prepareEventHandlers());
> >>results.append(this.prepareStyles());
> >>results.append(this.getElementClose());
> >>
> >>
> >><matts-idea>
> >>results.append(renderExtraAttributes());
> >></matt-sidea>
> >>
> >>return results.toString();
> >></snip>
> >>
> >>The use cases for this are (a) to support the readonly attribute and
> >>
> >>
> >
> >At least the <html:text> tag already supports readonly. Are there other
> >tags (where readonly is allowed) that are missing it?
> >
> >http://jakarta.apache.org/struts/userGuide/struts-html.html#text
> >
> >David
> >
> >
> >
> >>(b)
> >>to
> >>support the "attributes" extension that was shot down for inclusion in
> >>the
> >>out-of-the-box Struts <html> tags.
> >>
> >>2) Instead of accessing instance variables directly, use getters. (I'm
> >>not
> >>sure if this will cause problems with the EL versions of tags...
> >>thoughts
> >>anyone?)
> >>
> >><snip>
> >>if (accept != null) {
> >> results.append(" accept=\"");
> >> //old way
> >> //results.append(accept);
> >> //new way
> >> results.append(getAccept());
> >> results.append("\"");
> >>}
> >></snip>
> >>
> >>If someone wanted to override the accept attribute so that it was always
> >>equal to foo then they would be able to do so. A better use case would
> >>be
> >>overriding the onclick method so that it does something special like
> >>display
> >>a calendar popup.
> >>
> >>I apologize in advance if this has been discussed before. ([OT] I
> >>really
> >>wish there was an easier way to search the archives. I have resorted to
> >>googling them, but it's still a pain.)
> >>
> >>Matt
> >>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: New feature process
Posted by Ted Husted <hu...@apache.org>.
Once upon a time, I made a point of updating the changelog, but during
that death march affectionately known as the Struts 1.1. release =:), I
fell out of the habit, and haven't picked it up again. Back in the day,
some thoughtful people also tried to update the changelog as they made
the commits.
CVS and the CVS emails should be the primary reference for the
changelog, since these are kept automatically. Not everything goes
through Bugzilla. Erik Hatcher mentioned that Ant can generate a summary
changelog from CVS, but I haven't tried it yet.
As far as tests and documentation go, there is a general consensus that
new features should breed new tests. When possible, bugfixes should
generate new tests too. Although, since Struts was not designed for
testability, creating such tests can be a challenge. We should at least
be running the tests we have around any change or commit.
However, at this point, I believe the Cactus tests are broken and that
James Mitchell may try to fix them soon.
Since we are in an evolutionary mode right now, it not strictly
necessary to obtain a vote on new features. But, it can save the trouble
of backing the change out if it turns out to be something another
Committer would veto. The hardcore Apache projects rarely vote on
anything except releases. The decision-making is consensus-based through
general discussion on the development lists. People use terms like +1
and -1 in the discussions, but its not so much a vote as an indication
of how they would vote, should a vote occur.
So, if you used tests as part of developing the feature, then please
commit those too. Or, if you see a test suite that could be extended to
include the new feature, please add the test.
Unless we are going to try automating the changelog with Ant, then it
would be helpful to update the changelog as well (creating a new one if
needed).
Under heading "observe the style of the original", please make sure that
any submission is fully Javadoc'd. If possible, please also update the
user guide as to the existence of your feature, relying on the Javadoc
for base material.
If the feature was covered by a Bugzilla ticket, then please resolve the
ticket. It's been suggested that if a feature was not registered in
Bugzilla, then we should create one for it, but I'm not sure that we've
developed a behavioral consensus on that. =:)
-Ted.
Don Brown wrote:
> I'm familiar with the process of bringing up new features to the group as
> it is documented on jakarta's site:
> http://jakarta.apache.org/site/decisions.html
>
> Rather, I was interesting in what the Struts process once the feature is
> committed. I would assume the following areas would be affected:
> - tests
> - changelog
> - documentation
> - bugzilla
>
> Don
>
> On Sun, 28 Sep 2003, Robert Leland wrote:
>
>
>>Don Brown wrote:
>>
>>
>>>What is the process when adding a new feature (in this case, wildcards for
>>>action mappings)?
>>>
>>
>>Create a Subject: [Proposal] wild cards for action mappings.
>>
>>Use lazy Consensus.
>>At least 3 +1 votes, no -1 votes.
>>There is a doc somewhere that says when to use each type of vote.
>>Also I thought we already discussed this and it's addition was approved ?
>>
>>
>>>Do we wait until a release is ready to update the
>>>documentation or update it when the feature goes in?
>>>
>>
>>I would say nightly Docs should always match the nightly source
>>
>>
>>>Also, I couldn't
>>>really find a changelog.
>>>
>>
>>If you have maven you can now build the top level struts documentation
>>which includes a
>>generated change log.
>>
>>
>>>Do we just use bugzilla to track new features?
>>>If so, should an enhancement request be made before a feature gets added?
>>>
>>>
>>
>>No.
>>
>>
>>>If this information is already on a webpage somewhere, I apologize in
>>>advance :)
>>>
>>>
>>
>>I would like to know that answer also.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: New feature process
Posted by Don Brown <mr...@twdata.org>.
I'm familiar with the process of bringing up new features to the group as
it is documented on jakarta's site:
http://jakarta.apache.org/site/decisions.html
Rather, I was interesting in what the Struts process once the feature is
committed. I would assume the following areas would be affected:
- tests
- changelog
- documentation
- bugzilla
Don
On Sun, 28 Sep 2003, Robert Leland wrote:
> Don Brown wrote:
>
> >What is the process when adding a new feature (in this case, wildcards for
> >action mappings)?
> >
> Create a Subject: [Proposal] wild cards for action mappings.
>
> Use lazy Consensus.
> At least 3 +1 votes, no -1 votes.
> There is a doc somewhere that says when to use each type of vote.
> Also I thought we already discussed this and it's addition was approved ?
>
> >Do we wait until a release is ready to update the
> >documentation or update it when the feature goes in?
> >
> I would say nightly Docs should always match the nightly source
>
> > Also, I couldn't
> >really find a changelog.
> >
> If you have maven you can now build the top level struts documentation
> which includes a
> generated change log.
>
> > Do we just use bugzilla to track new features?
> >If so, should an enhancement request be made before a feature gets added?
> >
> >
> No.
>
> >If this information is already on a webpage somewhere, I apologize in
> >advance :)
> >
> >
> I would like to know that answer also.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: New feature process
Posted by Robert Leland <rl...@apache.org>.
Don Brown wrote:
>What is the process when adding a new feature (in this case, wildcards for
>action mappings)?
>
Create a Subject: [Proposal] wild cards for action mappings.
Use lazy Consensus.
At least 3 +1 votes, no -1 votes.
There is a doc somewhere that says when to use each type of vote.
Also I thought we already discussed this and it's addition was approved ?
>Do we wait until a release is ready to update the
>documentation or update it when the feature goes in?
>
I would say nightly Docs should always match the nightly source
> Also, I couldn't
>really find a changelog.
>
If you have maven you can now build the top level struts documentation
which includes a
generated change log.
> Do we just use bugzilla to track new features?
>If so, should an enhancement request be made before a feature gets added?
>
>
No.
>If this information is already on a webpage somewhere, I apologize in
>advance :)
>
>
I would like to know that answer also.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
New feature process
Posted by Don Brown <mr...@twdata.org>.
What is the process when adding a new feature (in this case, wildcards for
action mappings)? Do we wait until a release is ready to update the
documentation or update it when the feature goes in? Also, I couldn't
really find a changelog. Do we just use bugzilla to track new features?
If so, should an enhancement request be made before a feature gets added?
If this information is already on a webpage somewhere, I apologize in
advance :)
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: September 28, 2003 3:18 PM
> To: Struts Developers List
> Subject: Re: Standard HTML Tags (was Extending Standard Tags ...)
>
> Steve Raeburn wrote:
> > I still feel that many of the html tags are *necessary* for use in
> > a Struts app.
> >
> Unless you are using some alternative tag library for rendering your
> markup, such as the struts-faces library when it is done, or any other
> HTML rendering tag library that someone wanted to adapt (as needed) to
> work on top of Struts.
...
> Of course, the whole discussion of migrating tag libraries elsewhere is
> totally academic unless there is someone who wants to *do* it instead of
> just talk about it. In the absence of that, there's nothing wrong with
> leaving them exactly where they are.
Sure, I just wanted to suggest that moving them is not only unneccessary but
perhaps not a good way to go.
...
> > 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.
> >
> Agreed ... personally, I'm working on a different solution (than the
> Struts html tag library) to that problem :-).
Looking forward to it, but I think we need to hang on to the taglibs just a
little while longer :-)
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Standard HTML Tags (was Extending Standard Tags ...)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Steve Raeburn wrote:
>I think I'm coming at this from a different perspective than you :-)
>
>The acid test for me is whether you could sensibly create a Struts app
>without using the tags (just talking JSP here). While you can get by without
>bean or logic tags, I still feel that many of the html tags are *necessary*
>for use in a Struts app.
>
>
Unless you are using some alternative tag library for rendering your
markup, such as the struts-faces library when it is done, or any other
HTML rendering tag library that someone wanted to adapt (as needed) to
work on top of Struts.
>More below...
>
>-----Original Message-----
>
>
>>From: Ted Husted [mailto:husted@apache.org]
>>
>>
>...
>
>
>>Jakarta Taglibs maintains a Dreamweaver extension, why could they not
>>maintain a Struts extension?
>>
>>
>
>They could but, because JSP is the most common view technology, I think
>Struts would be diminished without the html tag library.
>
>
>
>>Likewise, Jakarta Velocity maintains a Struts extension. Should we ask
>>Nathan Bubna et al. to bring that here because it is dependent on Struts?
>>
>>
>
>But it's also dependent on Velocity :-) I think the need arose from users of
>Velocity wanting to use Struts rather than the other way round. I think it
>probably adds more value to Velocity than Struts and, you've pointed out,
>that's were the developers are.
>
>
>
>>The new Commons Chain package supports extensions for Servlets,
>>Portlets, and JavaServer Faces, which are technologies not maintained by
>>the Chain team.
>>
>>
>
>That's not really the same. Struts would depend on Chain, much as it now
>depends on other commons packages. Chain is useful in many other situations
>that don't include Struts. That's not *currently* the case for the taglibs.
>
>My view is that Struts taglib (html) depends on Struts *and* Struts depends
>on the tags. It's that co-dependency that leads me to think they should stay
>together.
>
>
>
>>IMHO, it's not a question of technology. It's a question of community
>>support. If the people who actively maintain these tags wanted to
>>maintain them at Jakarta Taglibs, there's no technical reason to keep
>>them here. Conversely, there's no technical reason to move them either.
>>It's just a matter of where the people doing the work want to do the work.
>>
>>
>
>And I think that the Struts project is where the maintainers of the Struts
>taglib are / will be :-)
>Changes to the tags will be as a result of changes to Struts and it requires
>an understanding of the internals of Struts to effectively support the tags.
>...
>
>
>
>>There could a
>>generic html library that didn't care about Struts, and then a
>>specialized one that utilized the Struts defaults. This strategy works
>>well for the Velocity Tools and should work just as well for taglibs.
>>
>>We keep saying that JSTL has no corollary to the html taglibs. Well,
>>maybe then it needs one. :) We moved BeanUtils and friends to Commons,
>>and I can't even count how many projects use these utilities now. Maybe
>>we should do the same with the html tags. The problems we are trying to
>>solve are the same problems everyone else is trying to solve. We shared
>>the wealth with Commons, maybe its time to do the same with Taglibs.
>>
>>
>
>That's a very definite possibility. If we can decouple the tags from Struts
>so that they could be used independently *then* it would make sense to treat
>them as a generic tag library. I would support moves in that direction, I
>just don't think they're ready to stand on their own two feet *yet*.
>
>
From the perspective of deciding this, it's useful to divide the
struts-html tags into two categories -- those that are just "translate
JSP tag attributes into corresponding markup" and those that are
dependent on Struts core internals. In the latter category, you'll
certainly find <html:form>, which has the machinery for automatic
creation of a form bean. Indirectly, then, you'll also find that all
the input field tags (button, cancel, checkbox, file, hidden, image,
multibox, password, radio, select, submit, text, textarea) are
dependent, because they depend on <html:form> to provide the base form
bean against which property names are resolved.
Less fundamental linkages, but real nevertheless, can be found in the
errors, link, and messages tags. That doesn't leave a whole lot.
Of course, the whole discussion of migrating tag libraries elsewhere is
totally academic unless there is someone who wants to *do* it instead of
just talk about it. In the absence of that, there's nothing wrong with
leaving them exactly where they are.
>
>
>>But, hey, I'm not a taglib guy, and I'm not going to be doing the work,
>>so it's not my decision. =:) I just want to be sure that them that does
>>the work and make the decisions are aware of their options.
>>
>>We scuttled Generic Datasource to get out of the Model business, and,
>>volunteers willing, maybe it's time to get out of the View business too.
>>
>>-Ted.
>>
>>
>
>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.
>
>
Agreed ... personally, I'm working on a different solution (than the
Struts html tag library) to that problem :-).
>Steve
>
>
Craig
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Standard HTML Tags (was Extending Standard Tags ...)
Posted by David Graham <gr...@yahoo.com>.
--- Nathan Bubna <na...@esha.com> wrote:
> Steve Raeburn said:
> > David Graham said:
> > > --- Steve Raeburn <sr...@apache.org> 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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Nathan Bubna <na...@esha.com>.
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
RE: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Steve Raeburn <sr...@apache.org>.
Sorry, excuse the formatting on that last message. I hope this is more
readable.
-----Original Message-----
From: Steve Raeburn [mailto:sraeburn@apache.org]
Sent: September 28, 2003 10:46 PM
To: Struts Developers List
Subject: RE: Standard HTML Tags (was Extending Standard Tags ...)
See below.
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: September 28, 2003 8:30 PM
> To: Struts Developers List
> Subject: Re: Standard HTML Tags (was Extending Standard Tags ...)
>
>
> > 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".
> > 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.
> > 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.
> > - 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.
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.
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. 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.
How would you suggest we include example applications without including at
least one view technology? 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?
Steve
>
> 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
Re: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Nathan Bubna <na...@esha.com>.
Steve Raeburn said:
> David Graham said:
> > --- Steve Raeburn <sr...@apache.org> 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 :).
> - 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. 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).
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
RE: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: September 28, 2003 1:51 PM
> To: Struts Developers List
> Subject: RE: Standard HTML Tags (was Extending Standard Tags ...)
>
> --- Steve Raeburn <sr...@apache.org> 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.
> 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.
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.
- 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.
- Medium to Long Term: JSF is probably going to be the way to go for the
view in JSP apps. A Jakarta/Struts Faces implementation would appear to fit
very well alongside the Struts controller framework.
Steve
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Standard HTML Tags (was Extending Standard Tags ...)
Posted by David Graham <gr...@yahoo.com>.
--- Steve Raeburn <sr...@apache.org> 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).
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.
David
>
> Steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Steve Raeburn <sr...@apache.org>.
I think I'm coming at this from a different perspective than you :-)
The acid test for me is whether you could sensibly create a Struts app
without using the tags (just talking JSP here). While you can get by without
bean or logic tags, I still feel that many of the html tags are *necessary*
for use in a Struts app.
More below...
-----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
...
> Jakarta Taglibs maintains a Dreamweaver extension, why could they not
> maintain a Struts extension?
They could but, because JSP is the most common view technology, I think
Struts would be diminished without the html tag library.
> Likewise, Jakarta Velocity maintains a Struts extension. Should we ask
> Nathan Bubna et al. to bring that here because it is dependent on Struts?
But it's also dependent on Velocity :-) I think the need arose from users of
Velocity wanting to use Struts rather than the other way round. I think it
probably adds more value to Velocity than Struts and, you've pointed out,
that's were the developers are.
> The new Commons Chain package supports extensions for Servlets,
> Portlets, and JavaServer Faces, which are technologies not maintained by
> the Chain team.
That's not really the same. Struts would depend on Chain, much as it now
depends on other commons packages. Chain is useful in many other situations
that don't include Struts. That's not *currently* the case for the taglibs.
My view is that Struts taglib (html) depends on Struts *and* Struts depends
on the tags. It's that co-dependency that leads me to think they should stay
together.
> IMHO, it's not a question of technology. It's a question of community
> support. If the people who actively maintain these tags wanted to
> maintain them at Jakarta Taglibs, there's no technical reason to keep
> them here. Conversely, there's no technical reason to move them either.
> It's just a matter of where the people doing the work want to do the work.
And I think that the Struts project is where the maintainers of the Struts
taglib are / will be :-)
Changes to the tags will be as a result of changes to Struts and it requires
an understanding of the internals of Struts to effectively support the tags.
...
> There could a
> generic html library that didn't care about Struts, and then a
> specialized one that utilized the Struts defaults. This strategy works
> well for the Velocity Tools and should work just as well for taglibs.
>
> We keep saying that JSTL has no corollary to the html taglibs. Well,
> maybe then it needs one. :) We moved BeanUtils and friends to Commons,
> and I can't even count how many projects use these utilities now. Maybe
> we should do the same with the html tags. The problems we are trying to
> solve are the same problems everyone else is trying to solve. We shared
> the wealth with Commons, maybe its time to do the same with Taglibs.
That's a very definite possibility. If we can decouple the tags from Struts
so that they could be used independently *then* it would make sense to treat
them as a generic tag library. I would support moves in that direction, I
just don't think they're ready to stand on their own two feet *yet*.
> But, hey, I'm not a taglib guy, and I'm not going to be doing the work,
> so it's not my decision. =:) I just want to be sure that them that does
> the work and make the decisions are aware of their options.
>
> We scuttled Generic Datasource to get out of the Model business, and,
> volunteers willing, maybe it's time to get out of the View business too.
>
> -Ted.
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.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Standard HTML Tags (was Extending Standard Tags ...)
Posted by Ted Husted <hu...@apache.org>.
Steve Raeburn wrote:
> I wasn't saying that the existing tags can't or shouldn't be extended. Just
> that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta
> Taglibs, because they are dependent on Struts.
Jakarta Taglibs maintains a Dreamweaver extension, why could they not
maintain a Struts extension?
Likewise, Jakarta Velocity maintains a Struts extension. Should we ask
Nathan Bubna et al. to bring that here because it is dependent on Struts?
The new Commons Chain package supports extensions for Servlets,
Portlets, and JavaServer Faces, which are technologies not maintained by
the Chain team.
IMHO, it's not a question of technology. It's a question of community
support. If the people who actively maintain these tags wanted to
maintain them at Jakarta Taglibs, there's no technical reason to keep
them here. Conversely, there's no technical reason to move them either.
It's just a matter of where the people doing the work want to do the work.
All things remaining equal, I'd suggest that the Struts taglibs are more
about taglibs then they are about Struts. They know how to find
resources provided by the Struts framework, but after that, virtually
all of the coding issues are related to the taglib and HTML
specifications, not to the Struts Controller.
When Geir and I bootstrapped the Velocity Tools for Struts initiative,
we did discuss whether it should be maintained here or there. In the
end, we decided that by maintaining the Tools at Velocity, they would be
exposed to the true Velocity experts, and that was a Good Thing. If
Struts were doing it's job, hooking up that end of it should be the easy
part. And it was.
By the time version 1.0 of Tools launched, there were multiple tools
sets: a generic set that could be used by most any web framework or
application, and a smaller set on top of that specialized to Struts. As
a result, the Tools are not only useful to Struts people, but now make
Velocity easier to use within other frameworks as well. [Now, *that's*
sharing the wealth :)]
From a community standpoint, most of the taglib support issues are not
about Struts, but about using taglibs generally. When JSTL and JSF
catches on, this is going to be more and more the case. Not only will we
have to support Struts, but we have to support JSTL and JSF as well.
And what do these tag libraries really do anyway? They look up resources
from predetermined locations, use them as parameters, and emit HTML.
Right now, many of the resource locations are hardwired to use the
Struts defaults. But, if they were exposed to a broader community, and
configurable factory methods were used, that could change. There could a
generic html library that didn't care about Struts, and then a
specialized one that utilized the Struts defaults. This strategy works
well for the Velocity Tools and should work just as well for taglibs.
We keep saying that JSTL has no corollary to the html taglibs. Well,
maybe then it needs one. :) We moved BeanUtils and friends to Commons,
and I can't even count how many projects use these utilities now. Maybe
we should do the same with the html tags. The problems we are trying to
solve are the same problems everyone else is trying to solve. We shared
the wealth with Commons, maybe its time to do the same with Taglibs.
But, hey, I'm not a taglib guy, and I'm not going to be doing the work,
so it's not my decision. =:) I just want to be sure that them that does
the work and make the decisions are aware of their options.
We scuttled Generic Datasource to get out of the Model business, and,
volunteers willing, maybe it's time to get out of the View business too.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Steve Raeburn <sr...@apache.org>.
Sorry, I don't understand your point, Vic.
I wasn't saying that the existing tags can't or shouldn't be extended. Just
that IMO the core Struts tags shouldn't be moved to somewhere like Jakarta
Taglibs, because they are dependent on Struts.
On the other hand, those tags that are general purpose and don't rely on
Struts can almost all be replaced with JSTL. Again, I don't think there is
any point moving them anywhere else, because they will probably just be
discontinued at some time in the future.
I think it's great that Matt and others have extended the Struts tags. (In
fact, Matt's calendar tag looks useful for something I'm working on now.) It
shows that it can be done and that not everything needs to be included in
the Struts distribution.
+1 for Variations :-)
Steve
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Vic Cekvenich
> Sent: September 27, 2003 9:04 PM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Extending Standard Tags was Editable Fields V/S Static Text
>
>
>
>
> Steve Raeburn wrote:
> > Many of the tags (basically those that have been implemented in
> struts-el)
> > are closely bound to Struts so I don't see that they belong
> anywhere else.
> > (Separate jar, yes. Separate cvs dir, probably). The remaining
> tags have a
> > limited shelf life, having been supesrseded by JSTL.
> >
>
> If I can disagre !with above; ex:
> http://www.mattkruse.com/javascript/javascripttoolbox.zip
>
> This exentds the HTML tag with .js emit.
> Variations are a frequent need.
> .V
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Vic Cekvenich <ce...@basebeans.com>.
Steve Raeburn wrote:
> Many of the tags (basically those that have been implemented in struts-el)
> are closely bound to Struts so I don't see that they belong anywhere else.
> (Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
> limited shelf life, having been superseded by JSTL.
>
If I can disagre !with above; ex:
http://www.mattkruse.com/javascript/javascripttoolbox.zip
This exentds the HTML tag with .js emit.
Variations are a frequent need.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Ted Husted <hu...@apache.org>.
Steve Raeburn wrote:
> While I'd probably be in favour of Struts becoming a top level
> project, I must confess I don't quite understand the criteria for
> becoming one.
It's mainly a question of whether the community surrounding the product
is mature enough to stand on its own and stay true to the Apache
principles of meritocracy and collaborative development. And also
whether that community wishes to be a top level project or not.
So, its *not* about the software product itself: it's about the
community that surrounds and supports the product.
In practice, we could stay at Jakarta and do all this. But, it's my
feeling that once you start talking about running subproducts that could
sustain a community of their own, then it's time to bite the bullet and
graduate to top-level.
> p.s. Jakarta Faces (or would it be Struts Faces?) would be an
> interesting subproject for a top level Struts. Then we'd be covering
> the V and the C.
If the people developing that product felt that way, then that would be
one way to go. But, IMHO, a JSF implementation has a broad enough scope
that it can easily justify a top-level project of its own.
Also, I believe that being under the Struts umbrella might stunt the
growth and acceptance of a product like this. There are frameworks other
than Struts that could use JSF, but if it's under our brand, many will
write it off as a "Struts thing". Sad, but true. Better, I think, to run
it under the Jakarta or Apache banner. But, as always, them that does
the work, make the decisions.
-Ted.
Steve Raeburn wrote:
> Many of the tags (basically those that have been implemented in struts-el)
> are closely bound to Struts so I don't see that they belong anywhere else.
> (Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
> limited shelf life, having been superseded by JSTL.
>
> I'd also like to see a separate cvs & distribution of optional packages.
>
> While I'd probably be in favour of Struts becoming a top level project, I
> must confess I don't quite understand the criteria for becoming one. Having
> Jakarta, XML, DB makes sense to me, but I don't get why Ant and Maven
> warrant top level projects (build tools?) or Cocoon (surely that fits in
> Jakarta?). If anyone has a clue, please let me know!
>
> Having said that, if it's a question of visibility, Struts certainly
> deserves to be recognized as a top level project and it would give us an
> opportunity to reorganize the code base and get more people and related
> projects on board.
>
> Steve
>
> p.s. Jakarta Faces (or would it be Struts Faces?) would be an interesting
> subproject for a top level Struts. Then we'd be covering the V and the C.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Steve Raeburn <sr...@apache.org>.
Many of the tags (basically those that have been implemented in struts-el)
are closely bound to Struts so I don't see that they belong anywhere else.
(Separate jar, yes. Separate cvs dir, probably). The remaining tags have a
limited shelf life, having been superseded by JSTL.
I'd also like to see a separate cvs & distribution of optional packages.
While I'd probably be in favour of Struts becoming a top level project, I
must confess I don't quite understand the criteria for becoming one. Having
Jakarta, XML, DB makes sense to me, but I don't get why Ant and Maven
warrant top level projects (build tools?) or Cocoon (surely that fits in
Jakarta?). If anyone has a clue, please let me know!
Having said that, if it's a question of visibility, Struts certainly
deserves to be recognized as a top level project and it would give us an
opportunity to reorganize the code base and get more people and related
projects on board.
Steve
p.s. Jakarta Faces (or would it be Struts Faces?) would be an interesting
subproject for a top level Struts. Then we'd be covering the V and the C.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: September 27, 2003 10:20 AM
> To: Struts Developers List
> Subject: Re: Extending Standard Tags was Editable Fields V/S Static Text
>
>
> Vic Cekvenich wrote:
> > (also IMO Struts HTML and tiles tag could/should migrate to taglibs)
>
> Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs,
> in the same way that the Struts View Tools are maintained by Velocity.
> Struts should make it as easy as possible for presentation technologies
> to hook up to the controller, so that the experts in that technology can
> provide the appropriate adapters for their platform.
>
> But Apache projects are not dumping grounds. To make it happen, a set of
> individuals deeply active in both Jakarta Taglibs and Jakarta Struts
> would have to step up and make the proposal to both communities.
>
> (Personally, I'd also like to see someone with an itch start the ball
> rolling on a Jakarta Faces product. The Sun distribution is apparently
> going to be closed source, and the SourceForge MyFaces project is using
> a restrictive license. Then the Struts-Faces taglib would also have a
> home among experts in that technology.)
>
> Alternatively, we should talk about setting up a series of "optional"
> Struts packages. So, rather than have things like Struts-Faces and
> Struts-el live in the nebulous contrib folder, they could live under
> org.apache.struts.opt.faces and *.opt.el. Likewise, there could be an
> *.opt.taglib. And at some point an opt.xls and maybe an opt.wml.
>
> If we followed the "optional" strategy, I'd also suggest we apply for
> status as a top-level Apache project, so that each of the opt packages
> could be a proper subproject, with its own CVS, set of Committers, and
> so forth.
>
> Though, personally, I'd prefer the idea of letting other Jakarta
> products do what they do best, so that Struts can focus on what it does
> best: provide the C in MVC.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Ted Husted <hu...@apache.org>.
Vic Cekvenich wrote:
> (also IMO Struts HTML and tiles tag could/should migrate to taglibs)
Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs,
in the same way that the Struts View Tools are maintained by Velocity.
Struts should make it as easy as possible for presentation technologies
to hook up to the controller, so that the experts in that technology can
provide the appropriate adapters for their platform.
But Apache projects are not dumping grounds. To make it happen, a set of
individuals deeply active in both Jakarta Taglibs and Jakarta Struts
would have to step up and make the proposal to both communities.
(Personally, I'd also like to see someone with an itch start the ball
rolling on a Jakarta Faces product. The Sun distribution is apparently
going to be closed source, and the SourceForge MyFaces project is using
a restrictive license. Then the Struts-Faces taglib would also have a
home among experts in that technology.)
Alternatively, we should talk about setting up a series of "optional"
Struts packages. So, rather than have things like Struts-Faces and
Struts-el live in the nebulous contrib folder, they could live under
org.apache.struts.opt.faces and *.opt.el. Likewise, there could be an
*.opt.taglib. And at some point an opt.xls and maybe an opt.wml.
If we followed the "optional" strategy, I'd also suggest we apply for
status as a top-level Apache project, so that each of the opt packages
could be a proper subproject, with its own CVS, set of Committers, and
so forth.
Though, personally, I'd prefer the idea of letting other Jakarta
products do what they do best, so that Struts can focus on what it does
best: provide the C in MVC.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Extending Standard Tags was Editable Fields V/S Static Text
Posted by Vic Cekvenich <ce...@basebeans.com>.
Sgarlata Matt wrote:
<SNIP> If my other
> suggestion of having the render() method call getters instead of directly
> accessing instance variables is used, then renderExtraAttributes() becomes
> more important. If it is not provided and someone wants to stick in some
> non-HTML 4.01 compliant HTML, what they will do is override something like
> the getSize() method so that it correctly renders the size and then sticks
> in the understandard HTML.
<SNIP
David Graham wrote:
<SNIP>
> I agree that the standard tags should be extendable to make
customizations
> easy. <SNIP>
If there is a way to make extending tags easier for rich tags....
displaytag, calendar tag, (tree tag is anyone knows one?)... it would be
very nice if they come more easier from CORE or HTML.
Just like people extend Action and ValidatorForm... it should be
encouraged that people extend tags to make them rich (and there is now
rich UI browser standard)
So please look upon kindley on how it can be made easier to exeetnd
"CORE" and HTML tags.
(also IMO Struts HTML and tiles tag could/should migrate to taglibs)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Sgarlata Matt <sg...@bah.com>.
----- Original Message -----
From: "David Graham" <gr...@yahoo.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Friday, September 26, 2003 1:02 AM
Subject: Re: Editable Fields V/S Static Text
>
> --- Robert Leland <rl...@apache.org> wrote:
> > David Graham wrote:
> >
> > >--- Sgarlata Matt <sg...@bah.com> wrote:
> > >
> > >
> > >>OK, here's another idea. I searched the archives for it and couldn't
> > >>find
> > >>it.
> > >>
> > >>How about two simple changes:
> > >>1) Add a new renderExtraAttributes() method that gives people the
> > chance
> > >>to
> > >>throw non-standard HTML into their tags that extend from Struts tags.
> > >>
> > >>
> > >
> > >I am -1 on the Struts tags supporting any non-standard HTML including
> > >providing the suggested hook method. Like Java itself, Struts aims to
> > be
> > >a cross-platform tool. Adding support for non-standard HTML undermines
> > >that goal and promotes non-interoperability.
> > >
> > >
> > Is it really the Struts tag library's mantra to dictate that the tags
> > should not be modified
> > externally to gain needed functionality ?
>
> I'm still not clear about this. What is the needed functionality that
> we're not providing?
The needed functionality is the ability to cleanly extend the Struts tags.
They tags are so good that when an application-specific requirement arises,
it's much more desirable to extend from the Struts tag and keep tie-ins with
ActionForms and such than it is to go off on your own.
> > By not providing hooks,
> > wheather these are the
> > correct ones or not, isn't very developer friendly. A framwork can be
> > developer friendly,
> > and well designed at the same time.
>
> I agree but hook methods that exist solely to help people write
> non-standard HTML aren't the way to go. Methods that perform a standard
> function that can be overridden are more appropriate IMO.
>
> >
> > And It's not that the tags would be producing non standard HTML 4.01,
> > it's that they would/could
> > add composite functionality over and above standard HTML that would
> > still be 4.01 compliant.
>
> What's an example of this?
I thought of a use case that *is* 4.01 compliant! I built an implementation
of Matt Kruse's JavaScript calendar widget based on the Struts tags a few
weeks before Matt made his own implementation, so I have some experience
doing this. As some brief background, the widget is a text box and a
corresponding calendar icon. When you click on the calendar icon a popup
appears where you can choose the date. When you click on the text box
(which is what overrides a Struts tag) you want onfocus to automatically
call this.blur() so that the user can't enter text into the textbox (that's
the calendar popup's job). So in my subclass it would be nice to override
the getOnfocus() method instead of overriding the entire
renderIForgetWhatItIsCalled() method.
Unfortunately I still can't think of a good HTML 4.01 compliant use case for
renderExtraAttributes(), but here is a weak try at it. If my other
suggestion of having the render() method call getters instead of directly
accessing instance variables is used, then renderExtraAttributes() becomes
more important. If it is not provided and someone wants to stick in some
non-HTML 4.01 compliant HTML, what they will do is override something like
the getSize() method so that it correctly renders the size and then sticks
in the understandard HTML. This is a nasty hack but you know a programmer
will choose that over duplicating an entire render() method.
I hope all this is clear, the threads are getting vicious here...
> David
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> David Graham wrote:
>
> >--- Sgarlata Matt <sg...@bah.com> wrote:
> >
> >
> >>OK, here's another idea. I searched the archives for it and couldn't
> >>find
> >>it.
> >>
> >>How about two simple changes:
> >>1) Add a new renderExtraAttributes() method that gives people the
> chance
> >>to
> >>throw non-standard HTML into their tags that extend from Struts tags.
> >>
> >>
> >
> >I am -1 on the Struts tags supporting any non-standard HTML including
> >providing the suggested hook method. Like Java itself, Struts aims to
> be
> >a cross-platform tool. Adding support for non-standard HTML undermines
> >that goal and promotes non-interoperability.
> >
> >
> Is it really the Struts tag library's mantra to dictate that the tags
> should not be modified
> externally to gain needed functionality ?
I'm still not clear about this. What is the needed functionality that
we're not providing?
> By not providing hooks,
> wheather these are the
> correct ones or not, isn't very developer friendly. A framwork can be
> developer friendly,
> and well designed at the same time.
I agree but hook methods that exist solely to help people write
non-standard HTML aren't the way to go. Methods that perform a standard
function that can be overridden are more appropriate IMO.
>
> And It's not that the tags would be producing non standard HTML 4.01,
> it's that they would/could
> add composite functionality over and above standard HTML that would
> still be 4.01 compliant.
What's an example of this?
David
>
> I agree with what several other committers, that if developers want to
> step up
> and show that they will help support those tags I'll vote for the
> ability to support these abilities,
> inside the struts tags not just the hooks.
>
> -Rob
>
>
>
> >I can't count the number of times I've been frustrated by webapps that
> >require a particular browser that I'm not using. I absolutely don't
> want
> >one of my favorite tools to support that kind of development.
> >
> >
> >
> >>Here
> >>is a snippet from BaseFieldTag.java:
> >>
> >><snip>
> >>results.append("\"");
> >>results.append(this.prepareEventHandlers());
> >>results.append(this.prepareStyles());
> >>results.append(this.getElementClose());
> >>
> >>
> >><matts-idea>
> >>results.append(renderExtraAttributes());
> >></matt-sidea>
> >>
> >>return results.toString();
> >></snip>
> >>
> >>The use cases for this are (a) to support the readonly attribute and
> >>
> >>
> >
> >At least the <html:text> tag already supports readonly. Are there
> other
> >tags (where readonly is allowed) that are missing it?
> >
> >http://jakarta.apache.org/struts/userGuide/struts-html.html#text
> >
> >David
> >
> >
> >
> >>(b)
> >>to
> >>support the "attributes" extension that was shot down for inclusion in
> >>the
> >>out-of-the-box Struts <html> tags.
> >>
> >>2) Instead of accessing instance variables directly, use getters.
> (I'm
> >>not
> >>sure if this will cause problems with the EL versions of tags...
> >>thoughts
> >>anyone?)
> >>
> >><snip>
> >>if (accept != null) {
> >> results.append(" accept=\"");
> >> //old way
> >> //results.append(accept);
> >> //new way
> >> results.append(getAccept());
> >> results.append("\"");
> >>}
> >></snip>
> >>
> >>If someone wanted to override the accept attribute so that it was
> always
> >>equal to foo then they would be able to do so. A better use case
> would
> >>be
> >>overriding the onclick method so that it does something special like
> >>display
> >>a calendar popup.
> >>
> >>I apologize in advance if this has been discussed before. ([OT] I
> >>really
> >>wish there was an easier way to search the archives. I have resorted
> to
> >>googling them, but it's still a pain.)
> >>
> >>Matt
> >>
>
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>--- Sgarlata Matt <sg...@bah.com> wrote:
>
>
>>OK, here's another idea. I searched the archives for it and couldn't
>>find
>>it.
>>
>>How about two simple changes:
>>1) Add a new renderExtraAttributes() method that gives people the chance
>>to
>>throw non-standard HTML into their tags that extend from Struts tags.
>>
>>
>
>I am -1 on the Struts tags supporting any non-standard HTML including
>providing the suggested hook method. Like Java itself, Struts aims to be
>a cross-platform tool. Adding support for non-standard HTML undermines
>that goal and promotes non-interoperability.
>
>
Is it really the Struts tag library's mantra to dictate that the tags
should not be modified
externally to gain needed functionality ? By not providing hooks,
wheather these are the
correct ones or not, isn't very developer friendly. A framwork can be
developer friendly,
and well designed at the same time.
And It's not that the tags would be producing non standard HTML 4.01,
it's that they would/could
add composite functionality over and above standard HTML that would
still be 4.01 compliant.
I agree with what several other committers, that if developers want to
step up
and show that they will help support those tags I'll vote for the
ability to support these abilities,
inside the struts tags not just the hooks.
-Rob
>I can't count the number of times I've been frustrated by webapps that
>require a particular browser that I'm not using. I absolutely don't want
>one of my favorite tools to support that kind of development.
>
>
>
>>Here
>>is a snippet from BaseFieldTag.java:
>>
>><snip>
>>results.append("\"");
>>results.append(this.prepareEventHandlers());
>>results.append(this.prepareStyles());
>>results.append(this.getElementClose());
>>
>>
>><matts-idea>
>>results.append(renderExtraAttributes());
>></matt-sidea>
>>
>>return results.toString();
>></snip>
>>
>>The use cases for this are (a) to support the readonly attribute and
>>
>>
>
>At least the <html:text> tag already supports readonly. Are there other
>tags (where readonly is allowed) that are missing it?
>
>http://jakarta.apache.org/struts/userGuide/struts-html.html#text
>
>David
>
>
>
>>(b)
>>to
>>support the "attributes" extension that was shot down for inclusion in
>>the
>>out-of-the-box Struts <html> tags.
>>
>>2) Instead of accessing instance variables directly, use getters. (I'm
>>not
>>sure if this will cause problems with the EL versions of tags...
>>thoughts
>>anyone?)
>>
>><snip>
>>if (accept != null) {
>> results.append(" accept=\"");
>> //old way
>> //results.append(accept);
>> //new way
>> results.append(getAccept());
>> results.append("\"");
>>}
>></snip>
>>
>>If someone wanted to override the accept attribute so that it was always
>>equal to foo then they would be able to do so. A better use case would
>>be
>>overriding the onclick method so that it does something special like
>>display
>>a calendar popup.
>>
>>I apologize in advance if this has been discussed before. ([OT] I
>>really
>>wish there was an easier way to search the archives. I have resorted to
>>googling them, but it's still a pain.)
>>
>>Matt
>>
Re: Editable Fields V/S Static Text
Posted by David Graham <gr...@yahoo.com>.
--- Sgarlata Matt <sg...@bah.com> wrote:
> OK, here's another idea. I searched the archives for it and couldn't
> find
> it.
>
> How about two simple changes:
> 1) Add a new renderExtraAttributes() method that gives people the chance
> to
> throw non-standard HTML into their tags that extend from Struts tags.
I am -1 on the Struts tags supporting any non-standard HTML including
providing the suggested hook method. Like Java itself, Struts aims to be
a cross-platform tool. Adding support for non-standard HTML undermines
that goal and promotes non-interoperability.
I can't count the number of times I've been frustrated by webapps that
require a particular browser that I'm not using. I absolutely don't want
one of my favorite tools to support that kind of development.
> Here
> is a snippet from BaseFieldTag.java:
>
> <snip>
> results.append("\"");
> results.append(this.prepareEventHandlers());
> results.append(this.prepareStyles());
> results.append(this.getElementClose());
>
>
> <matts-idea>
> results.append(renderExtraAttributes());
> </matt-sidea>
>
> return results.toString();
> </snip>
>
> The use cases for this are (a) to support the readonly attribute and
At least the <html:text> tag already supports readonly. Are there other
tags (where readonly is allowed) that are missing it?
http://jakarta.apache.org/struts/userGuide/struts-html.html#text
David
> (b)
> to
> support the "attributes" extension that was shot down for inclusion in
> the
> out-of-the-box Struts <html> tags.
>
> 2) Instead of accessing instance variables directly, use getters. (I'm
> not
> sure if this will cause problems with the EL versions of tags...
> thoughts
> anyone?)
>
> <snip>
> if (accept != null) {
> results.append(" accept=\"");
> //old way
> //results.append(accept);
> //new way
> results.append(getAccept());
> results.append("\"");
> }
> </snip>
>
> If someone wanted to override the accept attribute so that it was always
> equal to foo then they would be able to do so. A better use case would
> be
> overriding the onclick method so that it does something special like
> display
> a calendar popup.
>
> I apologize in advance if this has been discussed before. ([OT] I
> really
> wish there was an easier way to search the archives. I have resorted to
> googling them, but it's still a pain.)
>
> Matt
> ----- Original Message -----
> From: "Robert Leland" <rl...@apache.org>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> Sent: Thursday, September 25, 2003 1:41 PM
> Subject: Re: Editable Fields V/S Static Text
>
>
> > Sgarlata Matt wrote:
> >
> > >Has anyone ever discussed adding a general-purpose "attributes"
> attribute
> to
> > >the <html> tag library to support non-standard HTML like this? For
> example,
> > >
> > >
> > Yes, it was vetoed by several committers. Search the archives.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Sgarlata Matt <sg...@bah.com>.
OK, here's another idea. I searched the archives for it and couldn't find
it.
How about two simple changes:
1) Add a new renderExtraAttributes() method that gives people the chance to
throw non-standard HTML into their tags that extend from Struts tags. Here
is a snippet from BaseFieldTag.java:
<snip>
results.append("\"");
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());
<matts-idea>
results.append(renderExtraAttributes());
</matt-sidea>
return results.toString();
</snip>
The use cases for this are (a) to support the readonly attribute and (b) to
support the "attributes" extension that was shot down for inclusion in the
out-of-the-box Struts <html> tags.
2) Instead of accessing instance variables directly, use getters. (I'm not
sure if this will cause problems with the EL versions of tags... thoughts
anyone?)
<snip>
if (accept != null) {
results.append(" accept=\"");
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append("\"");
}
</snip>
If someone wanted to override the accept attribute so that it was always
equal to foo then they would be able to do so. A better use case would be
overriding the onclick method so that it does something special like display
a calendar popup.
I apologize in advance if this has been discussed before. ([OT] I really
wish there was an easier way to search the archives. I have resorted to
googling them, but it's still a pain.)
Matt
----- Original Message -----
From: "Robert Leland" <rl...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Thursday, September 25, 2003 1:41 PM
Subject: Re: Editable Fields V/S Static Text
> Sgarlata Matt wrote:
>
> >Has anyone ever discussed adding a general-purpose "attributes" attribute
to
> >the <html> tag library to support non-standard HTML like this? For
example,
> >
> >
> Yes, it was vetoed by several committers. Search the archives.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Robert Leland <rl...@apache.org>.
Sgarlata Matt wrote:
>Has anyone ever discussed adding a general-purpose "attributes" attribute to
>the <html> tag library to support non-standard HTML like this? For example,
>
>
Yes, it was vetoed by several committers. Search the archives.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by David Graham <gr...@yahoo.com>.
--- Sgarlata Matt <sg...@bah.com> wrote:
> Has anyone ever discussed adding a general-purpose "attributes"
> attribute to
> the <html> tag library to support non-standard HTML like this?
I'm -1 on any change to the tags that supports non-standard HTML.
David
> For
> example,
>
> <html:text property='something' attributes='readonly
> onclick="alert(\"hello\")\"'/>
>
> Obviously it is better to not include onclick on the attributes
> attribute,
> but I just included it as an example.
>
> Just a thought...
>
> Matt
> ----- Original Message -----
> From: "Robert Leland" <rl...@apache.org>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> Sent: Thursday, September 25, 2003 1:23 PM
> Subject: Re: Editable Fields V/S Static Text
>
>
> > Yes, This has been brought up many times over the last 3 years,
> > and probably has been implemented several times extending the Struts
> tags.
> >
> > I am not opposed to such a feature, and would support it,
> > though other committers might not.
> >
> > The key argument against it is that it would transform the html tags
> > into a non-standard
> > implementation. The html tags are ment to be a thin module aware layer
> > over the browsers tags,
> > and nothing more. That is why we don't have a Calender tag or Date
> > chooser tag.
> > Though I suppose if you really --knocked our socks off !-- with a
> spiffy
> > implementation it could
> > become part of Struts.
> >
> > I believe since we still support Netscape 4.X series browsers, a
> > read-only attribute has
> > not been added.
> >
> > Since struts is trying to get out of the JSP tag business since 40-50%
> > of our bugs are there.
> > which subtracts from our limited time for the core framework. You
> might
> > consider contributing
> > the tag to http://struts.sf.net
> >
> > -Rob
> >
> > Chris Gastin wrote:
> >
> > >Has anyone considered a feature which toggles between an editable
> form
> > >element and read only text / static text.
> > >
> > >I find myself developing JSPs where depending on the Use Case
> "fieldA"
> > >could be an editalbe text box (<input name="fieldA" value="My Text
> Value"
> > >/>) in Use Case 1 on xyz.jsp and readonly text /static text in Use
> Case
> 2
> > >(My Text Value) on the same jsp. Presently I am using the
> > ><logic:equal></logic:equal> tags. Which get really messy. Here is
> some
> > >sample code.
> > >
> > ><logic:equals name="actionForm" property="myFieldEditable"
> value="true">
> > > <html:text name="actionForm" property"myField" />
> > ></logic:equal>
> > ><logic:equals name="actionForm" property="myFieldEditable"
> value="false">
> > > <bean:write name="actionForm" property"myField" />
> > ></logic:equal>
> > >
> > >
> > >It would be nice to add an attribute to the current tag libraries,
> which
> is
> > >a boolean, and does this toggling for you. Here is what I am
> envisioning
> > >
> > >If actionForm.myField = "My Text Value"; This tag <html:text
> > >name="actionForm" property"myField" readOnlyText="true"/> would
> output
> "My
> > >Text Value".
> > >
> > >Where <html:text name="actionForm" property"myField"
> readOnlyText="false"/>
> > >the following tag would output
> > ><input name="fieldA" value="My Text Value" />
> > >
> > >As you can imagine this would not be a huge undertaking to add this
> feature
> > >to the current tag libraries in struts. I could use this feature, and
> I
> am
> > >sure other could too. I am willing to contribute my time to the
> development
> > >effort. I am not stuck on the attribute name "readOnlyText", and
> would
> > >welcome suggestions. Does this sound like a good idea, and if the
> answer
> is
> > >yes, what is the next step.
> > >
> > >Chris Gastin
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Sgarlata Matt <sg...@bah.com>.
Has anyone ever discussed adding a general-purpose "attributes" attribute to
the <html> tag library to support non-standard HTML like this? For example,
<html:text property='something' attributes='readonly
onclick="alert(\"hello\")\"'/>
Obviously it is better to not include onclick on the attributes attribute,
but I just included it as an example.
Just a thought...
Matt
----- Original Message -----
From: "Robert Leland" <rl...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Thursday, September 25, 2003 1:23 PM
Subject: Re: Editable Fields V/S Static Text
> Yes, This has been brought up many times over the last 3 years,
> and probably has been implemented several times extending the Struts tags.
>
> I am not opposed to such a feature, and would support it,
> though other committers might not.
>
> The key argument against it is that it would transform the html tags
> into a non-standard
> implementation. The html tags are ment to be a thin module aware layer
> over the browsers tags,
> and nothing more. That is why we don't have a Calender tag or Date
> chooser tag.
> Though I suppose if you really --knocked our socks off !-- with a spiffy
> implementation it could
> become part of Struts.
>
> I believe since we still support Netscape 4.X series browsers, a
> read-only attribute has
> not been added.
>
> Since struts is trying to get out of the JSP tag business since 40-50%
> of our bugs are there.
> which subtracts from our limited time for the core framework. You might
> consider contributing
> the tag to http://struts.sf.net
>
> -Rob
>
> Chris Gastin wrote:
>
> >Has anyone considered a feature which toggles between an editable form
> >element and read only text / static text.
> >
> >I find myself developing JSPs where depending on the Use Case "fieldA"
> >could be an editalbe text box (<input name="fieldA" value="My Text Value"
> >/>) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case
2
> >(My Text Value) on the same jsp. Presently I am using the
> ><logic:equal></logic:equal> tags. Which get really messy. Here is some
> >sample code.
> >
> ><logic:equals name="actionForm" property="myFieldEditable" value="true">
> > <html:text name="actionForm" property"myField" />
> ></logic:equal>
> ><logic:equals name="actionForm" property="myFieldEditable" value="false">
> > <bean:write name="actionForm" property"myField" />
> ></logic:equal>
> >
> >
> >It would be nice to add an attribute to the current tag libraries, which
is
> >a boolean, and does this toggling for you. Here is what I am envisioning
> >
> >If actionForm.myField = "My Text Value"; This tag <html:text
> >name="actionForm" property"myField" readOnlyText="true"/> would output
"My
> >Text Value".
> >
> >Where <html:text name="actionForm" property"myField"
readOnlyText="false"/>
> >the following tag would output
> ><input name="fieldA" value="My Text Value" />
> >
> >As you can imagine this would not be a huge undertaking to add this
feature
> >to the current tag libraries in struts. I could use this feature, and I
am
> >sure other could too. I am willing to contribute my time to the
development
> >effort. I am not stuck on the attribute name "readOnlyText", and would
> >welcome suggestions. Does this sound like a good idea, and if the answer
is
> >yes, what is the next step.
> >
> >Chris Gastin
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Robert Leland <rl...@apache.org>.
David Graham wrote:
>--- Robert Leland <rl...@apache.org> wrote:
>
>
>>Yes, This has been brought up many times over the last 3 years,
>>and probably has been implemented several times extending the Struts
>>tags.
>>
>>I am not opposed to such a feature, and would support it,
>>though other committers might not.
>>
>>The key argument against it is that it would transform the html tags
>>into a non-standard
>>implementation. The html tags are ment to be a thin module aware layer
>>over the browsers tags,
>>and nothing more. That is why we don't have a Calender tag or Date
>>chooser tag.
>>Though I suppose if you really --knocked our socks off !-- with a spiffy
>>
>>implementation it could
>>become part of Struts.
>>
>>I believe since we still support Netscape 4.X series browsers, a
>>read-only attribute has
>>not been added.
>>
>>
>
>As you know, we don't support browsers we support standard specifications.
>
>
Yes, and the decisions on what specfication to support relies largely on
what browsers are out there.
Since we last talked about this Mozilla 1.X has been released which
supports the read-only attribute
so users on Unix systems can benefit from its use. Best of all large
slow moving corporations, Goverments,
with Unix systems to support are moving Mozilla/Netscape 6.2 as a
standard. So I it seems that having
this workaround isn't as needed as it once was.
Now if we could only get rid of all the JSP 1.1/Servlet 2.2 containers
so struts can move to supporting
JSP 1.2/Servlet 2.3..
-Rob
>
>
>The tags are coded to the XHTML 1.0 and HTML 4.01 standards which do
>support a readonly attribute on input fields. The <html:text> tag
>supports a readonly attribute which seems to be the easiest way to
>accomplish the requested feature.
>
>http://jakarta.apache.org/struts/userGuide/struts-html.html#text
>
>
Re: Editable Fields V/S Static Text
Posted by David Graham <gr...@yahoo.com>.
--- Robert Leland <rl...@apache.org> wrote:
> Yes, This has been brought up many times over the last 3 years,
> and probably has been implemented several times extending the Struts
> tags.
>
> I am not opposed to such a feature, and would support it,
> though other committers might not.
>
> The key argument against it is that it would transform the html tags
> into a non-standard
> implementation. The html tags are ment to be a thin module aware layer
> over the browsers tags,
> and nothing more. That is why we don't have a Calender tag or Date
> chooser tag.
> Though I suppose if you really --knocked our socks off !-- with a spiffy
>
> implementation it could
> become part of Struts.
>
> I believe since we still support Netscape 4.X series browsers, a
> read-only attribute has
> not been added.
As you know, we don't support browsers we support standard specifications.
The tags are coded to the XHTML 1.0 and HTML 4.01 standards which do
support a readonly attribute on input fields. The <html:text> tag
supports a readonly attribute which seems to be the easiest way to
accomplish the requested feature.
http://jakarta.apache.org/struts/userGuide/struts-html.html#text
David
>
> Since struts is trying to get out of the JSP tag business since 40-50%
> of our bugs are there.
> which subtracts from our limited time for the core framework. You might
> consider contributing
> the tag to http://struts.sf.net
>
> -Rob
>
> Chris Gastin wrote:
>
> >Has anyone considered a feature which toggles between an editable form
> >element and read only text / static text.
> >
> >I find myself developing JSPs where depending on the Use Case "fieldA"
> >could be an editalbe text box (<input name="fieldA" value="My Text
> Value"
> >/>) in Use Case 1 on xyz.jsp and readonly text /static text in Use
> Case 2
> >(My Text Value) on the same jsp. Presently I am using the
> ><logic:equal></logic:equal> tags. Which get really messy. Here is some
> >sample code.
> >
> ><logic:equals name="actionForm" property="myFieldEditable"
> value="true">
> > <html:text name="actionForm" property"myField" />
> ></logic:equal>
> ><logic:equals name="actionForm" property="myFieldEditable"
> value="false">
> > <bean:write name="actionForm" property"myField" />
> ></logic:equal>
> >
> >
> >It would be nice to add an attribute to the current tag libraries,
> which is
> >a boolean, and does this toggling for you. Here is what I am
> envisioning
> >
> >If actionForm.myField = "My Text Value"; This tag <html:text
> >name="actionForm" property"myField" readOnlyText="true"/> would output
> "My
> >Text Value".
> >
> >Where <html:text name="actionForm" property"myField"
> readOnlyText="false"/>
> >the following tag would output
> ><input name="fieldA" value="My Text Value" />
> >
> >As you can imagine this would not be a huge undertaking to add this
> feature
> >to the current tag libraries in struts. I could use this feature, and I
> am
> >sure other could too. I am willing to contribute my time to the
> development
> >effort. I am not stuck on the attribute name "readOnlyText", and would
> >welcome suggestions. Does this sound like a good idea, and if the
> answer is
> >yes, what is the next step.
> >
> >Chris Gastin
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Editable Fields V/S Static Text
Posted by Robert Leland <rl...@apache.org>.
Yes, This has been brought up many times over the last 3 years,
and probably has been implemented several times extending the Struts tags.
I am not opposed to such a feature, and would support it,
though other committers might not.
The key argument against it is that it would transform the html tags
into a non-standard
implementation. The html tags are ment to be a thin module aware layer
over the browsers tags,
and nothing more. That is why we don't have a Calender tag or Date
chooser tag.
Though I suppose if you really --knocked our socks off !-- with a spiffy
implementation it could
become part of Struts.
I believe since we still support Netscape 4.X series browsers, a
read-only attribute has
not been added.
Since struts is trying to get out of the JSP tag business since 40-50%
of our bugs are there.
which subtracts from our limited time for the core framework. You might
consider contributing
the tag to http://struts.sf.net
-Rob
Chris Gastin wrote:
>Has anyone considered a feature which toggles between an editable form
>element and read only text / static text.
>
>I find myself developing JSPs where depending on the Use Case "fieldA"
>could be an editalbe text box (<input name="fieldA" value="My Text Value"
>/>) in Use Case 1 on xyz.jsp and readonly text /static text in Use Case 2
>(My Text Value) on the same jsp. Presently I am using the
><logic:equal></logic:equal> tags. Which get really messy. Here is some
>sample code.
>
><logic:equals name="actionForm" property="myFieldEditable" value="true">
> <html:text name="actionForm" property"myField" />
></logic:equal>
><logic:equals name="actionForm" property="myFieldEditable" value="false">
> <bean:write name="actionForm" property"myField" />
></logic:equal>
>
>
>It would be nice to add an attribute to the current tag libraries, which is
>a boolean, and does this toggling for you. Here is what I am envisioning
>
>If actionForm.myField = "My Text Value"; This tag <html:text
>name="actionForm" property"myField" readOnlyText="true"/> would output "My
>Text Value".
>
>Where <html:text name="actionForm" property"myField" readOnlyText="false"/>
>the following tag would output
><input name="fieldA" value="My Text Value" />
>
>As you can imagine this would not be a huge undertaking to add this feature
>to the current tag libraries in struts. I could use this feature, and I am
>sure other could too. I am willing to contribute my time to the development
>effort. I am not stuck on the attribute name "readOnlyText", and would
>welcome suggestions. Does this sound like a good idea, and if the answer is
>yes, what is the next step.
>
>Chris Gastin
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org