You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Jonas Denvall <jo...@arkatay.com> on 2002/08/27 11:32:43 UTC
Re: Mapping between turbine.om.security.User and om generatedTurbineUser
Thanx for your answer Peter. I need some clarifications, though:
>Basically, you implement your own User object (look at the User-Extend
Howto) via an Adapter class that extends
>org.apache.turbine.om.security.TurbineUser.
I somehow missed that step in the User-Extend How-to, regarding the
TurbineUser adapter class. That's why my MyUser object extends
com.mycompany.myapp.om.TurbineUser instead of
org.apache.turbine.om.security.TurbineUser (via the adapter class),
since I omitted the basClass and basePeer attributes. That will solve
some of my problems, thanx.
But I was under the impression that the User-Extend How-to guide is
applicable only for Turbine 2.1. I'm using TDK 2.2 b3, including the
Torque 3.0-b4. What issues in User-Extend How-to have changed in version
2.2? I've seen many questions about this, but no clear guides. I've read
that there is no need to write Adapter classes in 2.2 (see the message
link below), is this true, and why?
Another question:
Following the guidelines in
http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg07569.htm
l,
I have not only created my own MyUser table / class, (extending the
TurbineUser), but also stripped the Turbine_User table of some
attributes, such as FirstName and LastName. The reason for this is to
gather as much data as possible in the MyUser table. But, what happens
when the MyUser extends org.apache.turbine.om.security.TurbineUser? That
class provides methods for retrieving FirstName and LastName - that
don't exist in the database, and that does not feel good ;-). Am I on
the wrong track here, am I not supposed to remove attributes from the
TurbineUser table?
Thanx again,
Jonas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mapping between turbine.om.security.User and
omgeneratedTurbineUser
Posted by Peter Neubauer <pe...@yahoo.se>.
On Tue, 2002-08-27 at 19:40, Alexander Banthien wrote:
> Hi Peter,
>
> how did you get around the problem in the class map.TurbineUserPeerAdapter.java (cf. Extend User Howto) when generating a
> -------------
> private static MapBuilder mapBuilder getMapBuilder();
> --------------
> how do you do that? is it required anymore?
>
> Problem is that this statement is called outside any method and no Exception handling can take place. (compile error)
> The alternative, to call this method with a String, i don't understand. What must I put inas an argument?
>
> Thanks in advance
>
> Alex
Hi,
since we don't extend or deminish the TurbineUser tables, the whole
thing works with the default MapBuilder. Just omit this class and you
will be fine with the DeaultMapBuilder.
regards
/peter
>
> Peter Neubauer wrote:
>
> > On Tue, 2002-08-27 at 11:32, Jonas Denvall wrote:
> > > Thanx for your answer Peter. I need some clarifications, though:
> > >
> > > >Basically, you implement your own User object (look at the User-Extend
> > > Howto) via an Adapter class that extends
> > > >org.apache.turbine.om.security.TurbineUser.
> > >
> > > I somehow missed that step in the User-Extend How-to, regarding the
> > > TurbineUser adapter class. That's why my MyUser object extends
> > > com.mycompany.myapp.om.TurbineUser instead of
> > > org.apache.turbine.om.security.TurbineUser (via the adapter class),
> > > since I omitted the basClass and basePeer attributes. That will solve
> > > some of my problems, thanx.
> > >
> > > But I was under the impression that the User-Extend How-to guide is
> > > applicable only for Turbine 2.1. I'm using TDK 2.2 b3, including the
> > > Torque 3.0-b4. What issues in User-Extend How-to have changed in version
> > > 2.2? I've seen many questions about this, but no clear guides. I've read
> > > that there is no need to write Adapter classes in 2.2 (see the message
> > > link below), is this true, and why?
> > I don't know about that, but I implemented the adapter class anyway, in case you need to bridge some functionality (like inserting
> > a custom getUserName() function etc.
> > What has changed is that the BasePeer and Criteria Classes are now
> > located in Torque:
> >
> > import org.apache.torque.util.BasePeer;
> > import org.apache.torque.util.Criteria;
> >
> > (comes from TurbineUserPeer in Turbine)
> >
> > whereas the older turbine version have the BasePeer and Criteria in
> > turbine. That gives runtime problems since you construct Torque
> > criterias in your application, but the BasePeer is taking Turbine
> > criterias because of inheritance through the apapter classes.
> > >
> > > Another question:
> > > Following the guidelines in
> > > http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg07569.htm
> > > l,
> > > I have not only created my own MyUser table / class, (extending the
> > > TurbineUser), but also stripped the Turbine_User table of some
> > > attributes, such as FirstName and LastName. The reason for this is to
> > > gather as much data as possible in the MyUser table. But, what happens
> > > when the MyUser extends org.apache.turbine.om.security.TurbineUser? That
> > > class provides methods for retrieving FirstName and LastName - that
> > > don't exist in the database, and that does not feel good ;-). Am I on
> > > the wrong track here, am I not supposed to remove attributes from the
> > > TurbineUser table?
> > >
> > I tried that too, but looking at the source and activating the sql logs
> > in torque reveals that e.g. the Flux modules and turbine itself are
> > having dependencies, like an orderBy TURBINE_LOGIN name in a select I
> > saw.
> > I think it is no problem to leave the TURBINE_USER table as is, but not
> > using its columns except TURBINE.LOGIN_NAME and PASSWORD. The rest you
> > can do within your app_user.
> >
> > /peter
> >
> > > Thanx again,
> > > Jonas
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> > _____________________________________________________
> >
> > Gratis e-mail resten av livet på www.yahoo.se/mail
> >
> > Busenkelt!
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
>
> Mit freundlichen Grüßen
> Alexander Banthien
>
> _______________________________________
> Questech GmbH
> Schwarzwaldstr. 19
> 79199 Kirchzarten
>
> Fon: +49 (0)7661 90 35-15
> Fax: +49 (0)7661 90 35-20
> www.questech.de
>
> _______________________________________
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
_____________________________________________________
Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002
Håll dig ajour med nyheter och resultat, med vinnare och förlorare...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mapping between turbine.om.security.User and omgeneratedTurbineUser
Posted by Alexander Banthien <al...@questech.de>.
Hi Peter,
how did you get around the problem in the class map.TurbineUserPeerAdapter.java (cf. Extend User Howto) when generating a
-------------
private static MapBuilder mapBuilder getMapBuilder();
--------------
how do you do that? is it required anymore?
Problem is that this statement is called outside any method and no Exception handling can take place. (compile error)
The alternative, to call this method with a String, i don't understand. What must I put inas an argument?
Thanks in advance
Alex
Peter Neubauer wrote:
> On Tue, 2002-08-27 at 11:32, Jonas Denvall wrote:
> > Thanx for your answer Peter. I need some clarifications, though:
> >
> > >Basically, you implement your own User object (look at the User-Extend
> > Howto) via an Adapter class that extends
> > >org.apache.turbine.om.security.TurbineUser.
> >
> > I somehow missed that step in the User-Extend How-to, regarding the
> > TurbineUser adapter class. That's why my MyUser object extends
> > com.mycompany.myapp.om.TurbineUser instead of
> > org.apache.turbine.om.security.TurbineUser (via the adapter class),
> > since I omitted the basClass and basePeer attributes. That will solve
> > some of my problems, thanx.
> >
> > But I was under the impression that the User-Extend How-to guide is
> > applicable only for Turbine 2.1. I'm using TDK 2.2 b3, including the
> > Torque 3.0-b4. What issues in User-Extend How-to have changed in version
> > 2.2? I've seen many questions about this, but no clear guides. I've read
> > that there is no need to write Adapter classes in 2.2 (see the message
> > link below), is this true, and why?
> I don't know about that, but I implemented the adapter class anyway, in case you need to bridge some functionality (like inserting
> a custom getUserName() function etc.
> What has changed is that the BasePeer and Criteria Classes are now
> located in Torque:
>
> import org.apache.torque.util.BasePeer;
> import org.apache.torque.util.Criteria;
>
> (comes from TurbineUserPeer in Turbine)
>
> whereas the older turbine version have the BasePeer and Criteria in
> turbine. That gives runtime problems since you construct Torque
> criterias in your application, but the BasePeer is taking Turbine
> criterias because of inheritance through the apapter classes.
> >
> > Another question:
> > Following the guidelines in
> > http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg07569.htm
> > l,
> > I have not only created my own MyUser table / class, (extending the
> > TurbineUser), but also stripped the Turbine_User table of some
> > attributes, such as FirstName and LastName. The reason for this is to
> > gather as much data as possible in the MyUser table. But, what happens
> > when the MyUser extends org.apache.turbine.om.security.TurbineUser? That
> > class provides methods for retrieving FirstName and LastName - that
> > don't exist in the database, and that does not feel good ;-). Am I on
> > the wrong track here, am I not supposed to remove attributes from the
> > TurbineUser table?
> >
> I tried that too, but looking at the source and activating the sql logs
> in torque reveals that e.g. the Flux modules and turbine itself are
> having dependencies, like an orderBy TURBINE_LOGIN name in a select I
> saw.
> I think it is no problem to leave the TURBINE_USER table as is, but not
> using its columns except TURBINE.LOGIN_NAME and PASSWORD. The rest you
> can do within your app_user.
>
> /peter
>
> > Thanx again,
> > Jonas
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> _____________________________________________________
>
> Gratis e-mail resten av livet på www.yahoo.se/mail
>
> Busenkelt!
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Mit freundlichen Grüßen
Alexander Banthien
_______________________________________
Questech GmbH
Schwarzwaldstr. 19
79199 Kirchzarten
Fon: +49 (0)7661 90 35-15
Fax: +49 (0)7661 90 35-20
www.questech.de
_______________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mapping between turbine.om.security.User and om
generatedTurbineUser
Posted by Peter Neubauer <pe...@yahoo.se>.
On Tue, 2002-08-27 at 11:32, Jonas Denvall wrote:
> Thanx for your answer Peter. I need some clarifications, though:
>
> >Basically, you implement your own User object (look at the User-Extend
> Howto) via an Adapter class that extends
> >org.apache.turbine.om.security.TurbineUser.
>
> I somehow missed that step in the User-Extend How-to, regarding the
> TurbineUser adapter class. That's why my MyUser object extends
> com.mycompany.myapp.om.TurbineUser instead of
> org.apache.turbine.om.security.TurbineUser (via the adapter class),
> since I omitted the basClass and basePeer attributes. That will solve
> some of my problems, thanx.
>
> But I was under the impression that the User-Extend How-to guide is
> applicable only for Turbine 2.1. I'm using TDK 2.2 b3, including the
> Torque 3.0-b4. What issues in User-Extend How-to have changed in version
> 2.2? I've seen many questions about this, but no clear guides. I've read
> that there is no need to write Adapter classes in 2.2 (see the message
> link below), is this true, and why?
I don't know about that, but I implemented the adapter class anyway, in case you need to bridge some functionality (like inserting
a custom getUserName() function etc.
What has changed is that the BasePeer and Criteria Classes are now
located in Torque:
import org.apache.torque.util.BasePeer;
import org.apache.torque.util.Criteria;
(comes from TurbineUserPeer in Turbine)
whereas the older turbine version have the BasePeer and Criteria in
turbine. That gives runtime problems since you construct Torque
criterias in your application, but the BasePeer is taking Turbine
criterias because of inheritance through the apapter classes.
>
> Another question:
> Following the guidelines in
> http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg07569.htm
> l,
> I have not only created my own MyUser table / class, (extending the
> TurbineUser), but also stripped the Turbine_User table of some
> attributes, such as FirstName and LastName. The reason for this is to
> gather as much data as possible in the MyUser table. But, what happens
> when the MyUser extends org.apache.turbine.om.security.TurbineUser? That
> class provides methods for retrieving FirstName and LastName - that
> don't exist in the database, and that does not feel good ;-). Am I on
> the wrong track here, am I not supposed to remove attributes from the
> TurbineUser table?
>
I tried that too, but looking at the source and activating the sql logs
in torque reveals that e.g. the Flux modules and turbine itself are
having dependencies, like an orderBy TURBINE_LOGIN name in a select I
saw.
I think it is no problem to leave the TURBINE_USER table as is, but not
using its columns except TURBINE.LOGIN_NAME and PASSWORD. The rest you
can do within your app_user.
/peter
> Thanx again,
> Jonas
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
_____________________________________________________
Gratis e-mail resten av livet p� www.yahoo.se/mail
Busenkelt!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>