On 7/4/01 7:01 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>
>> On 7/4/01 4:27 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
>>
>>> Jason van Zyl wrote:
>>>
>>>> On 7/4/01 4:03 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> i would like to move the generation of the om/peer classes to tdk to give
>>>>> end-users a chance to extend the classes without subclassing anything.
>>>>>
>>>>> comments?
>>>>
>>>> Can you be more specific about the changes. I would assume we
>>>> keep all the interfaces in the turbine repository than generate
>>>> everything in the TDK, yes?
>>>
>>> yes.
>>> only the generated files + files overriding them (e.g. TurbineRole,
>>> TurbineRolePeer, ...) will be moved.
>>
>> Can we get rid of the overriding files too? I think torque would
>> need to add something to allow a generated peer/object to implement
>> a particular interface as was the case with the TurbineUserPeer. It
>> needs to implement UserPeer. That was causing a problem, but that could
>> be easily fixed.
>
> may work for group, role, ... where we can move stuff like group.grant(User
> user,
> RoleSet roleSet) to the DBUserManager or SecurityService
Those are generic operations, so definitely in the Security service.
Granting a user a role for a realm/project/whatever should work
for any backend implementation.
> i don't think it will work for the user class (e.g.
> user.getAccessCounterForSession() )
We can experiment in 2.2 and see what works and doesn't.
> but adding the ability to implement an interface is a good idea!
>
>>> The DBSecurityService, UserManager, interfaces (User, Role, ...) will stay
>>> in
>>> the turbine repository.
>>>
>>> to extend TurbineUser you only have to extend turbine-schema.xml, but if
>>> generated classes are included in turbine.jar you have to rebuild turbine.
>>
>> Yes, what we have is not optimal but definitely a step in the right
>> direction :-)
>>
>> I would say that we could hide most of the turbine-schema.xml file
>> and have a single file for the user implementation and then use the
>> include syntax to pull in the fragment that contains the user definition.
>> Than people can't mess up anything by mistake, and the rest of the schema
>> is out of sight, out of mind. I can't remember what the syntax is for
>> including a fragment.
>
> hmmm ... maybe someone wants to extend role ...
I would rather not guess, try to think of a case where it would make
sense to do this. Leaving everything possible because someone _might_
want to do something doesn't make sense to me. I think there is a finite
usage pattern. Maybe it makes sense to extend a role, but I don't see
one right off the top of my head. But with some feedback cycles I think
we can figure it out.
>>
>>
>>> if we move the generated classes to tdk, users are able to extend e.g.
>>> TurbineUser without recompiling turbine.
>>
>> Yes, that's what we want ideally. Cool!
>>
>
> other things on my list are:
> * remove blobs (they where never used for group, role, ...
+1
> * rename GROUP to something different (REALM was proposed some time ago)
+1 realm sounds good to me, are there any other choices that make sense?
> * we talked about adding a user-attributes table (so we can get rif of perm
> storage)
+1
> martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
