struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sgarlata Matt" <sgarlata_m...@bah.com>
Subject Re: Editable Fields V/S Static Text
Date Sat, 27 Sep 2003 00:18:22 GMT

----- Original Message ----- 
From: "David Graham" <grahamdavid1980@yahoo.com>
To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Sent: Friday, September 26, 2003 1:02 AM
Subject: Re: Editable Fields V/S Static Text


>
> --- Robert Leland <rleland@apache.org> wrote:
> > David Graham wrote:
> >
> > >--- Sgarlata Matt <sgarlata_matt@bah.com> wrote:
> > >
> > >
> > >>OK, here's another idea.  I searched the archives for it and couldn't
> > >>find
> > >>it.
> > >>
> > >>How about two simple changes:
> > >>1) Add a new renderExtraAttributes() method that gives people the
> > chance
> > >>to
> > >>throw non-standard HTML into their tags that extend from Struts tags.
> > >>
> > >>
> > >
> > >I am -1 on the Struts tags supporting any non-standard HTML including
> > >providing the suggested hook method.  Like Java itself, Struts aims to
> > be
> > >a cross-platform tool.  Adding support for non-standard HTML undermines
> > >that goal and promotes non-interoperability.
> > >
> > >
> > Is it really the Struts tag library's mantra to dictate that the tags
> > should not be modified
> > externally to gain needed functionality ?
>
> I'm still not clear about this.  What is the needed functionality that
> we're not providing?

The needed functionality is the ability to cleanly extend the Struts tags.
They tags are so good that when an application-specific requirement arises,
it's much more desirable to extend from the Struts tag and keep tie-ins with
ActionForms and such than it is to go off on your own.

> > By not providing hooks,
> > wheather these are the
> > correct ones or not, isn't  very developer friendly. A framwork can be
> > developer friendly,
> > and well designed at the same time.
>
> I agree but hook methods that exist solely to help people write
> non-standard HTML aren't the way to go.  Methods that perform a standard
> function that can be overridden are more appropriate IMO.
>
> >
> > And It's not that the tags would be producing non standard HTML 4.01,
> > it's that they would/could
> > add composite functionality over and above standard HTML that would
> > still be 4.01 compliant.
>
> What's an example of this?

I thought of a use case that *is* 4.01 compliant!  I built an implementation
of Matt Kruse's JavaScript calendar widget based on the Struts tags a few
weeks before Matt made his own implementation, so I have some experience
doing this.  As some brief background, the widget is a text box and a
corresponding calendar icon.  When you click on the calendar icon a popup
appears where you can choose the date.  When you click on the text box
(which is what overrides a Struts tag) you want onfocus to automatically
call this.blur() so that the user can't enter text into the textbox (that's
the calendar popup's job).  So in my subclass it would be nice to override
the getOnfocus() method instead of overriding the entire
renderIForgetWhatItIsCalled() method.

Unfortunately I still can't think of a good HTML 4.01 compliant use case for
renderExtraAttributes(), but here is a weak try at it.   If my other
suggestion of having the render() method call getters instead of directly
accessing instance variables is used, then renderExtraAttributes() becomes
more important.  If it is not provided and someone wants to stick in some
non-HTML 4.01 compliant HTML, what they will do is override something like
the getSize() method so that it correctly renders the size and then sticks
in the understandard HTML.  This is a nasty hack but you know a programmer
will choose that over duplicating an entire render() method.

I hope all this is clear, the threads are getting vicious here...

> David

Matt


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


Mime
View raw message