[adm2-dev] Synchronize properties

Currently the properties are hard-coded in many places and the format is

different in SDOs and SBOs. Any overrides you do in 9.1C will most likely

need to be moved in 9.1D, because important performance improvements

requires us to bypass those procedures/functions.

Also note that there are basically 3 types of properties and they are

managed in different places.

A. true context - bidirectional (lastRowNum, firstrownum etc... )

B. from client to server on each call (rebuildOnrepos, checkcurrentchanged )

C. from server to client on first call

(typical meta schema info like dbnames, indexInformation etc)

in 9.1C data.p (sdo)

A. genContextList

B. initializeServerObject

C. synchronizeProperties

So you should be able to achieve this with an override of genContextList.

Unfortunately, the sbo does not use this and all the properties are

hard-coded in different methods.

9.1C sbo.p

A and B. initializeServerObject

A and B. endClientDataRequest

A and B getContextAndDestroy.

C. serverFetchDoProperties - first time properties.

Dynam,ics and 9.1D

The 9.1D (under development) and Dynamics FCS have overridable APIs that are

more future proof and called from every possible place, including

synchronizeProperties and initializeServerObject.

They still need to be overridden separately in SDOs and SBOs though.

context = obtainContextForServer() |--| setContextAndIntialize(context)

applyContextFromServer(context) |

There is also an issue entered to get this as properties, but this is

currently not on the schedule for 9.1D. This is of course subject to

change...

http://www.possenet.org/issues/show_bug.cgi?id=2952

Havard

-Original Message-

From: Wim van der Ham

Sent: Friday, February 22, 2002 4:18 AM

To: dev@adm2.possenet.org

Subject: Synchronize properties

Hello all,

What's the best way to synchronize ADDITIONAL USER properties between the

(Web)Client and (stateless) Appserver ?

Should I create an override of synchronizeproperties and if so, were?

What's the requested format to pass properties from-to the appserver?

Is there any document on this issue?

Many TIA,

Wim

____________________________

Design, Development, Training

and Implementations in Italy

Tutto in Progress (r) !

(www.progress.com)

Wim van der Ham

Tel: +39 011 4527691

GSM: +39 335 6877283

Fax: +39 335 0 6877283

ICQ: 397259

To unsubscribe, e-mail: dev-unsubscribe@adm2.possenet.org

For additional commands, e-mail: dev-help@adm2.possenet.org

To unsubscribe, e-mail: dev-unsubscribe@adm2.possenet.org

For additional commands, e-mail: dev-help@adm2.possenet.org

The original question was posed 10 years ago...

What would the answer be to the same questions TODAY using ADM2 version 10.1C?

Many TIA,

Wim

The answer is the same as it was 10 years ago. It may very well be close to 10 years since I looked at or touched this code also, so I may miss something, but I believe the only change we have done after 9.1D was to reduce the size of the returned indexInformation to only return what it really can need, since it blew up the character limit for tables with many indexes . We may possibly also have fixed the sbo to use the sdo context. I may  confuse the sbo with the datacontainer (=any container marked as  appserver aware) though.

We never implemented the mentioned ability to use properties to define the context property names, so you would still override obtainContextForServer to pass context to the server and override obtainContextForClient to pass context back to the client. The context string is a chr(3) delimited list with a chr(4) delimiter between the property name and value. (I think you can use chr(4) only). Your override should add your property name and value to the string returned from the super call. Take care to avoid unknown values (Can be passed as "?" if necessary). If you have context that you only want to return to the client on the first call you can check the ServerFirstCall property (before the call to super()) and only append when it is true. I believe you alternatively can override the genContextList procedure if you have properties that need to be passed both ways, but I could be wrong about this.

You need corresponding set functions - set(pcValue as ) to receive the property values.