RE: Extending Standard Tags was Editable Fields V/S Static Text

[Steve Raeburn]

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:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
> Sent: September 27, 2003 9:04 PM
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extending Standard Tags was Editable Fields V/S Static Text

[Vic Cekvenich]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extending Standard Tags was Editable Fields V/S Static Text

[Ted Husted]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Extending Standard Tags was Editable Fields V/S Static Text

[Steve Raeburn]

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:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extending Standard Tags was Editable Fields V/S Static Text

[Ted Husted]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extending Standard Tags was Editable Fields V/S Static Text

[Vic Cekvenich]

Sgarlata Matt wrote:
  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.  


David Graham wrote:

> I agree that the standard tags should be extendable to make 
customizations
> easy.  

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Graham Leggett]

Edgar P Dollin wrote:

1) It is fine that the basic tags in struts don't emit non-standard html,
but why do struts tags have to 'police' the emission of non-html.  For many
intranet style projects, non standard html is important to achieve specific
required functionality.  To deny the need for such code seems strange.
I personally don't see why intranet applications should be exempt from 
following the same standards as internet applications - "breaking" 
standards out of convenience is not a good design practice.

The enforcement of standards by struts allows me the system architect to 
be certain that I am "doing the right thing" from a design perspective. 
And from a customer perspective, I don't want my intranet applications 
breaking because I upgraded from IE v6 to IE v7, now the custom little 
hacks I put in that worked in IE v6 suddenly don't work in IE v7.

2) It baffles my mind why struts insists the tags be so minimalistic and
non-creative.
To me, minimalism is another way of describing simplicity, and 
simplicity allows me to be more creative. From an art sense, simple is 
good :)

Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Craig R. McClanahan]

 still three years ago, or if JavaServer Faces didn't exist, 
then I'd be in hearty agreement with you that Struts should focus on 
improving the HTML tag library.  Neither of those is the case, however; 
so, in the time *I* have to devote to Struts, it's going to be spent on 
other things.

3) Lastly, there are certain class of business information that the view
needs, i.e. readonly, size.  The tags should have to ability to easily pass
this information from the business tier to the view.  Again, the hope of a
submission relating to this type of extension being accepted seems iffy,
especially since generalizing a specific implementation is a bit of effort.
 

I'd need to see a more detailed description of what you're thinking 
about to know whether it would fit in, but I assume you're talking about 
something more than the "disabled" and "readonly" attributes that 
already exist?

Edgar
 

Craig

 

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 26, 2003 5:07 PM
To: Struts Developers List
Subject: Re: Editable Fields V/S Static Text

David Graham wrote:
   

There are 3 things that earn my -1 on tag enhancements:
1.  Functionality already provided by the JSTL.
 

Just as an aside, I believe by -1 David means that he won't volunteer 
his own time to the issue. As a volunteer, this is his 
absolute right. 
But, since the Struts minimum platform doesn't support JSTL, 
this point 
alone would not be a justification for a "product change" veto.

   

2.  Functionality that supports non-standard HTML 
 

generation. 3.  Tags 
   

that don't tie into the Struts core functionality.  These 
 

are better 
   

suited for the Jakarta Taglibs project.
 

However, IMHO, these would be technical justifications for a 
-1 veto =:)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Ted Husted]

In the beginning, there was no Jakarta Taglibs, or inkling of something 
like JSTL. So, Craig bravely put together a useful implementation of 
some custom tags that did two things. First, they exposed the internals 
of the Struts Controller framework. Second, they provided some basic 
functionality so that people could get along without restoring to 
scriplets for everything.

Since that time, the need for Struts to provide basic tag functionality 
has withered away. The Jakarta Taglibs project thrives, JSTL has long 
since shipped, and JSF is late early release (to coin an oxymoron). 
Struts doesn't have to showcase taglibs as a proof of concept anymore.

Personally, I favor the idea that the original html taglib, and friends, 
should be continue to be maintain and improved. A lot of people just 
don't have access to the JSTL yet. But, we don't want to be in the 
datasource business anymore, and we don't want to be in the *generic* 
taglib  business anymore either. There are other places where such 
things can be done better than we can do them here.

Some good examples of people doing this already are Struts Layout 

and Struts Menu
.

If someone is not up to starting their own project, I'm sure the Struts 
SourceForge crew would also be open to Struts-related taglibs being 
hosted there.

What baffles us is the feeling that absolutely everything has to be part 
of the core framework. If people have tag implementations they want to 
share, there are many places where this can be done.

-Ted.

Edgar P Dollin wrote:
For the first time in many months, there was some visible progress in the
area of acceptance of submissions on tags.  Thank you David and Robert.
I do have some points that I am sure will draw fire, but I have been an
idiot on this forum for so long...
1) It is fine that the basic tags in struts don't emit non-standard html,
but why do struts tags have to 'police' the emission of non-html.  For many
intranet style projects, non standard html is important to achieve specific
required functionality.  To deny the need for such code seems strange.
2) It baffles my mind why struts insists the tags be so minimalistic and
non-creative.  I am aware of the difficulties in writing tags with the weird
life span and semi random instantiation patterns and the bugs that are
almost endemic with custom tags.  But simple tags like java-script assisted
date entry are so basic that simple implementations should be part of
struts.  Many of us have implementations of this (i.e. Matt Kruse's date
functions) but there would be no hope of a submission passing muster.
3) Lastly, there are certain class of business information that the view
needs, i.e. readonly, size.  The tags should have to ability to easily pass
this information from the business tier to the view.  Again, the hope of a
submission relating to this type of extension being accepted seems iffy,
especially since generalizing a specific implementation is a bit of effort.
Edgar


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Sgarlata Matt]

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 26, 2003 1:02 AM
Subject: Re: Editable Fields V/S Static Text


