Dave,
can you create a branch for "roller-newbackend" when you get a chance?
i'd like to start working on this.
-- Allen
Allen Gilliland wrote:
I don't think we need to involve Spring for any of these modifications.
Migrating to Spring is a separate step.
-- Allen
Max Rudman wrote:
Hi Allen,
Have you looked at Spring transaction management support yet? Your
proposal doesn't address how you plan to implement multi-step
operations and I think Spring can really help you there. I am more
than happy to help with getting that to work.
Max
On Mar 27, 2006, at 2:17 PM, Allen Gilliland wrote:
David M Johnson wrote:
On Mar 27, 2006, at 1:04 PM, Allen Gilliland wrote:
so we would be pushing the logic outside the persistence layer and
expecting someone else to do authentication/authorization, not the
persistence layer.
I agree that somebody else should do the authentication, but the
rules about who can do what (authorization) are part of the
application logic of Roller. The more of that we can encapsulate the
better.
Having said that, I can't object to ripping out setUser() and
getUser(). Currently, we double check things. The presentation layer
calls an "is user X authorized to perform action Y on object Z"
style method and then, in the save() method in the back-end does
another check -- but by that time it's too late, the change has
already been made to the persistent instance. Ripping out the
setUser() and getUser() methods will only affect that second check
that the back-end does -- so it's fine by me.
Are you going to leave the existing "is user authorized to edit"
methods in place so that checks can be made from the presentation
layer as they are now?
i'm not sure exactly what methods you are talking about, are you
talking about the PersistentObject.canSave() methods?
i don't think there is any problem with leaving those in place right
now, but i think long term we can come up with a better solution.
-- Allen
- Dave
