[Seaside] access to the model using goods

[Leo De Marco]

>We use Seaside and GOODS to manage many business objects and we use a
>"share none" approach for Seaside client connections -- meaning each
>connection gets its own connection to GOODs and maintains its own
>objects.  Doing this avoids a myriad of issues surrounding concurrency
>when sharing the same object instances.  How we've implemented this is
>as follows:
>
>1. We create an accessor on the page class (or you could share a goods
>connection in a subclass of WASession)  like the following:
>
>SomeWAComponent>>goodsDb
>
>	^ goodsDb ifNil:
>		[goodsDb _ KKDatabase
>			onHost: 'dbserver'
>			port: 9000]

>
>2. Then we just use the goodsDb method wherever we need it (e.g. when
>rendering or updating our business objects on postback).   We find
>this to be the best approach overall.

Yes, I have this too.

>
>3. Also, at the top of our renderContentOn: loop we do a
>  self goodsDb refresh just to keep the objects in their most current
>state as another user may have altered the objects during the session.

Good advice!

>
>4. When commiting changes made to the business objects we do them in a
>commitWithRetry block handler (on KKConnection).

yes, I implemented this (copy from seaside example page):

MySession -> withEscapeContinuation: aBlock

   ^ (self db) commitWithRetry: [super withEscapeContinuation: aBlock]

and worked fine... but I dont really understand why :) 

What (#withEscapeContinuation: aBlock) represent?

>
>5. Lastly, we have found that it works best to collect a list of
>actions from the seaside app rather than update the objects directly. 
>Actions can be as simple as collecting up a bunch of blocks into a
>list, where if you were to run the block the result would be to update
>the business object.  Why this may seem to be unnecessary
>complication, we find that it allows us to correctly handle conflicts
>between users in the midst of the commitWithRetry block handler I
>mentioned in #4 above.  I can provide a more detailed example of this
>if you are interested.

Yes, please, It would be nice to have.

>
>Maybe Avi has a better strategy for "replaying" the changes on
>postback to the business objects in a GOODS setting if there where
>commit conflicts.  Our "list of actions" approach is pretty easy to
>implement and simple, but there might be a built-in approach that I
>haven't seen.
>

Best Regards, Leo

>Regards,
>
>John
>
>
>
>On Tue, 7 Dec 2004 15:42:54 -0300, Leo De Marco <leo at smalltalking.net> wrote:
>> Hi everyone!
>> 
>> I was working with my application using seaside, leaving the persistence problem like the last thing to do...
>> So, now is the moment to worried about that. Till now, I have access to my model using a singleton where I have all my collections (Company current). I need to access to the singleton from my seaside "pages" and from the model too.
>> When I decided to use GOODS, I put my singleton like the root, so when I need to access from de session of seaside:
>> 
>> ^self db root
>> 
>> My problem is with the access from the model... I was thinking about the possibility to access through another connection in the model, but I dont know is the best thing to do....
>> Any ideas??
>> 
>> pd: I dont need performance :)
>> 
>> Best regards,
>> 
>> Leo De Marco
>> leo at smalltalking.net
>> 2004-12-07
>> 
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/seaside
>> 
>
>
>-- 
>If at first the idea is not absurd, then there is no hope for it. --
>Albert Einstein

= = = = = = = = = = = = = = = = = = = =
			
Leo De Marco
leo at smalltalking.net
2004-12-07