>
> --- Robert Leland <[EMAIL PROTECTED]> wrote:
> > David Graham wrote:
> >
> > >--- Sgarlata Matt <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Ted Husted]

Sgarlata Matt wrote:
Of course if I really want that I should probably just use
Velocity, huh? ;)
+1. I do =:)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Sgarlata Matt <[EMAIL PROTECTED]> wrote:
> - Original Message - 
> From: "David Graham" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Friday, September 26, 2003 7:52 PM
> Subject: Re: Editable Fields V/S Static Text
> > > However, at this time, we have a Struts-el taglib in circulation. We
> > > even have a Struts-faces taglib in the wings. We've definately
> reached
> > > the point where the JSTL has to sink or swim on its own. If the
> > > Community wants to use the tags, then we are bound to facilitate
> that
> > > any way we can. Standards are essential, but community-building is
> the
> > > Apache prime directive, and a large segment of our community is
> still
> > > locked out of the JCP JSTL standard.
> >
> > It would be neat to build tags that extend JSTL functionality to fill
> in
> > gaps left by the standard.  Let the JSTL do the heavy lifting and add
> on
> > as necessary.
> 
> I think this is the mandate of the taglibs-unstandard tag library, which
> is
> still in the sandbox.  

I was referring more to something like changing  into an
extension of  that supports references to Struts actions.  In
general, adding Struts support to the standard tags.

> I like the tags I see there a lot, particularly
>  and , although I think the tags could
> definitely
> use some work.  The documentation is awful and last time I looked
>  couldn't invoke methods with parameters (it could only
> invoke
> methods without parameters).  I would love to see some of the power of
> Velocity put into JSP taglibs, like the ability to use the EL-like
> syntax to
> invoke methods.  Of course if I really want that I should probably just
> use
> Velocity, huh? ;)
> 
> Of course at a certain point you have basically eliminated the advantage
> of
> removing scriptlet code because your JSP tags are so sophisticated, but
> in
> my opinion the JSTL is a lot easier to use than scriptlets because it's
> easier to get at things in the pageContext, request, etc. and on the
> presentation tier you often don't care about data types.

I couldn't agree more.

David

> 
> Matt
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[David Graham]

--- Edgar P Dollin <[EMAIL PROTECTED]> wrote:
> For the first time in many months, there was some visible progress in
> the
> area of acceptance of submissions on tags.  Thank you David and Robert.
> 
> I do have some points that I am sure will draw fire, but I have been an
> idiot on this forum for so long...
> 
> 1) It is fine that the basic tags in struts don't emit non-standard
> html,
> but why do struts tags have to 'police' the emission of non-html.  For
> many
> intranet style projects, non standard html is important to achieve
> specific
> required functionality.  To deny the need for such code seems strange.

I agree that the standard tags should be extendable to make customizations
easy.  What I take issue with is functionality designed expressly for
creating non-portable applications such as the hook methods suggested
earlier.  Non-standard HTML should be considered a crime against humanity
:-).

> 
> 2) It baffles my mind why struts insists the tags be so minimalistic and
> non-creative.  I am aware of the difficulties in writing tags with the
> weird
> life span and semi random instantiation patterns and the bugs that are
> almost endemic with custom tags.  

You just answered your own question :-).

> But simple tags like java-script
> assisted
> date entry are so basic that simple implementations should be part of
> struts.  Many of us have implementations of this (i.e. Matt Kruse's date
> functions) but there would be no hope of a submission passing muster.

Do these tags tie into Struts core functionality?  If not, they are great
candidates for the Jakarta Taglib project.  IMO, tags that help the view
talk to Struts (like the html taglib) are suited for the standard tags
distro.

> 
> 3) Lastly, there are certain class of business information that the view
> needs, i.e. readonly, size.  The tags should have to ability to easily
> pass
> this information from the business tier to the view.  Again, the hope of
> a
> submission relating to this type of extension being accepted seems iffy,
> especially since generalizing a specific implementation is a bit of
> effort.

This is a larger problem than just custom tags.  You would need an xml
description of your forms that we currently don't have the framework to
support.  Ted has mentioned something similar to this before.

David

> 
> Edgar
> 
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, September 26, 2003 5:07 PM
> > To: Struts Developers List
> > Subject: Re: Editable Fields V/S Static Text
> > 
> > 
> > David Graham wrote:
> > > There are 3 things that earn my -1 on tag enhancements:
> > > 1.  Functionality already provided by the JSTL.
> > 
> > Just as an aside, I believe by -1 David means that he won't volunteer 
> > his own time to the issue. As a volunteer, this is his 
> > absolute right. 
> > But, since the Struts minimum platform doesn't support JSTL, 
> > this point 
> > alone would not be a justification for a "product change" veto.
> > 
> > > 2.  Functionality that supports non-standard HTML 
> > generation. 3.  Tags 
> > > that don't tie into the Struts core functionality.  These 
> > are better 
> > > suited for the Jakarta Taglibs project.
> > 
> > However, IMHO, these would be technical justifications for a 
> > -1 veto =:)
> > 
> > -Ted.
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Sgarlata Matt]

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 26, 2003 7:52 PM
Subject: Re: Editable Fields V/S Static Text
> > However, at this time, we have a Struts-el taglib in circulation. We
> > even have a Struts-faces taglib in the wings. We've definately reached
> > the point where the JSTL has to sink or swim on its own. If the
> > Community wants to use the tags, then we are bound to facilitate that
> > any way we can. Standards are essential, but community-building is the
> > Apache prime directive, and a large segment of our community is still
> > locked out of the JCP JSTL standard.
>
> It would be neat to build tags that extend JSTL functionality to fill in
> gaps left by the standard.  Let the JSTL do the heavy lifting and add on
> as necessary.

