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]
