> -----Original Message----- > From: Heath Borders [mailto:[EMAIL PROTECTED] > Subject: Re: <x:script /> design > What does function overloading have to do with anything?
Sorry, maybe I misunderstood your comments "I don't think we should be changing the name of the function within the bodyContent of the tag" and "The tag should just generate a no-arg wrapper function around whatever they put in the bodyContent" then. > 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? I don't, but I actually haven't suffered much from this problem at all. Kalle > 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] > >