I think this is the mandate of the taglibs-unstandard tag library, which is
still in the sandbox.  I like the tags I see there a lot, particularly
 and , although I think the tags could definitely
use some work.  The documentation is awful and last time I looked
 couldn't invoke methods with parameters (it could only invoke
methods without parameters).  I would love to see some of the power of
Velocity put into JSP taglibs, like the ability to use the EL-like syntax to
invoke methods.  Of course if I really want that I should probably just use
Velocity, huh? ;)

Of course at a certain point you have basically eliminated the advantage of
removing scriptlet code because your JSP tags are so sophisticated, but in
my opinion the JSTL is a lot easier to use than scriptlets because it's
easier to get at things in the pageContext, request, etc. and on the
presentation tier you often don't care about data types.

> David

Matt


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Chris Gastin wrote:
>  > As I can tell from the list I have opened topic that is pretty well
>  > beaten. Let me first apologize.  I did not realize this was such a
>  > political topic in the Struts community.
> 
> There was a time when we were encouraging people to use the JSTL, and 
> there was a political bent to some of the encouragement. We were 
> concerned that the popularity of the Struts tags would cause a schism 
> and slow the adoption of a new JCP standard. The Apache Software 
> Foundation and Struts have always been ardent supporters of standards, 
> and so we did not want to further the Struts tags at the expense of the 
> JSTL.

That has never been why I've promoted the JSTL over Struts and I really
never considered that reason until now.  I just really like the JSTL tags.

> 
> However, at this time, we have a Struts-el taglib in circulation. We 
> even have a Struts-faces taglib in the wings. We've definately reached 
> the point where the JSTL has to sink or swim on its own. If the 
> Community wants to use the tags, then we are bound to facilitate that 
> any way we can. Standards are essential, but community-building is the 
> Apache prime directive, and a large segment of our community is still 
> locked out of the JCP JSTL standard.

It would be neat to build tags that extend JSTL functionality to fill in
gaps left by the standard.  Let the JSTL do the heavy lifting and add on
as necessary.

David

> 
> Problem is, none of the active Committers seem to be using the old tags 
> anymore, and so we are reaching out for new blood
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar
> 
> -Ted.
> 
> Chris Gastin wrote:
> > As I can tell from the list I have opened topic that is pretty well
> beaten.
> > Let me first apologize.  I did not realize this was such a political
> topic
> > in the Struts community.
> > 
> > I am starting to think that there should be some sort of Struts Tag
> Lib
> > Extensions, which would address some of these issues while being
> totally
> > separate from the Struts project. I am starting to agree with David I
> don't
> > want to polute Struts with non standard HTML, but it would be nice to
> have
> > an add on module which is dependant on Struts that could give users
> the
> > functionality which it seems that other are requesting. I am willing
> > contribute to this effort.
> > 
> > I did not realize there were so many bugs for the taglibs, which some
> of you
> > pointed out. I will see if I can help out. I will check out bugzilla,
> and
> > try to contribute in that area.
> > 
> > Chris Gastin
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[Edgar P Dollin]

For the first time in many months, there was some visible progress in the
area of acceptance of submissions on tags.  Thank you David and Robert.

I do have some points that I am sure will draw fire, but I have been an
idiot on this forum for so long...

1) It is fine that the basic tags in struts don't emit non-standard html,
but why do struts tags have to 'police' the emission of non-html.  For many
intranet style projects, non standard html is important to achieve specific
required functionality.  To deny the need for such code seems strange.

2) It baffles my mind why struts insists the tags be so minimalistic and
non-creative.  I am aware of the difficulties in writing tags with the weird
life span and semi random instantiation patterns and the bugs that are
almost endemic with custom tags.  But simple tags like java-script assisted
date entry are so basic that simple implementations should be part of
struts.  Many of us have implementations of this (i.e. Matt Kruse's date
functions) but there would be no hope of a submission passing muster.

3) Lastly, there are certain class of business information that the view
needs, i.e. readonly, size.  The tags should have to ability to easily pass
this information from the business tier to the view.  Again, the hope of a
submission relating to this type of extension being accepted seems iffy,
especially since generalizing a specific implementation is a bit of effort.

Edgar

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> Sent: Friday, September 26, 2003 5:07 PM
> To: Struts Developers List
> Subject: Re: Editable Fields V/S Static Text
> 
> 
> David Graham wrote:
> > There are 3 things that earn my -1 on tag enhancements:
> > 1.  Functionality already provided by the JSTL.
> 
> Just as an aside, I believe by -1 David means that he won't volunteer 
> his own time to the issue. As a volunteer, this is his 
> absolute right. 
> But, since the Struts minimum platform doesn't support JSTL, 
> this point 
> alone would not be a justification for a "product change" veto.
> 
> > 2.  Functionality that supports non-standard HTML 
> generation. 3.  Tags 
> > that don't tie into the Struts core functionality.  These 
> are better 
> > suited for the Jakarta Taglibs project.
> 
> However, IMHO, these would be technical justifications for a 
> -1 veto =:)
> 
> -Ted.
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Ted Husted]

David Graham wrote:
There are 3 things that earn my -1 on tag enhancements:
1.  Functionality already provided by the JSTL.
Just as an aside, I believe by -1 David means that he won't volunteer 
his own time to the issue. As a volunteer, this is his absolute right. 
But, since the Struts minimum platform doesn't support JSTL, this point 
alone would not be a justification for a "product change" veto.

2.  Functionality that supports non-standard HTML generation.
3.  Tags that don't tie into the Struts core functionality.  These are
better suited for the Jakarta Taglibs project.
However, IMHO, these would be technical justifications for a -1 veto =:)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Ted Husted]

