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

[Todd Blanchard]

I find that Seaside/Glorp interaction is an awful lot like 
WebObjects/EOF.
EOF has a slight advantage in that you *can* have nested editing 
contexts (where an editing context is roughly equivalent to glorp 
session).

Even so, I've found that its often a mistake to bind aspects of my 
model directly to UI elements unless they are display-only.

For instance, borrowing an example from the mewa example, allowing the 
user to create a new phone number, I would have a panel for phone 
number creation that had ivars for each of the fields to be entered 
into the phone number object.  Its only in the submit callback that I 
would actually start the unitOfWork, create and add a new phone number 
object, fill in its fields, and commit it.

Otherwise, as you've noted, your UI navigation has a significant (and 
frequently undesireable) impact on your transaction boundaries.


On Jan 31, 2005, at 5:03 PM, 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...
>
>
>   Consider for example a navigation bar with two links, each leading to
> an editing pane for some database object. On each I have something like
>
> 	MyEditingPane>>renderContentOn: html
> 		session beginUnitOfWork.
> 		(self confirm: 'Do you want to save that?')
> 			ifTrue: [ s commitUnitOfWork ]
> 			ifFalse: [ s rollbackUnitOfWork ]
>
>
>   Now when the user changes to the other editor pane while the 
> #confirm:
> is displayed, *boom*, glorp throws an exception. The only way I see out
> of that is to use UnitOfWorks only when it can't be preempted by the 
> user.
> But then, don't I lose all the benefits (like in the example above, 
> being
> able to roll back easily)?
>
>   My real example is a bit more complicated, so I can't just move the
> #beginUnitOfWork after the confirm as it's doing the modifications in
> a #call'ed subcomponent and returns true/false depending on the user
> hitting a save or revert button.
>
>   Wrong approach to that problem?
>
> 	mjl
>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>