As to the three proposals:
I personally would deliver both 2 and 3, the proposal number 2 does
have problems though, Craig has pointed them out...
an easy solution for 2:
In fact you can always use the id - if you set the id of the naming
containers, you know what your client-id will look like - and you can
easily change your javascript functions to use that (I admit a little
longer) id.
an easy solution for 3:
what about using the tags I recently invented for MyFaces?
jsValueChangeListener could easily be extended to be callable on any
javascript event; you can call any java-script method from the value
changed expression and can pass the id of the component you want to
change; solves at least the event handler problems; and your
javascript stays independent of any one id (better for code reuse
anyways)...
regards,
Martin
On Sun, 2 Jan 2005 23:34:06 -0600, Heath Borders
<[EMAIL PROTECTED]> wrote:
> The <x:script> doesn't HAVE to drop variables into the global
> namespace. It depends upon how it is used. In the example I gave,
> there are two affected namespaces: that of the <x:script> tag and that
> of the enableOrNot() function. Of course, the <x:script> tag is
> powerful enough to allow for additions to the global namespace thusly:
>
> <h:inputText id="myInputText" value="#{bean.value}" />
> <x:script>
> <x:scriptParameter for="myInputText" id="p_myInputText" />
> var inputText = document.getElementById('p_myInputText');
> </x:script>
>
> This would therefore add "inputText" into the global namespace.
>
> I realize that the j4j tag already basically solves this problem, but
> I think that this tag is a more graceful solution that would be easy
> to implement.
>
> On Sun, 2 Jan 2005 20:34:28 -0800 (PST), Martin Cooper
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, 2 Jan 2005, Sean Schofield wrote:
> >
> > >> What the <x:script> tag would have to do is search its body content
> > >> for ids specified in the <x:scriptParameter> tag and replace them with
> > >> the clientId's of the components specified in the
> > >> <x:scriptParameter>'s "for" attribute.
> > >>
> > >> Thoughts?
> > >
> > > I'm personally not too wild about this. Why do we want to subject the
> > > user to all of this extra coding? Its one thing if there is no other
> > > way, but it seems like we have another way (your suggestion of
> > > overriding convertClienttId() method.) This idea has some
> > > possibilities but it strikes me as not much of an improvement over the
> > > "proxy tag" idea that has been developed.
> > >
> > > Out of curiousity, are you leaning in favor of or against the directId
> > > attribute? I detect three distinct ideas here...
> > >
> > > #1) This is not much of a problem - do nothing
> > > #2) Allow user to specify directId/styleId attribute
> > > #3) Provide some sort of custom tag to finesse the javascript
> > >
> > > I obviously don't agree with conclusion #1. I personally favor #2
> > > over #3 because they will be equally difficult for us to code but #2
> > > will require much less of the user to use (and will look much
> > > cleaner.) You've weighed in with ideas for both #2 and #3 so I was
> > > wondering what your preference was.
> > >
> > > Where do other people stand on this? For those who don't think this
> > > is much of a problem to begin with, would either of these solutions
> > > cause prolems? Or would they be a case of unecessary effort but no
> > > harm done?
> >
> > I'm definitely in the "this is a problem" camp. I would prefer #2 over #3,
> > since it's going to make life a lot easier for the people most affected by
> > the problem.
> >
> > As far as #3 goes, note that the j4j idProxy tag generates an additional
> > element enclosing the original content. This will likely break a lot of
> > existing JavaScript code that "knows" the structure of what it's
> > manipulating. Also, the <x:script> element is dropping variables in the
> > global namespace, which is also likely to cause problems.
> >
> > --
> > Martin Cooper
> >
> > >> -Heath Borders-Wing
> > >
> > > sean
> > >
> >
>
> --
> -Heath Borders-Wing
> [EMAIL PROTECTED]
>
