Hi!

I think a change like this needs to be voted. I personally do not see a need 
for it. I admit I may not be understanding the problem correctly, but as I 
see it now, no changes to Peers are needed.

Could you describe better why simply making  Attribute.java (in your example) 
implement any interface you need. Since you can edit Attribute.java there is 
no need to change anything in Peers. What's the specific need to bother with 
BaseAttribute?  AFAIR you never work directly with BaseSomething so it should 
not be important which interfaces it implements...
Also I do not entirely understand the intention behind _instance_ 
getNewInstance method (which rather sounds like a good name for a boy... i 
mean  for a static factory method)

As you guessed it I am -1 ATM.

dixi

Fedor.

On Sunday 06 May 2001 21:06, you wrote:
> Well,
>
> It turns out that in order for the Peer system to support the ability to
> have multiple targets to a base object, we need to define an interface for
> the BO's so that they reference the interface only. This pattern is similar
> to what the TurbineSecurity system does already, however, that system is
> coded with hand coded Peer's. That is why we haven't run into this problem
> before.
>
> So, what is changing? All that is changing is that the BaseFoo objects are
> going to be coded against an interface (that is also auto generated). So,
> imagine that you have a table in your database called "ATTRIBUTE", the
> classes that are generated are:
>
> public abstract class BaseAttribute extends BaseObject
>     implements Retrievable, Persistent, AttributeInterface
>
> The AttributeInterface looks like this:
>
> public interface AttributeInterface
> {
>     /**
>      * The class which extends this class needs to implement this
>      * method. This allows you to provide an alternative BO by
>      * extending the BO and overriding/implementing this method
>      * yourself.
>      */
>     public AttributeInterface getNewInstance()
>         throws Exception;
> }
>
> The implementation of the method (in the Attribute.java class) looks like
> this:
>
>     public AttributeInterface getNewInstance()
>         throws Exception
>     {
>         return (AttributeInterface) new Attribute();
>     }
>
> Now, the API change I'm working on is that if you are currently using the
> Peer system, you will need to implement this method yourself. I have
> modified Torque to generate the method for new installations, but
> unfortunately, Torque doesn't have any facilities to modify existing
> installations. So, that is the pain in the butt for you. I just did it with
> Scarab and it only took me about 10 minutes to add this method to Scarab's
> ~15 tables.
>
> What I'm also doing is going through Torque and removing all references to
> the BO's from the BasePeer/BaseBO and simply referring to the interface or
> to the Base object as needed. I'm not finished with this step yet, but
> initial experimentation looks very good.
>
> I'm giving this notification now so that we can discuss it. I have not
> checked in any of this code as I'm not finished yet, but I do plan on fully
> testing everything with Scarab before checking things in.
>
> Once this is done, I might work towards making the User/ Role/ Permission/
> Group Peer objects be based on Torque instead of the currently hard coded
> stuff. This is something I would like to see happen before 2.1 is released.
>
> thanks,
>
> -jon
>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to