on 5/9/01 8:19 AM, "Turpin, Jay" <[EMAIL PROTECTED]> wrote:
> Jon,
>
> I have been spending a considerable amount of time attempting to understand
> how Turbine works, both by looking through CVS as well as stepping through
> code. I apologize for my ignorant questions, but spending three weeks with
> the product compared to the amount of time you've spent writing the system
> leaves me at a disadvantage. I assure you, I am not intentionally asking
> stupid questions nor am I just posting a question because I'm too lazy to
> look through CVS. Turbine is a very complex system and there are many areas
> I have not even touched. When we get stuck, the mail list is about the only
> place we can turn to for guidance.
Right, but if you have questions, ask specific questions about the code in
CVS please. That is all that I'm asking.
> BTW, looking in CVS at the latest version of
> org.apache.turbine.om.security.peer.UserPeer, it is implemented as an
> interface. It no longer contains any code, it just extends
> org.apache.turbine.services.security.impl.db.entity.UserPeer, which is in
> the attic in CVS. Please educate.
You are right and I am wrong. I apologize. I was really thinking that
because generated Peer's don't have interfaces, we wouldn't have created
them for the hard coded user/role/perm stuff. I was wrong. There is an
interface, but I wouldn't really count on it right now as that is not the
way to do things at this point in time. Keep reading...
There are several things going on right now:
#1. Torque Generated Peers do not have interfaces. I spent yesterday
discussing with John and Daniel the need for this and we decided that
implementing this in the Torque generation system will be a major pain in
the ass. So we shelved it for now. If you would like to implement this, I
would love it, but it isn't entirely necessary at this point in time. Keep
reading...
#2. We can hold off on implementing this because Torque now supports the
concepts of class hierarchy.
<http://jakarta.apache.org/turbine/classhierarchy.html>
Except for a couple places that I'm going to be working on in the next few
days, the above methodology fits the bill. What you end up doing is simply
extending the existing OM/Peer classes with objects that map to your
database/tables. You then create a factory which will instantiate the
correct OM classes. The changes that I need to make to Torque are to make it
so that the Peers instantiate the right class...right now, they don't
entirely do that...but are very close.
#3. The goal is to eventually move all the user/role/permission/group stuff
to using Torque instead of the currently hand coded BO's and peers (they
were done long before Torque existed). So, that is why I'm saying that
making/using the interface isn't really needed at this point in time. If you
would like to work on that part of things, that would be great as well. Just
make sure to ensure 100% backward compatibility through the use of
deprecation. If you don't get to it, I will in the next few weeks. I think
it is a must have before release. Something about eating our own dog food.
:-)
So, let me know how you want to progress...
-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]
