Sean, The reason I'd like to use $'s rather than @'s is that $'s are legal to use in a js identifier. That means that people could generate their template code in whatever js IDE they use without having to copy in the @'s after the fact.
Kalle, 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 useful ways of getting the clientId's into our functions (either by directly passing them, or automatically finding the associated DOM elements, etc). 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:myInputTe > 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]
