> So if a homepage or bookmarkable page does this:
> setResponsePage(XXX.class) then XXX will be rendered now no matter what
> checkaccess of XXX says!
> thats wrong.
>
> Also if checkAccess does one of the setResponsePages (class or instance)
> then those are also not checked anymore.
>
No, I don't think that is wrong, as it should be part of
IAuthorizationStrategy. The sole reason for checkAccess imo is that
you can redirect to another page (ie logon page) in certain cases.
This case is common enough to support seperately, though I'm not
entirely happy with it's seperate position.
So, say we would do it after even processing. That would mean you
could have a interface method called before check access is even
called.
I think i already mention that before somewhere.
The render phase is always the first phase because only after a render phase you can call events on it.
so checkaccess is always first before anything else.
but I agree that the check should also be there (but isn't that page.beforeCallComponent(component, method); ??)
>
> Also IPageClassRequest now also extends icheckaccess and also
> isessionsynchronize (can also render a page with models!)
Then that target should better be diveded further. There is no need
for synchronization on the target when it is only redirecting.
No but i can't worry about that to much. Because that is a very very small piece of code.
What we can do is do it in the request targets but don't know if we want that....
Or it shouldn't be a marker interface but an interface that returns the sync object..
And then the ClassRequest can check it it is a redirect and return null if it is and session if it is not.
johan
