That's essentially what I've done (I'm injecting the page name into a property, but the effect is the same).
It's a perfectly fine work-around, and maybe it's the 'solution'. If you do decide to work on it, I agree that none of the binding prefixes (prefices?) make sense other than ognl and literal, but coding just those 2 means it's not forward-compatible with new binding prefixes or user-supplied prefixes that might make sense. It's kind of like specifying a message: prefix for the source binding on a contrib:Table. It's stupid as hell, and you get what you deserve if you do it, but you *can* do it. The component pukes and all is well. If you're going to add prefix support, I think it should be complete. Admittedly, I'm not very familiar with the bowels of the tap code, but here's how I see this working. The specification parser should really be creating IBinding objects out of the values and handing that to each injection worker. The injection worker should be responsible for getting the value out of that binding, making sure it's appropriate for use -- throwing exceptions if it's not -- and using it. What would be wrong -- not just poor design, but *wrong* -- with a developer using a message: prefix to get the name of a i18n page to render a response? It's silly and needless, but perfectly functional. Thanks, -Mike > Would it work for you to just do this: > > String pageName = com.package.PageConstants.FOO_PAGE; > getPage().getRequestCycle().getPage(pageName); > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
