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/27 17:47:54 UTC

single User class

Hi there,

I wonder if anybody is out there who has been trying to "synchronize"

a) org.apache.turbine.om.security.TurbineUser, the User-Implementation that
offers Turbine-backend functionality with
b) com.mycom.om.TurbineUser(Peer), the Peer classes that are used to access
table turbine_user

in order to have the functionality of both classes under a single
cover(class).

I have not yet understood if there is a common solution for this, or if this
is solved completely according to individual needs. Can somebody give me an
idea briefly?

Also, it irretates me that *both* org.apache.turbine.om.security.TurbineUser
and com.mycom.om.TurbineUser provide get/set-methods for the fields in table
turbine_user. Why is that?

Actually I have been trying the whole week to discover the most clean way to
implement custom business logic for the user. TurbineUserPeer apparently is
one place to do that. But when it comes to extending security management,
extending org.apache.turbine.om.security.TurbineUser seems to make more
sense.
So...  I was wondering if it's possible to have a single class for all kind
of user-functionality, including my own custom methods.

Thanks.

Marc


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


Re: Protecting an extended Peer class

Posted by Guido Sohne <gu...@sohne.net>.
The BaseXXX and BaseXXXPeer classes will be overwritten but XXX
and XXXPeer classes will not be overwritten if they already exist.

Move your application logic into XXX and XXXPeer. As a rule you
should not change the Base classes ...

On Fri, Sep 27, 2002 at 02:39:06PM -0400, Bruce Altner wrote:
> Greetings:
> 
> I'm in the initial stages of my second Turbine-based application and find 
> that I have to extend the behavior of one of my custom-defined Peer 
> classes. I have done this already and it works fine. However, as the 
> project progresses I will very likely need to regenerate the Peer classes 
> from time to time (at least that's what happened in my first project) and 
> this will "erase" the changes I've already made, since these were code 
> changes rather than changes to the schema itself.
> 
> Is there a recommended way to prevent this from happening? I guess I could 
> always pull the extended class out of CVS but I was thinking that there 
> might be a better way, e.g., one that didn't overwrite extended classes 
> each time I need to execute the ant "project-om" target.
> 
> Thanks,
> Bruce
> 
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 

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


RE: Protecting an extended Peer class

Posted by Chris K Chew <ch...@fenetics.com>.
>Bruce Altner:
>one that didn't overwrite extended classes
>each time I need to execute the ant "project-om" target.

Take a look at the Torque tutorial on the jakarta website.  What you are
looking for is mentioned in Step 4 and again in the "Adding Functionality to
the Object Model" section.

http://jakarta.apache.org/turbine/torque/tutorial.html

Chris


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


Protecting an extended Peer class

Posted by Bruce Altner <ba...@hq.nasa.gov>.
Greetings:

I'm in the initial stages of my second Turbine-based application and find 
that I have to extend the behavior of one of my custom-defined Peer 
classes. I have done this already and it works fine. However, as the 
project progresses I will very likely need to regenerate the Peer classes 
from time to time (at least that's what happened in my first project) and 
this will "erase" the changes I've already made, since these were code 
changes rather than changes to the schema itself.

Is there a recommended way to prevent this from happening? I guess I could 
always pull the extended class out of CVS but I was thinking that there 
might be a better way, e.g., one that didn't overwrite extended classes 
each time I need to execute the ant "project-om" target.

Thanks,
Bruce


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