All source and detailed instructions are included in the howto at:
http://jakarta.apache.org/turbine/turbine-2/howto/extend-user-howto.html

Scott

----- Original Message -----
From: "Frans Thamura" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 23, 2001 7:23 AM
Subject: Re: Extending TurbineUser


> Dear Scott,
>
> I new in Turbine,
>
> Would  you send me the source code to me?
>
> So, I just compile it and try it, I still confuse with extending Turbine.
>
>
> Frans
> ----- Original Message -----
> From: "Scott Eade" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 18, 2001 11:06 AM
> Subject: Re: Extending TurbineUser
>
>
> > Humberto,
> >
> > I think part of the reason why the schemas are split between
> > turbine and the applications is because TurbineUser is a critical part
> > of the security mechanism and also because there is the basis for
> > retrieving the user information from some place else - e.g. an LDAP
> > server.
> >
> > I originally copied TurbineUser into my applications schema.xml
> > file so that I could add a bunch of attributes to the table and use
> > userId as foreign keys in my application tables.  The down side of
> > this approach is that I often end up coding data.User.getUserId()
> > and passing the result to the object model classes generated by the
> > TurbineUser defined in my application schema - not very efficient
> > because I will often be reading the TurbineUser table twice in a
> > single transaction.
> >
> > The up side however was that I could save changes to my
> > TurbineUser data and associated tables in a single transaction -
> > this is particularly important when you make use of the methods
> > torque generates when it encounters foreign key references to a
> > table.
> >
> > Because of the down side I was never really happy with the
> > above solution and I set aside some time to reimplement the
> > necessary parts of my application in what I thought would be
> > the best way - i.e. extending TurbineUser as documented in the
> > howto.
> >
> > This worked well until it came to invoking TurbineUser.save()
> > which fails to save any of the related objects that may have been
> > added to the TurbineUser object by way of the torque methods
> > generated because of foreign key definitions.  These methods are
> > generated and appear to be useful, but at the end of the day they
> > don't perform their advertised function of associating the added
> > data with the TurbineUser record (worse than that, the data is
> > simply discarded).
> >
> > Check this message for details:
> >
>
http://www.mail-archive.com/turbine-user%40jakarta.apache.org/msg03447.html
> > This information should really be appended to the howto.
> >
> > I have actually abandoned the work I did on extending
> > TurbineUser and reverted to the first method until I have
> > aditional time available to consider other possible solutions.
> >
> > Cheers,
> >
> > Scott
> >
> > ----- Original Message -----
> > From: "Humberto Hernadez Torres" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, October 18, 2001 10:53 AM
> > Subject: Extending TurbineUser
> >
> >
> > We just finished extending TurbineUser. Thank God for the HOWTO
> > document. YES!!!!
> >
> > It seems to me that it is a very long and painful process for something
> > that it is very commonly needed. If I understood the problem well the
> > root cause of the problem is this:
> > - The Object model for TurbineUser is already generated within the
> > turbine.jar so it has to be extended by hand.
> > - We have a separate turbine-schema.xml from the newapp-schema.xml
> > therefore it isn�t easy to have foreign keys between them.
> >
> > Don�t you think the process would be simpler if the turbine schema were
> > defined within newapp-schema.xml and generated automatically.
> >
> > As a by product the WEB-INF/build/build.xml would be smaller and
> > simpler. This file is probably a mistery for most beginners.
> >
> > What do you think? Is this crazy or just plain stupid? I am sure there
> > may be some reasons to have the schemas divided.
> >
> > --
> >   Humberto
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to