On 10/23/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
I've got a question about the postBack methods i have to implement to match ViewController interface. What should i have to have to implement there - the documentation does not mention them, it tells that the methods will be called ( e.g. setPotBack(true)) - but a more detailed description why i have to implement them would be nice, because every postback my page processes ( validation error etc. pp, outcome of the handler is null ), my setPostBack method is never called, so to make things clear, why its there and how to use it?
Separate from Matthias's question about whether you are extending AbstractViewController instead of implementing ViewController, a separate question relevant to your scenario is whether or not you're using the @View annotation from the Tiger Extensions to mark your view controllers. If you are, then you should be aware that the "postback" property is not supported. As background, I think having the "postback" property might have been a little bit of overkill in the original API design. One sure way to tell if you're processing a postback or not is if the preprocess() method gets called. Thus, the only time (from Shale's perspective) that the application might really want to know is in the init() method ... and I am moving towards being convinced that adding the "postback" property just for this use case is not really the right thing to do. What do you think? Is it important enough for a view controller to know this in the init() method to add full support for the "postback" property, even when you are using the @View annotation? Torsten
Craig
