So if I understand the thread properly, are you proposing to get rid of the
Group, Role and Permission class interfaces? How will this affect the
TurbineSecurity, BaseSecurity, DBSecurityService chain, since these
functions typically pass the interface?
A co-worker and I spent all day yesterday trying to shoehorn the new Torque
*Group* classes, which we like BTW, into the existing Group interface. Much
more difficult than we first imagined. I would love to at least redesign the
Group interface to be more in line with the new OM class, but that seems to
affect a number of other modules, and we still don't have a good
understanding of everything that would be touched by this change.
Any guidance will be appreciated.
Regards,
Jay Turpin
-----Original Message-----
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 10, 2001 4:47 PM
To: turbine-dev
Subject: Re: Plans for TurbineGroup, TurbineRole, etc.
on 5/10/01 4:37 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
>
>
> Jon Stevens wrote:
>
>> on 5/10/01 12:17 PM, "Martin Poeschl" <[EMAIL PROTECTED]> wrote:
>>
>>> sounds like a job for me ;-)
>>>
>>> i generated the classes with torque ...
>>>
>>> some the method names are different (e.g. getCreateDate() ->
getCreated() )
>>> should i change the interface (and also the LDAP classes)?
>>> or add the methods to match the interface?
>>
>> Ok, the way to do this without breaking existing code and giving people a
>> chance to migrate is to put the generated classes into a different
package
>> (you will have to do that anyway since the Peer objects are no longer in
a
>> .peer. package).
>>
>> Then, you essentially replace all the code in the existing
methods/classes
>> with calls to the new code in the new packages. The old stuff just
becomes a
>> thin wrapper around the new stuff. You mark everything in the old stuff
as
>> being deprecated.
>>
>> Make sense?
>
> hmmm ... and what should happen to the interface???
> should i add the methods like they are generated and mark the old ones as
> deprecated too??
> then i have to update the ldap stuff too ...
>
> so the new interface will have the same methods as the generated classes
...
For now, get rid of the interfaces (well, leave them where they are, but
don't make the torque generated stuff use them) since that isn't something
that the Torque stuff uses anyway. When we upgrade torque to support
generation of interfaces, then that is when it will make more sense...
When I finish Scarab's Module abstraction stuff, I will look into enhancing
torque to generate the interfaces...
> why do you think we need a different package name???
Just for clarity and ease...the o.a.t.o.s.p package will go away? What about
people who were depending on that code?
> i think org.apache.turbine.om.security will work ... i can add the
deprecated
> method to the generated classes ...
Hmmm...you mean the generated Extend*.vm classes?
I like o.a.t.o.s so maybe you can try to find a way to keep it...
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
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]
