Igor Vaynberg schrieb:
any way you look at it wicket is where requests originate. so wicket is the
first layer of request processing. some people feel comfortable determining
authorization as soon as possible. that means either in wicket, or in some
filter over wicket servlet. why should we limit those people?
also wicket is where user context lives, because wicket is in charge of
session, so anyway you look at it something has to talk to wicket to
determine the user context.
wicket is here to be generic and not to force one specific design onto
users, whether it be the best design or not. unless you are stepping up and
saying that your design is the best for every situation out there and are
willing to prove it i think this discussion is moot.
I don't think the design I'm currently using is the best for all
situations. Quoting from my previous posting:
| I guess peoples opinions differ because the situations differ. In my
| case, the security features of Wicket just add to Wickets complexity,
| which is a bad thing. In other cases, it might be convenient to have
| security support.
Timo
-Igor
On 2/11/06, Timo Stamm <[EMAIL PROTECTED]> wrote:
Eelco Hillenius schrieb:
I would like to put it a bit differently. Actually I think wicket is
more MVC than frameworks like struts are because we have the MVC at
the level of components instead of requests.
But to answer your question: yes it is a good idea to have such a
framework, even if you want to make authorization part of the model
layer. The mechanism we built in gives you a guaranteed mechanism to
plug in your authorization (in your case, like at Component.ENABLE),
and gives you the possibility to handle authorization exceptions at
the UI layer (because besides denying actions, you generally want to
communicate the denial in some way). So that works even in your case.
In my case, I don't even need authorization exceptions. It looks like
this:
for (Action a : entity.getActions()) {
add(new ActionButton(a));
}
Furthermore I don't agree with the statement that it should be done in
the model.
It should be in an MVC application, especially if there is more than one
view. In my app, the model is accessed by an administration application
that uses Wicket, and a web service using standard servlets. Obviously I
don't want to write the access checks multiple times.
We are building a generic framework, so as much as we can,
we should enable users to decide on this themselves. And I think a lot
of times, authorization actually is more related to end-user
functionality that has a 1-1 relationship with the UI than it is with
the model layer. But... opinions differ and that's why we just try to
provide a generic framework.
I guess peoples opinions differ because the situations differ. In my
case, the security features of Wicket just add to Wickets complexity,
which is a bad thing. In other cases, it might be convenient to have
security support.
I would not trade simple design for convenience (I think it's better to
improve the simplicity of the design), but that is certainly just my
opinion.
Timo
On 2/11/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
wicket is not MVC so the design of your application will be different.
what
we provide are hooks for you to build on, if you dont want to use them
you
dont have to. that is the beauty of the design: they are there for you
if
you need them, and invisible if you dont.
-Igor
On 2/11/06, Timo Stamm <[EMAIL PROTECTED]> wrote:
Johan Compagner schrieb:
We have now a Security framework (better said security interfaces)
inside
wicket.
I was wondering whether this is really a good idea. Isn't
authorization
a responsibility of the model in a MVC application?
Timo
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