Chris Gastin wrote:
> As I can tell from the list I have opened topic that is pretty well
> beaten. Let me first apologize.  I did not realize this was such a
> political topic in the Struts community.
There was a time when we were encouraging people to use the JSTL, and 
there was a political bent to some of the encouragement. We were 
concerned that the popularity of the Struts tags would cause a schism 
and slow the adoption of a new JCP standard. The Apache Software 
Foundation and Struts have always been ardent supporters of standards, 
and so we did not want to further the Struts tags at the expense of the 
JSTL.

However, at this time, we have a Struts-el taglib in circulation. We 
even have a Struts-faces taglib in the wings. We've definately reached 
the point where the JSTL has to sink or swim on its own. If the 
Community wants to use the tags, then we are bound to facilitate that 
any way we can. Standards are essential, but community-building is the 
Apache prime directive, and a large segment of our community is still 
locked out of the JCP JSTL standard.

Problem is, none of the active Committers seem to be using the old tags 
anymore, and so we are reaching out for new blood

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar

-Ted.

Chris Gastin wrote:
As I can tell from the list I have opened topic that is pretty well beaten.
Let me first apologize.  I did not realize this was such a political topic
in the Struts community.
I am starting to think that there should be some sort of Struts Tag Lib
Extensions, which would address some of these issues while being totally
separate from the Struts project. I am starting to agree with David I don't
want to polute Struts with non standard HTML, but it would be nice to have
an add on module which is dependant on Struts that could give users the
functionality which it seems that other are requesting. I am willing
contribute to this effort.
I did not realize there were so many bugs for the taglibs, which some of you
pointed out. I will see if I can help out. I will check out bugzilla, and
try to contribute in that area.
Chris Gastin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> 
> >--- Sgarlata Matt <[EMAIL PROTECTED]> 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:
> >>
> >>
> >>results.append("\"");
> >>results.append(this.prepareEventHandlers());
> >>results.append(this.prepareStyles());
> >>results.append(this.getElementClose());
> >>
> >>
> >>
> >>results.append(renderExtraAttributes());
> >>
> >>
> >>return results.toString();
> >>
> >>
> >>The use cases for this are (a) to support the readonly attribute and 
> >>
> >>
> >
> >At least the  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  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?)
> >>
> >>
> >>if (accept != null) {
> >>results.append(" accept=\"");
> >>//old way
> >>//results.append(accept);
> >>//new way
> >>results.append(getAccept());
> >>results.append("\"");
> >>}
> >>
> >>
> >>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Chris Gastin <[EMAIL PROTECTED]> wrote:
> As I can tell from the list I have opened topic that is pretty well
> beaten.
> Let me first apologize.  I did not realize this was such a political
> topic
> in the Struts community.

I wouldn't describe anything in Struts as political.  We've all openly
stated our opinions and reasoning.

> 
> I am starting to think that there should be some sort of Struts Tag Lib
> Extensions, which would address some of these issues while being totally
> separate from the Struts project. I am starting to agree with David I
> don't
> want to polute Struts with non standard HTML, but it would be nice to
> have
> an add on module which is dependant on Struts that could give users the
> functionality which it seems that other are requesting. I am willing
> contribute to this effort.
> 
> I did not realize there were so many bugs for the taglibs, which some of
> you
> pointed out. I will see if I can help out. I will check out bugzilla,
> and
> try to contribute in that area.

I ran an informal bugzilla report a while back that indicated a large
percentage of our total historical bugs are custom tag related.  I don't
remember the exact number but it was between 25% and 50%.  This is one
reason I don't think duplicating JSTL functionality is a good idea.

David

> 
> Chris Gastin
> 
> - Original Message - 
> From: "David Graham" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, September 25, 2003 3:39 PM
> Subject: RE: Editable Fields V/S Static Text
> 
> 
> >
> > --- Edgar P Dollin <[EMAIL PROTECTED]> wrote:
> > > I think it is more than a 'preference' based on the rapidity with
> which
> > > INVALID or WONTFIX is stamped on tag suggestions and patches.
> >
> > I can't speak for anyone else but here is my view on the tags:
> >
> > There are 3 things that earn my -1 on tag enhancements:
> > 1.  Functionality already provided by the JSTL.
> > 2.  Functionality that supports non-standard HTML generation.
> > 3.  Tags that don't tie into the Struts core functionality.  These are
> > better suited for the Jakarta Taglibs project.
> >
> > I'm personally open to other tag enhancements.  If you check cvs,
> you'll
> > see that I have volunteered some time at refactoring and enhancing the
> > tags.
> >
> > Whenever tag extendability enhancements are discussed, we always hear
> > complaints from a vocal minority but no tested working patches show
> up.  I
> > haven't heard any good suggestions that would make the tags easier to
> > subclass.  If the current factoring isn't good enough, provide patches
> for
> > something better.
> >
> > The fact is that the current tags work great for my needs so I'm not
> > motivated to spend a bunch of time pondering some ultimate
> extendability
> > framework.  There's not much we can do without use cases and patches.
> >
> > David
> >
> > >
> > > Perhaps it would be best if the tags were cut loose from struts and
> a
> > > different group of committers were responsible for them.  I
> wouldn't,
> > > nor
> > > would I expect anyone else interested in the tags to make any time
> > > commitment with the current 'RULES' placed on the tags, i.e. ONLY
> emit
> > > HTML
> > > 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc.
> > >
> > > Edgar
> > >
> > > > -Original Message-
> > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, September 25, 2003 2:23 PM
> > > > To: Struts Developers List
> > > > Subject: Re: Editable Fields V/S Static Text
> > > >
> > > >
> > > > It's only a "political football" in the sense that most of
> > > > the current
> > > > committers would prefer not to work on the HTML tags.  If other
> folks
> > > > came to the fore and committed themselves to supporting those
> tags,
> > > > including writing unit tests and answering questions on the
> > > > user list, I
> > > > don't think you would see much opposition to development in
> > > > that area -- 
> > > > along with an eventual nomination for committer status for the
> > > > individuals involved so that they can do their work directly.
> > > >
> > > > Asking the existing co

