Hi,
>2. Creating an additiona table in the database containg all personal
> information about an user, using only VISITORID, LOGINID, PASSWORD_VALUE
> and CONFIRMED_VALUE from Visitor (let's say, these are system-level information,
> and our table is application-level information).
> We could also use Peers model creating classes UserInfomation and
> UserInformationPeer, and subclass TurbineMapBuilder as neccessary.
Sounds a bit like option number 1. Wouldn't this give the same kind of problems?
>
> 3. Create an SQL script to ALTER TABLE VISITOR ADD ... the fields we want,
> Subclass TurbineUser, TurbineUserPeer and TurbineMapBuilder as neccessary.
Just some thoughts on this. If you call methods like doSelect from TurbineUserPeer
you get a Vector of TurbineUser objects. A
subclass (call it SUBTurbineUserPeer ) will then also return a Vector of TurbineUser
objects. To get it to return a Vector of
SUBTurbineUser objects you will need to override methods, and in effect replace large
pieces of working code. The same goes for
TurbinMapBuilder: TurbineUserPeer and therefore subclasses references
TurbineMapBuilder and not SUBTurbineMapBuilder.
The only solution I can see to this, is to make this classes more intelligent in the
way that subclasses TurbineUserPeer knows that
it should make objects of a subclass of TurbineUser and not of TurbineUser itself.
Haven't really come up with an idea yet :-)
> 4. Other possibilites?
How about loosening up the link between TurbineUser and the Implementation of the User
interface. The User implementation can maybe
be done in such a way that it is possible to plug any Peer class that has a specific
set of fields. In other words to extend the
Visitor class, you create a table that contains all the existing fields plus add some
of your own. Then create your own peer
classes (Using NewGenerateMapBuilderTask :-). Finally you point the User
implementation to use your new set of Peer classes which
will work because you have all the original fields of visitor. This is fairly
theoretical at the moment, but it might work :-)
> Approach 1 is definetely bad, because it's unclear and hard to maintaind,
I agree! This is what I'm doing at the moment, and I would *not* reccomend it!
> but we cat't decide between 2 and 3. Any advice is wellcome!
> Thanks in advace
> Rafal
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
