#3 is just a possibility I came up with recently, so I thought I'd put it out there.
I think I like #3 the best because I don't have any legacy javascript that I am worried about including. Most of the javascript i'm developing is very lightweight interactions between components as I described in my example, and the <x:script> tag would take care of this just fine. However, we also have to be aware of our user base, and if our users are more used to the #2 method, I don't see why we shouldn't develop that to attract more people to MyFaces. As for difficulties, it seems like #3 would be vastly easier to code (I might even do it tomorrow at work), as opposed to #2. I don't see this as an either-or problem. Both ways can coexist peacefully. On Sun, 2 Jan 2005 21:58:57 -0500, Sean Schofield <[EMAIL PROTECTED]> 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? > > > -Heath Borders-Wing > > sean > -- -Heath Borders-Wing [EMAIL PROTECTED]
