Hi Oleg,
for our current problem the first option is the better solution because it
does not require to repeat in all JSPs the on... attributes. The overloaded
tag class can automatically append some javascript code without a JSP
developer
even to know about it. In this case the only thing of struts that we have to
patch is the tld which is acceptable.
The second option is also a great idea because then javascript logic is no
longer scattered everywhere but can be centralized. I think lots of
developers
would be very grateful to have this possiblity.
However in our case the (automatically added) javascript code is already
centralized in the overloading classes. To be able to configure it we would
need
some session- or application-scope object where we could define such global
settings for all html-elements of certain kinds. I think this would be a big
undertaking but maybe it would be enough to define somewhere default values
for all attributes of all JSP tags.
To summarize: we are completely happy if just the member access in the tags
is replaced by getter methods.
Ciao,
Stefan
> Hello Stefan,
>
> How do you want to specify default javascript code for tags? I view
> two ways to do so (all this variants uses your model - with proxy
> getXXX() methods and avoid direct variable values retrieving) -
>
> 1. Extend html:input tag with your own tag and reload all
> getXXXJscriptCode methods to generate default client side code.
> 2. Write new version of html:input tag with support of resource
> strings. So developer can specify key to retrieve string from
> resources and use it as attribute value -
>
> <html:input name="someField" onKeyDown="javascript:alert('Wow!')"/>
> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>
> Last example uses key 'javascript.alert.field' to retrieve value
> from resources.
>
> I think that second method is more powerful and flexible. Is it
> way to solve your problem?
>
> Thursday, November 22, 2001, 10:29:28 AM, you wrote:
>
> SW> Hi Oleg,
>
> SW> we want to add automaticallly additional javascript code to all input
> SW> fields, links, and (non-submitting) buttons to implement a
> dirty-check-mechanism.
>
> SW> The original problem is that if some enters lots of data in a form and
> then
> SW> clicks a link then all the the entered form data is lost. Our customer
> does
> SW> not accept this behaviour (because many unskilled people use the
> application).
> SW> Therefore we added onchange-javascript-code to all input fields and
> SW> checking-javascript-code to all links and (non-submitting) buttons.
> Now in case of
> SW> dirtyness of a form a dialog pops up saying that the entered data will
> be lost
> SW> and allowing to cancel the request.
>
> SW> We already use the <html:input>-tags in all our JSPs but we don't want
> to
> SW> have the necessary javascript code repeated everywhere (for
> consistency and
> SW> maintainance reasons). Therefore we want the necessary javascript code
> to be
> SW> added automatically.
>
> SW> If you think our solution is general enough then maybe this behaviour
> could
> SW> also be directly incorparted into struts.
>
> SW> Ciao,
> SW> --Stefan
>
> >> Hello Stefan,
> >>
> >> Wednesday, November 21, 2001, 6:33:38 PM, you wrote:
> >>
> >> SW> our first proposal concerning the extensibility of struts concerns
> the
> >> SW> html-taglib. Currently in the
> org.apache.struts.taglib.BaseHandlerTag
> >> the
> >> SW> members
> >> SW> (onClick, onDblClick, ...) are directly accessed. If the prepare
> >> methods
> >> SW> would use getter methods then you could easily extend the tags by
> >> SW> overloading the
> >> SW> getter method:
> >>
> >> SW> Current version of BaseHandler has methods like this:
> >>
> >> SW> private void prepareKeyEvents(StringBuffer handlers) {
> >>
> >> SW> if (onKeyDown != null) {
> >> SW> handlers.append(" onKeyDown=\"");
> >> SW> handlers.append(onKeyDown);
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (onKeyUp != null) {
> >> SW> handlers.append(" onKeyUp=\"");
> >> SW> handlers.append(onKeyUp);
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (onKeyPress != null) {
> >> SW> handlers.append(" onKeyPress=\"");
> >> SW> handlers.append(onKeyPress);
> >> SW> handlers.append("\"");
> >> SW> }
> >> SW> }
> >>
> >> SW> Our proposed version is:
> >>
> >> SW> private void prepareKeyEvents(StringBuffer handlers) {
> >>
> >> SW> if (getOnKeyDown() != null) {
> >> SW> handlers.append(" onKeyDown=\"");
> >> SW> handlers.append(getOnKeyDown());
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (getOnKeyUp() != null) {
> >> SW> handlers.append(" onKeyUp=\"");
> >> SW> handlers.append(getOnKeyUp());
> >> SW> handlers.append("\"");
> >> SW> }
> >>
> >> SW> if (getOnKeyPress() != null) {
> >> SW> handlers.append(" onKeyPress=\"");
> >> SW> handlers.append(getOnKeyPress());
> >> SW> handlers.append("\"");
> >> SW> }
> >> SW> }
> >>
> >> SW> Admittedly this is not a great change, but it would help
> extensibility
> >> a
> >> SW> lot. Who decides if this proposal is incorporated into the next
> >> version?
> >>
> >> SW> I will send you some more proposals soon.
> >>
> >> It is good addition. But what reason to do so? Can you explain any
> >> situation when such methods can be used?
> >>
> --
> Best regards,
> Oleg mailto:[EMAIL PROTECTED]
>
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
