Thought inc.

The Dynamic O/R Mapping Company
     

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Suggestions
Define an interface for proxies
< Previous Thread     Next Thread >
Author
Thread    Post New Thread     Post A Reply
steve
Member

Registered: May 2001
Posts: 16

In the "Cocobase Questions" forum (thread "Transactions and user-defined generic proxies"), I was told that the only proxy class supported by the Transaction object was CocoProxyM and that I should derive my proxies from that object if I wanted transaction support. That works but I like to suggest defining a proxy interface. There are several reasons for this suggestion. CocoProxyM is a concrete object and I may not need or want all of it's functionality in my application-specific proxy class. Also, my understanding is that the "M" in the name signifies that it is a method-based proxy (vs. the CocoProxy which is field based). I have defined a custom field-based proxy, yet I have to inherit from CocoProxyM. This seems a bit strange. If a proxy interface were defined and then implemented by both CocoProxy and CocoProxyM, they both could be supported by the transaction code. Furthermore, it would provide end users with a cleaner mechanism for defining custom proxies with full transaction support.

05-24-2001 06:58 PM
Click Here to See the Profile for steve    Find more posts by steve        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

Actually we don't need a Proxy Interface, that's what the
CBProp inteface is. The issue is that we haven't modified
the Transaction object to allow you to override the proxy
with an additional version of a class that implements that
interface. We will allow that extension eventually, it just
hasn't been a high enough priority since we ship the class
CocoProxyM as source code to customers for their extensions
to be added. You can find the source code in the demos\pguide
subdirectory of the product.

Hope that helps clarify this!

THOUGHT Support

05-24-2001 08:00 PM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
steve
Member

Registered: May 2001
Posts: 16

CBProp doesn't satisfy all the requirements of a Proxy for Transaction purposes. If it did, then CocoProxy could also be used with Transactions since it implements CBProp. Specifically, you need additional semantics for a Proxy interface. For example, accessors for the proxy's delegate object (e.g. setObject/getObject) so that the Transaction can copy the delegate's state when an object is bound to a Transaction. The Proxy interface should also derive from Cloneable or an equivalent so the proxy object's state can be copied along with the delegate's state. As an example, during our evaluation we have created a high performance proxy that doesn't look up data field and method objects on every setPropObjectData. To support this approach, we needed to store the map name in the proxy. The problem is that the map name is not copied with the proxy during a Transaction bind. To workaround the problem we had to derive from CocoProxyM and use the setKeyValue/getKeyValue methods of that class to pass the map name. A little strange, to say the least, but it worked. We're keeping our fingers crossed that we don't need the set/getKeyValue methods for their intended purpose. A proxy interface with delegate access and cloning ability would be a much better solution.

05-24-2001 09:09 PM
Click Here to See the Profile for steve    Find more posts by steve        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

Ok there are several things we need to respond to in this
email.

1) We'll be producing a solution for using multiple Proxy
objects, but you can just as easily incorporate your
enhancements into the CocoProxyM class without requiring a
separate Proxy interface.

2) The Transaction object does copy the 'state' of the object
if CocoProxyM is used so if you follow step 1 this will happen.

3) The Transaction should be bound using the map name if you
are using a CocoProxyM so instead of

cocoTxn.bind(proxyInstance);
instead use:
cocoTxn.bind(proxyInstance, mapName);

4) CocoProxyM already implements cloneable.

Hope this helps explain this better.

THOUGHT Support

05-25-2001 10:37 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread     Next Thread >

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.