Re: Editable Fields V/S Static Text

[Robert Leland]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Chris Gastin]

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" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 25, 2003 9:43 PM
Subject: Re: Editable Fields V/S Static Text


> David Graham wrote:
>
> >--- Sgarlata Matt <[EMAIL PROTECTED]> 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:
> >>
> >>
> >>results.append("\"");
> >>results.append(this.prepareEventHandlers());
> >>results.append(this.prepareStyles());
> >>results.append(this.getElementClose());
> >>
> >>
> >>
> >>results.append(renderExtraAttributes());
> >>
> >>
> >>return results.toString();
> >>
> >>
> >>The use cases for this are (a) to support the readonly attribute and
> >>
> >>
> >
> >At least the  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  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?)
> >>
> >>
> >>if (accept != null) {
> >>results.append(" accept=\"");
> >>//old way
> >>//results.append(accept);
> >>//new way
> >>results.append(getAccept());
> >>results.append("\"");
> >>}
> >>
> >>
> >>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Robert Leland]

David Graham wrote:

--- Sgarlata Matt <[EMAIL PROTECTED]> 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:

results.append("\"");
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());

results.append(renderExtraAttributes());

return results.toString();

The use cases for this are (a) to support the readonly attribute and 
   

At least the  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  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?)

if (accept != null) {
   results.append(" accept=\"");
   //old way
   //results.append(accept);
   //new way
   results.append(getAccept());
   results.append("\"");
}

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

[Niall Pemberton]

Sounds good. I'll put some thought into it.

Niall
- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 26, 2003 2:09 AM
Subject: Re: Editable Fields V/S Static Text


>
> --- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > I submitted a PATCH in May 2001, but it wasn't applied.
> >
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg01450.html
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=1683
>
> That bug is marked fixed but there are no patches attached to it.  This is
> a perfect example of why we ask patches to not be sent via email and
> prefer them to be attached to the bugzilla ticket.
>
> >
> > I haven't looked at them for a while but the issue was with the big
> > chunks
> > of code in the doStartTag()/doEndTag() - refactoring attributes out of
> > those
> > makes life much easier and I think was a good idea.
> >
> > I would do it again for the current Struts except that I don't want to
> > botther putting the effort in for it to be ignored a second time.
>
> I'm willing to work with you on this if you have the time to test and
> submit patches.  Let's start with one tag and discuss the needed changes
> on struts-dev before coding anything.  When we decide on the right changes
> to make we can open a bugzilla ticket to track things.
>
> My main area of interest is in the html taglib because it offers
> functionality not provided by the JSTL; however, if other tags need
> refactoring I'm willing to work on those as well.
>
> Does this sound reasonable?
>
> David
>
> >
> > Niall
> >
> > - Original Message - 
> > From: "David Graham" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Thursday, September 25, 2003 9:39 PM
> > Subject: RE: Editable Fields V/S Static Text
> >
> >
> > > Whenever tag extendability enhancements are discussed, we always hear
> > > complaints from a vocal minority but no tested working patches show
> > up.  I
> > > haven't heard any good suggestions that would make the tags easier to
> > > subclass.  If the current factoring isn't good enough, provide patches
> > for
> > > something better.
> > >
> > > David
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Don Brown]

The Struts Sourceforge site, http://struts.sf.net, is a good place for
such Struts extensions.

Don

On Thu, 25 Sep 2003, Chris Gastin wrote:

