And access based on model data is one of the big things i want to have supported!
if not then i personally say don't add anything lets build on top of wicket what you need.
Because anything that doesn't give me the possiblitly to do the steps i want is useless
i know it and i have seen it so often in a current project. We have build in security but
it misses this or that and what happens? 7 out of 10 persons are building there own complete security.
So if we have such a basic support that most persons are still completely do it them selfs
then i don't want it anyway.
I agree that enums or bits are not the the best things but what can we do? We just have different things to test
if a special implemenation don't want to support it its fine. They can ignore it ofcourse (and return true or false
depending on yes/now or what ever)
I just want finer gradiant support.
For exampe what do you mean with it will be hard for property models?
Property models are not the things you want to test.
Data testing you do on the real object. So most of the time the object that is in the compound model of the form
For example Person that is of Type X can be seen by a user that is of Type Y or is only readable by a user of Type Z.
That where the things that was shown and was supported by the acegi framework in the session i saw.
with ofcourse links that where visible or not depending of the user/roles.
All with really horrible configuration so that is ofcourse something i want to avoid :)
On 10/26/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
A couple of more 'new insights' ;)
* having a read-only option is good. Still don't agree with the
enumeration though. Jonathan came up with another reason why you don't
want to have an enumeration. If there's any more things we come up
with in the future (which would, in the case of an enumeration mean
adding a new enumeration value), you would have a silent addition
instead of an API break. We think that is bad, as you want to force
clients how to support such new functionality. Having seperate
(boolean returning) methods does that. Again, any implementation is
free to map these seperate methods into one enumeration based method.
We can't guarantee read-only models. Sure, we can proxy any IModel
object, but that would only work for very simple models. All models
that work like property models for instance can't be guaranteed unless
we would make full copies of the model objects and wrap those, which
would be way too expensive. Furthermore, as there are many ways to
secure you domain objects (like not providing public setters, or e.g.
using the new Hibernate functionality in case you use that framework),
I think we shouldn't even try to do this in Wicket. It will otherwise
confuse people/ make Wicket harder to understand, and we can't even
guarantee anything but the simplest use cases.
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
