I haven't had time to fully catch up on this thread, so I hope I am not stating something that has already been said.
 
My problem/concern about any _javascript_ solution is cross field _javascript_.  I need the ability with any of these solutions to manipulate a different element from the one that called the _javascript_ funtion.  For instance, I have an onChange event for 1 element change the HTML/CSS of another element.  Or what about a _javascript_ that gets called on page submit to do something.  There absolutely has to be a way to easily get the id of elements other than the one that invoked the function.  So just having the component pass in a reference to the element to the function won't satisfy my needs.
 
I'm sure all of you are aware of this.  I just wanted to stress the point one more time.
 
I appreciate all of the effort and thought for this.  This IS an issue that people here would use to discourage the use of JSF.
 
Thanks,
Ray

Sean Schofield <[EMAIL PROTECTED]> wrote:
> The whole point of using something like
> JSF is that you are moving away from writing direct html code. In the long
> run, every single thing on your page should be a JSF component, including
> the script portions.

I don't see myself writing all of my _javascript_ via components anytime
soon. IMO this would be overkill. _javascript_ is already difficult to
maintain and follow, why add more complexity if you can avoid it?

Yes I can envision myself starting to write more of the _javascript_ in
components now that faces is here. Certainly not all of it and not
until I decide to switch my project to JSF (and even then, I will be
converting a little bit at a time)

> I think the should be used even if it
> doesn't do anything other than output a


Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search. Learn more.

Reply via email to