[Seaside] Smalltalk design advice -howtoimplement genericbi-directional pointers?

[Ramon Leon]

> insights, it's probably not the way to go. Still, it sounds 
> like Tsunami is a great technical achievement and could be 
> used in other ways in the future. 

I wouldn't call it a great technical achievement, but it was fun, and it
proved the value of unit testing to me.  I was failing miserably until I
switched to a test first style.  I think going overboard hacking
#doesNotUnderstand is a Smalltalk right of passage.  It's something you have
to do so you know when not to do it, it's very tempting to go crazy with it.

> As an aside, you might want 
> to copy some of your previous reply and paste it into the 
> general description of Tsunami on SqueakSource so that the 
> casual passer-by can weigh the pros and cons of the technique.

Not a bad idea, I'll do that.

> I get it. You separate the concerns of "testing" and 
> "setting" into methods that can be overridden. You also don't 
> want to allow the general "setter" to save invalid data, so 
> you construct it in a clever way to call the other two 
> methods. Even though this all makes sense, it begs a 
> question... "Maybe data validation happens too soon?"

One of the premises of the book is to never allow invalid data into the
object.

> Imagine "name" was bound up to a text field on an HTML web 
> form. Let's say that the testing code required the first 
>
> snip...
>
> I would offer a slight variation. I would write your snippet like so:
>
> snip...
>
> The idea here is that "name" will always get set, regardless 
> of what is typed, but it might not be saved to your 
> persistence layer (object database - Magma, or relational 
> database - GLORP). When you type in "rosenzweig" and hit 
> "submit", one of the following could occur:
> 
> -- Aaron

You're assuming that I'd bind a business object directly to a form for
editing and wouldn't commit it unless it was valid, however, there's a flaw
in this technique, it allows the business object to be in an invalid state
which makes the further assumption that I'm required to commit to a
persistent store.  

Such is not always the case, especially when prototyping or writing small
apps that won't have more than 5-10 users. I use the image itself as the
persistence layer which means any changes made to the object *is* a commit
and is immediately available to other users.  I don't want biz objects in an
invalid state visible to others.  

When I edit objects, I bind a memento from the object to the form, and edit
the memento.  Only when the memento passes all necessary rules (which you
can test via the testX methods and gathering exceptions) would I allow the
memento to update the actual business object (took this technique from
Magritte, first time I'd seen a memento used this way).

Ramon Leon
http://onsmalltalk.com