On Tue, Jun 12, 2001 at 10:51:50AM -0700, Jon Stevens wrote:
> on 6/12/01 10:12 AM, "Mike Haberman" <[EMAIL PROTECTED]> wrote:
>
> > permission, role, group, user
>
> +1 +1 +1 -1
>
> I say -1 on User unless you provide equal functionality/implementation of
> data.setPerm
>
> To this day, I still feel that data.setPerm is a good idea in some cases.
> However, I'm up for discussion on the actual implementation of that method.
Right now, when a you get an http binding event, DBUserManager.store(user)
eventually gets called. All this method does is pull things out of the
permenant hash table (the field names of User) to set up the criteria
and then it does a
criteria.add( TurbineUserPeer.OBJECT_DATA, permData );
then it does the save.
So for the basic implemenation without blobs, data.setPerm() would work
as it does today.
Now if you want to add arbitary data to the user that gets saved over
crashes, I would say that the application user should either add
the relevant fields to a User object (or create a catch all blob field).
In any case, turbine's base classes have a coherent front and the
general answer is to subclass to add additional fields per application
need.
The security code is something I do not have a lot of experience with
so I could be missing something. But I like the idea of using
torque for the security classes in the same manner that we use for
other BO in our apps. It's nice to be able to explain to others
how the whole BO stuff works and then tell them the security stuff
is handled the same way.
While martin works on the the torque stuff, I can pull out the blob
stuff in the current implementation.
mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
