> Consider the case in which I want to create a set of JSF components that > essentially wrap the widgets from an existing JavaScript framework, to > make them easier to use in a JSF environment. The JavaScript framework > almost certainly wants a great deal of control over the resulting HTML. > Changing the JavaScript framework so that it can be made to work with JSF > isn't something that's likely to happen, since (a) the people developing > the framework and the people wrapping widgets in JSF components are not > likely to be the same people, and (b) the changes would quite possibly > break existing uses of the framework.
This is a good counter example. I don't currently rely on my framework (Struts) to generate the javascript. With faces, however, this would make much more sense. And so yes, for those components that are generating javascript via the framework (say using UIComponent.getClientId() as Craig suggested), those will allways have to be refactored when you switch frameworks. So that is a good example of where you would not need to use directId. As Heath points out in this case, just go with option #1 (do nothing.) You can just use UIComponent.getClientId() in your encode method when generating the javascript and there are no issues. If this is how you generate the bulk of your javascript, then I can see why one wouldn't think this is an issue. For those of us who do not require dynamically generated javascript all of the time, this will be a big problem. > Martin Cooper sean