> As I can tell from the list I have opened topic that is pretty well beaten.
> Let me first apologize.  I did not realize this was such a political topic
> in the Struts community.
>
> I am starting to think that there should be some sort of Struts Tag Lib
> Extensions, which would address some of these issues while being totally
> separate from the Struts project. I am starting to agree with David I don't
> want to polute Struts with non standard HTML, but it would be nice to have
> an add on module which is dependant on Struts that could give users the
> functionality which it seems that other are requesting. I am willing
> contribute to this effort.
>
> I did not realize there were so many bugs for the taglibs, which some of you
> pointed out. I will see if I can help out. I will check out bugzilla, and
> try to contribute in that area.
>
> Chris Gastin
>
> - Original Message -
> From: "David Graham" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, September 25, 2003 3:39 PM
> Subject: RE: Editable Fields V/S Static Text
>
>
> >
> > --- Edgar P Dollin <[EMAIL PROTECTED]> wrote:
> > > I think it is more than a 'preference' based on the rapidity with which
> > > INVALID or WONTFIX is stamped on tag suggestions and patches.
> >
> > I can't speak for anyone else but here is my view on the tags:
> >
> > There are 3 things that earn my -1 on tag enhancements:
> > 1.  Functionality already provided by the JSTL.
> > 2.  Functionality that supports non-standard HTML generation.
> > 3.  Tags that don't tie into the Struts core functionality.  These are
> > better suited for the Jakarta Taglibs project.
> >
> > I'm personally open to other tag enhancements.  If you check cvs, you'll
> > see that I have volunteered some time at refactoring and enhancing the
> > tags.
> >
> > Whenever tag extendability enhancements are discussed, we always hear
> > complaints from a vocal minority but no tested working patches show up.  I
> > haven't heard any good suggestions that would make the tags easier to
> > subclass.  If the current factoring isn't good enough, provide patches for
> > something better.
> >
> > The fact is that the current tags work great for my needs so I'm not
> > motivated to spend a bunch of time pondering some ultimate extendability
> > framework.  There's not much we can do without use cases and patches.
> >
> > David
> >
> > >
> > > Perhaps it would be best if the tags were cut loose from struts and a
> > > different group of committers were responsible for them.  I wouldn't,
> > > nor
> > > would I expect anyone else interested in the tags to make any time
> > > commitment with the current 'RULES' placed on the tags, i.e. ONLY emit
> > > HTML
> > > 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc.
> > >
> > > Edgar
> > >
> > > > -Original Message-
> > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, September 25, 2003 2:23 PM
> > > > To: Struts Developers List
> > > > Subject: Re: Editable Fields V/S Static Text
> > > >
> > > >
> > > > It's only a "political football" in the sense that most of
> > > > the current
> > > > committers would prefer not to work on the HTML tags.  If other folks
> > > > came to the fore and committed themselves to supporting those tags,
> > > > including writing unit tests and answering questions on the
> > > > user list, I
> > > > don't think you would see much opposition to development in
> > > > that area --
> > > > along with an eventual nomination for committer status for the
> > > > individuals involved so that they can do their work directly.
> > > >
> > > > Asking the existing committers to do all the work isn't the way to
> > > > leverage how open source operates :-).
> > > >
> > > > Asking the existing committers to apply patches (and add unit
> > > > test cases
> > > > that already work), and pestering them until they get around
> > > > to it (or
> > > > nominate you to committer status so you can do it 

Re: Editable Fields V/S Static Text

[Chris Gastin]

As I can tell from the list I have opened topic that is pretty well beaten.
Let me first apologize.  I did not realize this was such a political topic
in the Struts community.

I am starting to think that there should be some sort of Struts Tag Lib
Extensions, which would address some of these issues while being totally
separate from the Struts project. I am starting to agree with David I don't
want to polute Struts with non standard HTML, but it would be nice to have
an add on module which is dependant on Struts that could give users the
functionality which it seems that other are requesting. I am willing
contribute to this effort.

I did not realize there were so many bugs for the taglibs, which some of you
pointed out. I will see if I can help out. I will check out bugzilla, and
try to contribute in that area.

Chris Gastin

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 25, 2003 3:39 PM
Subject: RE: Editable Fields V/S Static Text


>
> --- Edgar P Dollin <[EMAIL PROTECTED]> wrote:
> > I think it is more than a 'preference' based on the rapidity with which
> > INVALID or WONTFIX is stamped on tag suggestions and patches.
>
> I can't speak for anyone else but here is my view on the tags:
>
> There are 3 things that earn my -1 on tag enhancements:
> 1.  Functionality already provided by the JSTL.
> 2.  Functionality that supports non-standard HTML generation.
> 3.  Tags that don't tie into the Struts core functionality.  These are
> better suited for the Jakarta Taglibs project.
>
> I'm personally open to other tag enhancements.  If you check cvs, you'll
> see that I have volunteered some time at refactoring and enhancing the
> tags.
>
> Whenever tag extendability enhancements are discussed, we always hear
> complaints from a vocal minority but no tested working patches show up.  I
> haven't heard any good suggestions that would make the tags easier to
> subclass.  If the current factoring isn't good enough, provide patches for
> something better.
>
> The fact is that the current tags work great for my needs so I'm not
> motivated to spend a bunch of time pondering some ultimate extendability
> framework.  There's not much we can do without use cases and patches.
>
> David
>
> >
> > Perhaps it would be best if the tags were cut loose from struts and a
> > different group of committers were responsible for them.  I wouldn't,
> > nor
> > would I expect anyone else interested in the tags to make any time
> > commitment with the current 'RULES' placed on the tags, i.e. ONLY emit
> > HTML
> > 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc.
> >
> > Edgar
> >
> > > -Original Message-
> > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, September 25, 2003 2:23 PM
> > > To: Struts Developers List
> > > Subject: Re: Editable Fields V/S Static Text
> > >
> > >
> > > It's only a "political football" in the sense that most of
> > > the current
> > > committers would prefer not to work on the HTML tags.  If other folks
> > > came to the fore and committed themselves to supporting those tags,
> > > including writing unit tests and answering questions on the
> > > user list, I
> > > don't think you would see much opposition to development in
> > > that area -- 
> > > along with an eventual nomination for committer status for the
> > > individuals involved so that they can do their work directly.
> > >
> > > Asking the existing committers to do all the work isn't the way to
> > > leverage how open source operates :-).
> > >
> > > Asking the existing committers to apply patches (and add unit
> > > test cases
> > > that already work), and pestering them until they get around
> > > to it (or
> > > nominate you to committer status so you can do it yourself)
> > > *is* the way
> > > to leverage how open source operates :-).
> > >
> > > Craig
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> I submitted a PATCH in May 2001, but it wasn't applied.
> 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01450.html
> http://issues.apache.org/bugzilla/show_bug.cgi?id=1683

That bug is marked fixed but there are no patches attached to it.  This is
a perfect example of why we ask patches to not be sent via email and
prefer them to be attached to the bugzilla ticket.

> 
> I haven't looked at them for a while but the issue was with the big
> chunks
> of code in the doStartTag()/doEndTag() - refactoring attributes out of
> those
> makes life much easier and I think was a good idea.
> 
> I would do it again for the current Struts except that I don't want to
> botther putting the effort in for it to be ignored a second time.

I'm willing to work with you on this if you have the time to test and
submit patches.  Let's start with one tag and discuss the needed changes
on struts-dev before coding anything.  When we decide on the right changes
to make we can open a bugzilla ticket to track things.

