> > what get/set perm does is serialize data to the OBJECTDATA column of the
>TURBINE_USER...
>
> I'm pretty sure that is what it does, although I haven't used this feature myself.
>Strike that, I have tried it and it
> does work (I just tried it for my Title attribute).
>
> > Can someone who knows confim or deny these facts?
get/setPerm works whether there is a column to store the data or not.
One additional note, in 2.1 you will probably need to modify the
TurbineUserMapBuilder (not sure that is the exact classname), to add the
additional column(s) in addition to defining them in the xml schema.
Regarding no get/setUserId methods or any other methods missing due to
2.1 security classes not following the torque model 100%.
Create adapters that extend TurbineUser and/or TurbineUserPeer and use
the adapter classes in the baseClass/basePeer attributes of your
application schema.
TurbineUserAdapter extends TurbineUser
{
getUserId() {return getPrimaryKey();}
...
}
<table name="NewAppUser" baseClass="com.mycompany.om.TurbineUserAdapter"
...
Scott Eade wrote:
>
> From: "Dan Bachelder" <[EMAIL PROTECTED]>
> > The compile problem... Maybe what needs to happen is to add the key to your new
>user... do the init to create the auto
> generated classes... Implement the getUserId method, THEN add the FK to your other
>tables... and reinit.... just a
> thought....
>
> I do not think this will work because the RDF classes expecting the getUserId()
>method in BaseNewappUserImpl, rather
> than NewappUserImpl. If it does work, then it is cetrainly counter-intuitive and
>difficult to implement. Ultimately I
> think this should have a fairly straightforward solution - it is after all
>supposedly designed with this in mind (isn't
> it?)
>
> > As to how to implement other functionality.. I had trouble using other column in
>TURBINE_USER so what I did was the
> following..
> >
> > public void setSomeAttribute(Object obj)
> > {
> > setPerm("someAttribute", obj);
> > }
> >
> > public Object getSomeAttribute()
> > {
> > return (Object)getPerm("someAttribute");
> > }
> >
>
> I now know and confirm it.
>
> > I would also like to see what using the actual columns looks like in code...
> >
> > I thought I saw somewhere that turbine user was using set/get perm for several
>fields (i.e. email, confirm_status)
> even though there are columns for these attributes... I might be making that up
>though...
>
> I came across this code myself today in org.apache.turbine.om.security.TurbineUser
>and thought it very odd as the data
> is definitely stored in the available columns. It ties in to
>org.apache.turbine.services.security.db.DBUserManager. It
> seems that turbine allows for the user data to be stored in whatever medium you like
>as configured by
> services.SecurityService.user.manager in TR.props. The idea being that you can pull
>this data out of an LDAP directory
> or whatever. This is what makes me uncomfortable about the solution I currently use
>(simply moving all of the turbine
> tables into my application schema, generating TurbineUser and TurbineUserPeer
>classes as if it were a standard
> application table and retrieving records also as if they are standard application
>tables). I also recall seeing a post
> recently that indicated that this is why the TurbineUser does not implement
>getUserId() - something about there being no
> equivalent key when LDAP is used (in which case what should we be using as foreign
>keys into TURBINE_USER?).
>
> A few minutes of investigation has revealed that DBUserManager calls back into
>TurbineUserPeer.buildCriteria() which
> moves from Perm to criteria the columns it knows about and then writes the remaining
>Perm to Objectdata. Given that
> using an alias in the application schema does not generate anything new in terms of
>TurbineUser/TurbineUserPeer, this
> means that the only way to add additional attributes to TurbineUser is to use Perm
>(and thus there is no point adding
> columns to TURBINE_USER in turbine-schema.xml ... given the current design that is.)
>
> While it is excellent that turbine supports the ability to add attributes to
>TURBINE_USER with little effort (if you
> don't care for the convenience getter/setter methods you can just use
>set/getPerm()), it would be great to provide a way
> to actually get the data into real columns so that it is available to other
>applications that you might want to grant
> access to the database.
>
> That said, this could simplify what needs to go into the HOWTO for the moment - i.e.
>unless you are going to also extend
> DBUserManager, you should only use Perm to store additional attributes in
>TurbineUser.
>
> Cheers,
>
> Scott
>
> ---------------------------------------------------------------------
> 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]
