I'm afraid I can't be of immediate help. It would require that I go back and RTFM . I try to avoid creating custom JSF tags at the binary level these days for a number of reasons. One of which, fortunately, is that the set of powerful third-party extension tagsets available right now is so good. Custom tags are expensive to create and maintain, so I let some other poor sucker do it for me when I can. Failing that, the next alternative is to create Facelets components, and only then do I break out the binary option.
The main reason I stuck my nose in, however, was to proffer some (possibly unwanted) advice. While it's nice that we can do things like add custom EL extensions, putting logic on JSF view definitions is a violation of the MVC contract, which says that the view should reflect what's in the model. One reason is that one doesn't have to figure out which file the logic is in because it's always in a standard place. Another is that it's a heck of a lot easier to run a debugger against POJO logic in the backing bean than it is to trace through the EL processor. So use those awesome powers wisely!
An IDE is no substitute for an Intelligent Developer.
Joined: Oct 25, 2011
Thanks for the advice Tim and your speedy response. I agree with what you're saying about keeping any such logic out of the jsf pages but in my case I am choosing the lesser of two evils. My cutom tag is rendering an embedded object and custom set of controls for the object to a jsf page however the embedded object is a bit nasty, suffice to say it has lead me to need to construct a complete url for on of it's parameters. Obviously I could do this on the server side when rendering my component but due to where the source of the url (coming out of a servlet) this would lead to my tag being tied into my jsf application and not being very re-usable. I suppose I could bash this logic out to a backing bean somewhere and have my component retrieve the url from there to keep with the mvc concepts but it's only a simple function I'm wanting to perform and only in this one specific context.
FWIW, here's how I managed to specify absolute URLs with a minimum of complexity:
The pageContext bean grabbed the FacesConfig to get the HttpServletRequest to get the context from its URL. So that particular bean does have javax.faces specialized code in it, but it localizes the dependency on JSF to that particular bean so I don't have it splattered all over the webapp.>