My main area of interest is in the html taglib because it offers
functionality not provided by the JSTL; however, if other tags need
refactoring I'm willing to work on those as well.

Does this sound reasonable?

David

> 
> Niall
> 
> - Original Message - 
> From: "David Graham" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, September 25, 2003 9:39 PM
> Subject: RE: Editable Fields V/S Static Text
> 
> 
> > Whenever tag extendability enhancements are discussed, we always hear
> > complaints from a vocal minority but no tested working patches show
> up.  I
> > haven't heard any good suggestions that would make the tags easier to
> > subclass.  If the current factoring isn't good enough, provide patches
> for
> > something better.
> >
> > David
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Sgarlata Matt <[EMAIL PROTECTED]> 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:
> 
> 
> results.append("\"");
> results.append(this.prepareEventHandlers());
> results.append(this.prepareStyles());
> results.append(this.getElementClose());
> 
> 
> 
> results.append(renderExtraAttributes());
> 
> 
> return results.toString();
> 
> 
> The use cases for this are (a) to support the readonly attribute and 

At least the  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  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?)
> 
> 
> if (accept != null) {
> results.append(" accept=\"");
> //old way
> //results.append(accept);
> //new way
> results.append(getAccept());
> results.append("\"");
> }
> 
> 
> 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" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> 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  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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Sgarlata Matt]

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:


results.append("\"");
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());



results.append(renderExtraAttributes());


return results.toString();


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  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?)


if (accept != null) {
results.append(" accept=\"");
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append("\"");
}


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" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
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  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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Sgarlata Matt]

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:


results.append("\"");
results.append(this.prepareEventHandlers());
results.append(this.prepareStyles());
results.append(this.getElementClose());



results.append(renderExtraAttributes());


return results.toString();


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  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?)


if (accept != null) {
results.append(" accept=\"");
//old way
//results.append(accept);
//new way
results.append(getAccept());
results.append("\"");
}


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" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
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  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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Niall Pemberton]

I submitted a PATCH in May 2001, but it wasn't applied.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg01450.html
http://issues.apache.org/bugzilla/show_bug.cgi?id=1683

I haven't looked at them for a while but the issue was with the big chunks
of code in the doStartTag()/doEndTag() - refactoring attributes out of those
makes life much easier and I think was a good idea.

I would do it again for the current Struts except that I don't want to
botther putting the effort in for it to be ignored a second time.

Niall

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 25, 2003 9:39 PM
Subject: RE: Editable Fields V/S Static Text


> Whenever tag extendability enhancements are discussed, we always hear
> complaints from a vocal minority but no tested working patches show up.  I
> haven't heard any good suggestions that would make the tags easier to
> subclass.  If the current factoring isn't good enough, provide patches for
> something better.
>
> David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[David Graham]

--- Edgar P Dollin <[EMAIL PROTECTED]> wrote:
> I think it is more than a 'preference' based on the rapidity with which
> INVALID or WONTFIX is stamped on tag suggestions and patches.

I can't speak for anyone else but here is my view on the tags:

There are 3 things that earn my -1 on tag enhancements:
1.  Functionality already provided by the JSTL.
2.  Functionality that supports non-standard HTML generation.
3.  Tags that don't tie into the Struts core functionality.  These are
better suited for the Jakarta Taglibs project.

I'm personally open to other tag enhancements.  If you check cvs, you'll
see that I have volunteered some time at refactoring and enhancing the
tags.

Whenever tag extendability enhancements are discussed, we always hear
complaints from a vocal minority but no tested working patches show up.  I
haven't heard any good suggestions that would make the tags easier to
subclass.  If the current factoring isn't good enough, provide patches for
something better.

The fact is that the current tags work great for my needs so I'm not
motivated to spend a bunch of time pondering some ultimate extendability
framework.  There's not much we can do without use cases and patches.

David

> 
> Perhaps it would be best if the tags were cut loose from struts and a
> different group of committers were responsible for them.  I wouldn't,
> nor
> would I expect anyone else interested in the tags to make any time
> commitment with the current 'RULES' placed on the tags, i.e. ONLY emit
> HTML
> 4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc.
> 
> Edgar
> 
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, September 25, 2003 2:23 PM
> > To: Struts Developers List
> > Subject: Re: Editable Fields V/S Static Text
> > 
> > 
> > It's only a "political football" in the sense that most of 
> > the current 
> > committers would prefer not to work on the HTML tags.  If other folks 
> > came to the fore and committed themselves to supporting those tags, 
> > including writing unit tests and answering questions on the 
> > user list, I 
> > don't think you would see much opposition to development in 
> > that area -- 
> > along with an eventual nomination for committer status for the 
> > individuals involved so that they can do their work directly.
> > 
> > Asking the existing committers to do all the work isn't the way to 
> > leverage how open source operates :-).
> > 
> > Asking the existing committers to apply patches (and add unit 
> > test cases 
> > that already work), and pestering them until they get around 
> > to it (or 
> > nominate you to committer status so you can do it yourself) 
> > *is* the way 
> > to leverage how open source operates :-).
> > 
> > Craig
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[Edgar P Dollin]

I think it is more than a 'preference' based on the rapidity with which
INVALID or WONTFIX is stamped on tag suggestions and patches.

Perhaps it would be best if the tags were cut loose from struts and a
different group of committers were responsible for them.  I wouldn't, nor
would I expect anyone else interested in the tags to make any time
commitment with the current 'RULES' placed on the tags, i.e. ONLY emit HTML
4.01 or XHMTL 1.0, only a 'thin' layer over standard html tags, etc.

