You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Humberto Hernadez Torres <hh...@itweb.com.mx> on 2001/10/18 02:53:24 UTC

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: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Extending TurbineUser

Posted by Scott Eade <se...@backstagetech.com.au>.
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" <ft...@yahoo.com>
To: <tu...@jakarta.apache.org>
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" <se...@backstagetech.com.au>
> To: <tu...@jakarta.apache.org>
> 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" <hh...@itweb.com.mx>
> > To: <tu...@jakarta.apache.org>
> > 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: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Extending TurbineUser

Posted by Frans Thamura <ft...@yahoo.com>.
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" <se...@backstagetech.com.au>
To: <tu...@jakarta.apache.org>
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" <hh...@itweb.com.mx>
> To: <tu...@jakarta.apache.org>
> 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: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Extending TurbineUser

Posted by Scott Eade <se...@backstagetech.com.au>.
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" <hh...@itweb.com.mx>
To: <tu...@jakarta.apache.org>
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: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org