You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Marc Lustig <ma...@marclustig.com> on 2002/09/26 14:33:30 UTC

extending TurbineUser using Fulcrum SecurityService

> > I want to extend org.apache.turbine.om.security.TurbineUser to provide
> > business logic functionality to my application to use them in Screen
> > classes, Action classes, Peer classes.
> >
> > I adjust TR.props:
> >
> > services.SecurityService.user.class=de.geoconnect.audiotex.AudiotexUser
> >
> > Q: Is that all I have to do, or is there something else to do?
> >
> > JavaDoc/ org.apache.turbine.om.security.TurbineUser says:
> > "You are welcome to extend this class if you wish to have custom
> > functionality in your user objects (like accessor methods for custom
> > attributes). Note* that implementing a different scheme of user
> data storage
> > involves writing an implementation of UserManager interface. "
> >
> > Q: What is refered here as "a different scheme of user data storage"?
> > The TurbineUser Peer or what?
> >
> > Q: In what case do I have to write an implementation of UserManager
> > interface?
> >
> > Thanks.
> >
> > Marc
>
> Hi Marc,
>
> I'm afraid you have just grabbed a snake by the tail.  From what I
> understand, the only people that have successfully extended the
> turbine-user
> table in turbine 2.2bx have been using the DBSecurity service in fulcrum
> rather than the one provided with turbine itself.  On top of this I think
> the better option may be to utilise the SecurityService proposal code in
> fulcrum cvs head from Henning - this seems to add a whole lot of
> flexibility
> (IIRC Henning was going to make the internal cvs repository (of
> the company
> he works for) containing additional enhancements to fulcrum available for
> read-only access, but I don't think this has happened yet).

Thanks, Scott.
Oh boy, is it really that bad?

I looked into the Fulcrum SecurityService doc.
It uses as standard
services.SecurityService.user.class=
org.apache.fulcrum.security.impl.db.entity.TurbineUser
(instead of org.apache.turbine.om.security.TurbineUser)

So what if I simply extend
org.apache.fulcrum.security.impl.db.entity.TurbineUser instead of
org.apache.turbine.om.security.TurbineUser?

Would that work?

I don't think I need to change
services.SecurityService.userPeer.class=
org.apache.fulcrum.security.impl.db.entity.TurbineUserPeer

cause I am fine keeping TurbineUser table as basis for the User, and just
extend it on table-level. I know using this solution I won't have the
comfort of accessing all my user-properties from the object itself. But I
can I can live with that and get them from other other Peers (Kunden).

---> The reason why I would like to have a clean User extension is that I
like the idea to access abstract business logic directly from the user
object, not from a Peer (either TurbineUser or Kunden, my extended user
table).
like user.goInTheJungleAndGetSomeFood()
instead of having calling numerous Peer-methods on a less abstraction-level.

Isn't this reasonable?

But if this User-extension is too adventurous I think I will forget about it
and just go with the simple Peer-methods.

Cheers

Marc


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: extending TurbineUser using Fulcrum SecurityService

Posted by Scott Eade <se...@backstagetech.com.au>.
> From: "Marc Lustig" <ma...@marclustig.com>
> 
> Thanks, Scott.
> Oh boy, is it really that bad?
Probably not.  I did it for turbine 2.1 and others have done it (using
fulcrum) with turbine 2.2bx so there will be help about.  Other than this I
suggest you check the mail archive as I am pretty sure a couple of people
have posted their steps (at a very high level) for achieving this.  What I
want to do however is to determine a good way of doing it and then to
document it to replace the t2.1 extend-user howto.  This is in fact the main
thing holding me (and at least a few others) back from migrating forward to
t2.2.  I just have to find some time to look into it ;-)

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>