Edgar

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 25, 2003 2:23 PM
> To: Struts Developers List
> Subject: Re: Editable Fields V/S Static Text
> 
> 
> It's only a "political football" in the sense that most of 
> the current 
> committers would prefer not to work on the HTML tags.  If other folks 
> came to the fore and committed themselves to supporting those tags, 
> including writing unit tests and answering questions on the 
> user list, I 
> don't think you would see much opposition to development in 
> that area -- 
> along with an eventual nomination for committer status for the 
> individuals involved so that they can do their work directly.
> 
> Asking the existing committers to do all the work isn't the way to 
> leverage how open source operates :-).
> 
> Asking the existing committers to apply patches (and add unit 
> test cases 
> that already work), and pestering them until they get around 
> to it (or 
> nominate you to committer status so you can do it yourself) 
> *is* the way 
> to leverage how open source operates :-).
> 
> Craig
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Craig R. McClanahan]

Edgar P Dollin wrote:

If the tags were structured differently so they were easier to extend
without breaking when new releases of struts come out these issues might not
come up.  Of course, I myself have resigned myself to this issue since the
tags are such a political football on this list.
Edgar
 

It's only a "political football" in the sense that most of the current 
committers would prefer not to work on the HTML tags.  If other folks 
came to the fore and committed themselves to supporting those tags, 
including writing unit tests and answering questions on the user list, I 
don't think you would see much opposition to development in that area -- 
along with an eventual nomination for committer status for the 
individuals involved so that they can do their work directly.

Asking the existing committers to do all the work isn't the way to 
leverage how open source operates :-).

Asking the existing committers to apply patches (and add unit test cases 
that already work), and pestering them until they get around to it (or 
nominate you to committer status so you can do it yourself) *is* the way 
to leverage how open source operates :-).

Craig



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Forking Struts taglibs[ was Re: Editable Fields V/S Static Text]

[Robert Leland]

Edgar P Dollin wrote:

If the tags were structured differently so they were easier to extend
without breaking when new releases of struts come out these issues might not
come up.  Of course, I myself have resigned myself to this issue since the
tags are such a political football on this list.
Edgar
 

If we aren't meeting a real need that you have, there is nothing 
stopping interprising
developer(s) from forking the struts taglibs and hosting that on source 
forge.
This is open source after all !
A little healthy competition is good.

-Rob

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Robert Leland]

David Graham wrote:

--- Robert Leland <[EMAIL PROTECTED]> 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  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

[David Graham]

--- Robert Leland <[EMAIL PROTECTED]> 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  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 ( >/>)  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
> > tags. Which get really messy. Here is some
> >sample code.
> >
> > value="true">
> >
> >
> > value="false">
> >
> >
> >
> >
> >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   >name="actionForm" property"myField" readOnlyText="true"/> would output
> "My
> >Text Value".
> >
> >Where  readOnlyText="false"/>
> >the following tag would output
> >
> >
> >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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[David Graham]

--- Sgarlata Matt <[EMAIL PROTECTED]> wrote:
> Has anyone ever discussed adding a general-purpose "attributes"
> attribute to
> the  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,
> 
> 
> 
> 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" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> 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 ( > >/>)  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
> > > tags. Which get really messy. Here is
> some
> > >sample code.
> > >
> > > value="true">
> > >
> > >
> > > value="false">
> > >
> > >
> > >
> > >
> > >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   > >name="actionForm" property"myField" readOnlyText="true"/> would
> output
> "My
> > >Text Value".
> > >
> > >Where  readOnlyText="false"/>
> > >the following tag would output
> > >
> > >
> > >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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Robert Leland]

Sgarlata Matt wrote:

Has anyone ever discussed adding a general-purpose "attributes" attribute to
the  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[Edgar P Dollin]

If the tags were structured differently so they were easier to extend
without breaking when new releases of struts come out these issues might not
come up.  Of course, I myself have resigned myself to this issue since the
tags are such a political football on this list.

Edgar

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 25, 2003 12:23 PM
> To: Struts Developers List
> 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 ( >/>)  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
> > tags. Which get really messy. 
> Here is some
> >sample code.
> >
> > value="true">
> > 
> > value="false">
> >
> >
> >
> >
> >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   >name="actionForm" property"myField" readOnlyText="true"/> 
> would output 
> >"My Text Value".
> >
> >Where  >readOnlyText="false"/> the following tag would output  >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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Sgarlata Matt]

Has anyone ever discussed adding a general-purpose "attributes" attribute to
the  tag library to support non-standard HTML like this?  For example,



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" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
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 ( >/>)  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
> > tags. Which get really messy. Here is some
> >sample code.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >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   >name="actionForm" property"myField" readOnlyText="true"/> would output
"My
> >Text Value".
> >
> >Where 
> >the following tag would output
> >
> >
> >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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Editable Fields V/S Static Text

[Robert Leland]

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 ()  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
 tags. Which get really messy. Here is some
sample code.

   


   

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   would output "My
Text Value".
Where 
the following tag would output

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Editable Fields V/S Static Text

[Edgar P Dollin]

You could use a JSP expression to output the readonly='true' attribute of
the html:text or use the html-el library and use jstl to evaluate the
attribute.

Edgar

> -Original Message-
> From: Chris Gastin [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 25, 2003 12:29 AM
> To: [EMAIL PROTECTED]
> Subject: 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 ( 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  tags. Which get really 
> messy. Here is some sample code.
> 
>  value="true">
>  
>   property="myFieldEditable" value="false">
>  
> 
> 
> 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   name="actionForm" property"myField" readOnlyText="true"/> 
> would output "My Text Value".
> 
> Where  readOnlyText="false"/> the following tag would output  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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Editable Fields V/S Static Text

[Chris Gastin]

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 ()  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
 tags. Which get really messy. Here is some
sample code.









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   would output "My
Text Value".

Where 
the following tag would output


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]