> -----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] > >
