[Seaside] How to add GLORP to a Seaside application?

[Brett Taylor]

I use an Editing Copy mechanism also (though not as sophisticated as Rado's).  I've found it to be very manageable.  I put the responsibilty of producing the copy on the editor. That way if the particular editor knows that it only works with a limited portion of the object, it can overide the method, and copy only the part of the object graph that matters. All access by the Editor is through the editing copy.  All changes to the editing copy are replicated to the model object.
Here is my method in my class EditingCopyDialog (subclass of WALabelledFormDialog)

EditingCopyDialog>>updateModelWithEditingCopy
	self session dbSession transact:
			[:dbsess |
			self registerModelAndRelatedObjectsIn: dbsess.
			self copyFromEditingCopyToModel]


This method is called by the save method.I have a default implementation of copyFromEditingCopyToModel that transverses the object graph, but I overide it in certain cases.  Also, my domain model object implement postCopy to make sure that that deep copies are correctly performed.  This is in VisualWorks so I'm not sure about the copying semantics in Squeak.


Brett
On Tue, 1 Feb 2005 17:36:08 +0100 (CET), radoslav hodnicak <rh at 4096.sk> wrote:

> On Tue, 1 Feb 2005, Martin J.Laubach wrote:
>
>>    I'm afraid I painted myself in yet another corner with GLORP and
>> Seaside.
>>
>>    The problem is that glorp does not support nesting of UnitOfWorks.
>> That, together with the highly dynamic behaviour of Seaside
>> applications,
>> leads to my losing much hair...
>
> Well yeah, you will lose much hair. Did you expect things to be easy?
>
> Anyhow, after a year of trying various ways to deal with the issue of
> nested editors I'm currently using glorp's descriptor to create deep
> copies of the edited object (only fields mapped by glorp get copied) and
> then only in the case when I want to save the changes to db I do something
> like
>
> begin unit of work
> register original object
> replay changes from the copy to the original
> commit unit of work
>
> resp. there is some logic to work with a chain of deep copies so that the
> changes are only commited to db in the "topmost" editor.
>
> On cancel I don't do anything, the original is unchanged and the deep copy
> gets GCed.
>
> advantages:
> - every editor works with own set of data, the user can fork browsers and
> save/cancel data however he wants to
> - prevents partially changed and uncommited objects in the case where the
> user just hits the back button to break from a form instead of save/cancel
> button
> - all unit of work work happens in a callback so there is no problems with
> other components holding the UoW
>
> disadvantages:
> - memory hungry. deep copies of everything take a lot of space. my
> production image went from about 40MB runtime to 180MB runtime
> - very tricky to get the copying and replaying right. in fact I wansn't
> able to make it work correctly with glorp's proxies so I don't use proxies
> anymore
> - deep copies create a MESS when it comes to object identity (one of the
> main points in glorp)
>
>
> So... on one side I'm glad to have it, because it (mostly) works and I
> don't have anything better. On other side, I'm unhappy about it because
> it's ugly and I don't have anything better.
>
> rado
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>
>