RE: How to extend TURBINE_USER - a solution to the documented pro blem

["Pugh, Eric" <EP...@MuseumCompany.com>]

Scott,

I am not sure how many changes you are proposing, but one change that I
would love to see is that the interface User was a lot more abstract.  For
our company right now, we use microsoft technologies, and all our users are
stored using NT Authentication.  Until I can hook turbine up to ask for a
username and password that is validated against the NT domain, it doesn't
make sense for us to duplicate users passwords into the Turbine tables.
Therefore, we decided as a stop gap, that since usernames change rarely, but
passwords change frequently, that we would use an already existing table
EMPLOYEE, and just add an OBJECTDATA column to it to store extended Turbine
information.  Unfortuantantly, the existing TurbineUser interface has led to
a lot of problems for us.

Our EMPLOYEE table schema:
EMPLOYEE_ID int
USERNAME	varchar
ACTIVE	bit
OBJECTDATA	image

Therefore we don't have things like getConfirmed values, Last Access Date,
Last Name, Password, etc..  Now, a lot of that could have been stored as
part of the ObjectData value, but we didn't need any of that.

I ended up hacking up a lot of the Turbine's built in code for handling
users to make it work with our system, but it is not very pretty.
Eventually, when we go back to having username AND password for
authentication, then we can go back to using the existing Turbine system.
But in the meantime, what would have made life much easier would be to have
a very basic interface for User and TurbineUser.  That way we wouldn't have
to dummy up a lot of values and methods.

My code that I used is viewable as a zip at http://briefcase.yahoo.com/dep4b
in the Java directory.

Just my 2 cents...

Eric

-----Original Message-----
From: Scott Eade [mailto:seade@backstagetech.com.au]
Sent: Friday, January 04, 2002 6:36 AM
To: turbine-user@jakarta.apache.org
Subject: How to extend TURBINE_USER - a solution to the documented
problem


About a month ago I revisited the work I did earlier on
extending turbine_user.  My goal was to overcome the
problem I had identified and documented about 3/4 of
the way down the extend-user-howto under the heading
"Additional Information (Added 12 Nov 2001)".  To 
summarise, after going through all of the effort to extend
turbine_user, the implementation is incomplete because
user.save() fails to save any related objects you may have 
added using the generated user.addXXX() methods.

By making some small changes to torque's Object.vm 
template it is possible to have the code necessary to 
save the related objects generated in the OM class
for the turbine_user alias.  This solution is reasonably
small and it works well (I am using it in a production
site).

The only trouble with this solution is that it seems a
bit like a hack because it mixes non-turbine security
objects with turbine security objects - you can include
the user.save() in a transaction, but the saving of the
actual turbine_user record will not be part of the
transaction because the turbine db security 
implementation does not allow for this.

Anyway, I have a solution that works.  My question
is, should I submit a patch to Object.vm that could
be considered to be a hack or should I just outline the
hack in a patch to extend-user-howto so that interested 
users can apply the patch themselves?  


BTW: Anyone that has extended turbine_user will love 
this change.  With it you can use data.getUser() just 
like any other OM class (after casting it to your alias 
class).

Any thoughts?

Scott



--
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>