Viewhandler question/proposal
Hi, a question to the list... I am currently writing a chainable view handler (a view handler which you can pass a sequential list of handlers which are then chained together in the order you give in the parameters - top down, all done in the faces config) Now I rechecked the tlds and I saw that you already can cascade the decorating view handlers. But one question to the people in here more familiar with the specs, does this cascade enforce a calling order or not? I am not talking about the actual implementation here but more about the specs themselves. the * in the view handler tag definition makes that unclear. If it does I can dump the work spent so far on the custom handler if not, then it probably is a good idea to implement it fully.
Re: Viewhandler question/proposal
On 1/5/06, Werner Punz [EMAIL PROTECTED] wrote: Hi, a question to the list...I am currently writing a chainable view handler(a view handler which you can pass a sequential list of handlerswhich are then chained together in the order you give in the parameters - top down, all done in the faces config)Now I rechecked the tlds and I saw that you already can cascade thedecorating view handlers.But one question to the people in here more familiar with the specs, does this cascade enforce a calling order or not?Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR).You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. CraigI am not talking about the actual implementation herebut more about the specs themselves. the * in the view handler tag definition makes that unclear.If it does I can dump the work spent so far on the custom handlerif not, then it probably is a good idea to implement it fully.
Re: Viewhandler question/proposal
Craig McClanahan wrote: Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR). You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. Ok thanks for the clarification, then my work spent on it so far is more or less useless because the JSF api basically implcitely already does what I had in mind :-)
Re: Viewhandler question/proposal
Yep; also, consecutive calling isn't really right because few of the ViewHandler methods return anything indicating hey, I handled it, so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler' and tweaking them. Where Craig says it would be better than nothing (referring to alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's not something I wanted to be stuck with for the rest of eternity. -- Adam On 1/5/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan wrote: Within a given faces-config.xml file you should be able to count on ordering (the last one you declare will be the view handler from the point of view of the Application object. However, there's no mandated ordering with respect to view handlers loaded from different faces-config.xml files (for example, those implicitly loaded from the META-INF directory of a component JAR). You may recall some earlier discussion on this list about what the JSF RI currently does -- essentially loading the jar files in alphabetical order. It's a convention, not a mandated requirement, and doesn't address all possible dependency relationships you might want, but it would be better than nothing. Ok thanks for the clarification, then my work spent on it so far is more or less useless because the JSF api basically implcitely already does what I had in mind :-)
Re: Viewhandler question/proposal
On 1/5/06, Adam Winer [EMAIL PROTECTED] wrote: Yep;also, consecutive calling isn't really right because few ofthe ViewHandler methods return anything indicating hey, I handled it,so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler'and tweaking them.Where Craig says it would be better than nothing (referringto alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's notsomething I wanted to be stuck with for the rest of eternity.+1 ... a correct solution would support some sort of dependency declaration mechanism to determine ordering. Craig
Re: Viewhandler question/proposal
I thought I'd added a summary of the dependency discussion as comments to the jsf-spec issue #121, but I don't see them now https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=121 On 1/5/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/5/06, Adam Winer [EMAIL PROTECTED] wrote: Yep; also, consecutive calling isn't really right because few of the ViewHandler methods return anything indicating hey, I handled it, so everyone else hands off, and because the decoration pattern is in fact often required, to support working off the results of another ViewHandler' and tweaking them. Where Craig says it would be better than nothing (referring to alphabetical order), I agree in so far as making it a convention, but I argued against making it part of the spec, since it's not something I wanted to be stuck with for the rest of eternity. +1 ... a correct solution would support some sort of dependency declaration mechanism to determine ordering. Craig
