What does function overloading have to do with anything? The script tag needs to achieve 2 goals: create a user-defined-named function which a developer can use in jsf clientside callbacks pass clientId parameters into that user-defined-named function (which could then use those clientId's to call legacy code, or whatever).
I think that we've basically got that here, so maybe we need to just focus on getting those two goals accomplished. Are there any other requirements for this tag you can think of? On Mon, 3 Jan 2005 18:07:36 -0800, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Heath Borders [mailto:[EMAIL PROTECTED] > > Subject: Re: <x:script /> design > > I don't think we should be changing the name of the function > > within the bodyContent of the tag. The tag should just > > generate a no-arg wrapper function around whatever they put > > in the bodyContent. They provide the name of the wrapper > > function, and can call it from the event callbacks on components. > > ECMAscript doesn't have function overloading. You can do all sort of > weird hacks with prototype based languages to save a reference to the > original function (which is ugly; I made a stint to Flash ActionScript > programming some time ago), but a newly declared prototype basically > overrides the existing one in the same scope. > > > We could also try to put in some namespace checks in the > > renderer, if we really want to catch errors. > > Yeah, maybe, but it might be difficult to reliably predict the order of > which the browser interprets the page. Anyway, I meant my code snippet > only as an idea for discussion and if found to be good enough, a basis > for somebody to polish it up for an actual implementation. > > Kalle > > > On Mon, 3 Jan 2005 17:16:40 -0800, Korhonen, Kalle > > <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > > > From: Heath Borders [mailto:[EMAIL PROTECTED] > > > > Subject: Re: <x:script /> design > > > > I like the way you went with that. > > > > We could probably have a different parameter type that would > > > > automatically do the document.getElementById call for you. > > > > I'm really a fan of using the <x:script/> as just a means > > of calling > > > > a templated function. We should probably try to take > > this as far as > > > > it could go, so that we have a maximally > > > > > > Yeah, already when I sent the email I was thinking of > > cleaning it up a > > > bit. How about: > > > <x:script> > > > <x:function name="disableMyInputText" calls="disable" > > > parameters="myInputText, myOtherInputText"/> function > > > disable(myInputText, myOtherInputText) { > > myInputText.disabled=true; > > > myOtherInputText.disabled=true; } </x:script> > > > > > > Where "calls" is an optional attribute if a text child node > > exists. If > > > it doesn't, a text node would be required, i.e.: > > > <x:script> > > > <x:function name="disableMyInputText" parameters="myInputText, > > > myOtherInputText"> > > > myInputText.disabled=true; > > > myOtherInputText.disabled=true; > > > </x:function> > > > </x:script> > > > > > > Would render: > > > <script> > > > function disableMyInputText() { > > > disableMyInputText$Parameters( > > > > > document.getElementById('weirdParentId:anotherParentId:myInputText'), > > > document.getElementById('uglyParentId:myOtherInputText') > > > ); > > > } > > > > > > function disableMyInputText$Parameters(myInputText, > > myOtherInputText) > > > { myInputText.disabled=true; myOtherInputText.disabled=true; } > > > </script> > > > > > > The nice thing about this is that you could make most of > > your existing > > > javascript working without changing it with creative use of > > x:function > > > as wrappers to the existing functions. > > > > > > Kalle > > > > > > > On Mon, 3 Jan 2005 15:26:00 -0800, Korhonen, Kalle > > > > <[EMAIL PROTECTED]> wrote: > > > > > > -----Original Message----- > > > > > > From: Travis Reeder [mailto:[EMAIL PROTECTED] > > > > > > Subject: Re: <x:script /> design I like it, but for > > simplicity's > > > > > > sake if the x:script is going to replace matching id strings, > > > > > > then I don't see the need for having the for and the id. Why > > > > > > not just the for like so: > > > > > > <x:script language="javascript" type="text/javascript"> > > > > > > <x:scriptParameter for="myInputText" /> function > > > > > > disableMyInputText() { > > > > > > var input = document.getElementById('myInputText'); > > > > > > input.disabled=true; > > > > > > } > > > > > > </x:script> > > > > > > > > > > Hold on guys.. why would we even need to explicitly call > > > > > document.getElementById() anymore? Couldn't > > > > <x:scriptParameter> render > > > > > that line and handle the whole shebang of getting a > > > > reference to the > > > > > object with its appropriate clientId.. i.e. like this: > > > > > <x:script language="javascript" type="text/javascript"> > > > > > <x:scriptGetElement var="input" for="myInputText" /> function > > > > > disableMyInputText() { input.disabled=true; } </x:script> > > > > > > > > > > The problem with this is that it would create the > > > > references in global > > > > > scope, which might not be a huge deal and there are ways to > > > > deal with > > > > > that, but anyways, if we think this a little bit further, > > > > we could do: > > > > > <x:script language="javascript" type="text/javascript"> > > > > > <x:scriptFunctionParameters id="disableMyInputText" > > for="disable" > > > > > elementIds="myInputText, myOtherInputText"/> function > > > > > disable(myInputText, myOtherInputText) { > > > > myInputText.disabled=true; > > > > > myInputText.disabled=true; } </x:script> > > > > > > > > > > Which would render: > > > > > <script> > > > > > function disableMyInputText() { > > > > > > > > > > > > > > > > disable(document.getElementById('weirdParentId:anotherParentId:myInp > > > > ut > > > > > Te > > > > > xt'), > > > > > > > > > > > > document.getElementById('weirdParentId:anotherParentId:myInputText > > > > > ') > > > > > ); > > > > > } > > > > > > > > > > function disable(myInputText, myOtherInputText) { > > > > > myInputText.disabled=true; myOtherInputText.disabled=true; } > > > > > </script> > > > > > > > > > > So we get nice parametrized functions that can be reused > > > > and less to > > > > > write since we don't need to deal with getting the client ids - > > > > > win/win situation right? Why wouldn't this work? > > > > > > > > > > Kalle > > > > > > > > > > > > > > > > Heath Borders wrote: > > > > > > >Here is the JSP and rendering hints I was thinking about for > > > > > > >the <x:script /> tag. > > > > > > > > > > > > > >JSP Example: > > > > > > > > > > > > > ><h:inputText id="myInputText" value="#{bean.text}" > > /> <x:script > > > > > > >language="javascript" type="text/javascript"> > > > > > > ><x:scriptParameter for="myInputText" id="p_myInputText" /> > > > > > > >function > > > > > > disableMyInputText() { > > > > > > > var input = document.getElementById('p_myInputText'); > > > > > > > input.disabled=true; > > > > > > >} > > > > > > ></x:script> > > > > > > > > > > > > > > > > > > > > >The language and type attributes would be optional, and > > > > default to > > > > > > >"javascript" and "text/javascript" respectively. > > > > > > > > > > > > > >The scriptParameter would use the > > > > UIComponent.findComponent(String) > > > > > > >method to find a component within the current > > > > > > namingContainer with the > > > > > > >given id. The <x:script> tag would then search its > > > > > > bodyContent for any > > > > > > >strings matching the <x:scriptParameter> id's and replace > > > > > > them with the > > > > > > >clientId of the UIComponent from the <x:scriptParameter> for > > > > > > attribute. > > > > > > > > > > > > > >This would be a simple way to include javascript (and > > > > > > appropriate code > > > > > > >commenting and <noscript> tags for non-javascript > > > > browsers) in JSF > > > > > > >code. > > > > > > > > > > > > > >I'd appreciate any input on this design. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Travis Reeder > > > > > > Ecommstats Web Analytics > > > > > > www.ecommstats.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > -Heath Borders-Wing > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED] > > > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
