Hello Ted,
Monday, November 26, 2001, 8:14:19 PM, you wrote:
TH> I think its a clever idea. It's important that the framework not require
TH> Javascript for nominal operation, but using it is a fact of life for
TH> most applications, and getting it into a tag can be problematic.
TH> Though, should we allow for the Javascript to come from a separate bean,
TH> the ActionForm (or name=) bean being the default? So, we might have an
TH> optional scriptName="JavaScriptBean".
Add method to ActionForm and rewrite it in extended classes -
public class ActionForm {
protected ClentSideScripts scripts = null;
public ClentSideScripts getClientSideScripts() {
return scripts;
}
public void setClientSideScripts() {
this.scripts = scripts;
}
}
public class ClientSideScripts {
public String getOnkeydown() {
return "";
}
.....
}
public class MyScripts extends ClientSideScripts {
public String getOnkeydown() {
return "javascript:alert('Hey!')";
}
}
and in struts-config.xml add additional attribute to the action form
definition -
<form-bean name="logonForm"
type="org.apache.struts.webapp.example.LogonForm"
scriptSourceBeanClass="some.package.MyScripts"/>
or
public class SomeForm extends ActionForm {
public ClentSideScripts getClientSideScripts() {
// any custom code to return bean with script
// definitions
}
}
Some implementation of ClientSideScripts can read scripts from
resources, for example... 8)
TH> The other thing I've always wanted to add to the tags is a "literal" or
TH> ("custom" or "verbatim") property, that would just spit out whatever you
TH> put into it. This would solve the problems with tags like textarea,
TH> where the wrap attribute is not an official attribute. So, there we
TH> could use literal="wrap=virtual" and have it add that to the textarea
TH> tag. Of course, we would add this to all the tags, for consistency.
Great. It is simple and flexible.
TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
TH> -- Custom Software ~ Technical Services.
TH> -- Tel +1 716 737-3463
TH> -- http://www.husted.com/struts/
TH> Oleg V Alexeev wrote:
>>
>> Hello friends,
>>
>> Is it interesting for somebody to implement for html tags such logic
>> as listed below?
>>
>> Add to tags xxxKey attributes for all scripting support attributes
>> and extend html tags with ability to retrieve client side code from
>> resources by the key from attribute value. For example -
>>
>> <html:input name="someField" onKeyDownKey="javascript.alert.field"/>
>>
>> In this example 'javascript.alert.field' is the key to retireve
>> client code script.
>>
>> Is it interesting? I think it is useful and easy to implement.
>>
>> Monday, November 26, 2001, 1:52:39 PM, you wrote:
>>
>> SW> Hi Oleg,
>>
>> SW> for our current problem the first option is the better solution because it
>> SW> does not require to repeat in all JSPs the on... attributes. The overloaded
>> SW> tag class can automatically append some javascript code without a JSP
>> SW> developer
>> SW> even to know about it. In this case the only thing of struts that we have to
>> SW> patch is the tld which is acceptable.
>>
>> SW> The second option is also a great idea because then javascript logic is no
>> SW> longer scattered everywhere but can be centralized. I think lots of
>> SW> developers
>> SW> would be very grateful to have this possiblity.
>>
>> SW> However in our case the (automatically added) javascript code is already
>> SW> centralized in the overloading classes. To be able to configure it we would
>> SW> need
>> SW> some session- or application-scope object where we could define such global
>> SW> settings for all html-elements of certain kinds. I think this would be a big
>> SW> undertaking but maybe it would be enough to define somewhere default values
>> SW> for all attributes of all JSP tags.
>>
>> SW> To summarize: we are completely happy if just the member access in the tags
>> SW> is replaced by getter methods.
>>
>> SW> Ciao,
>> SW> 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?
>> >>
>>
>> --
>> Best regards,
>> Oleg mailto:[EMAIL PROTECTED]
>>
>> --
>> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
TH> --
TH> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
TH> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
