This is a tricky mine field. Sometimes you need a lot of business
functionality in objects referenced in your objects that are currently
in the editor. So I'm still to see a project in which the memento
pattern really worked for more complex scenarios. How deep do you dive
to have enough memento objects to provide the functionality needed. I
guess you can do that with some sort of object-level transaction
framework that automatically creates mementos of whatever object is
being navigated to during some kind of processing-context. I guess slots
could be of use here. But this is not trivial for general cases.
In my experience, this problem area makes for the other 70% of the time
spent on developing GUI or Web applications, besides the 60% for GUI
design and implementation and 25% business logic...
I'd be interested to learn about patterns to handle such more complex
things. We constantly travel back and forth between implementing stuff
in the GUI handlers (copying values to the GUI classes that access
themselves during GUI operations and push values to the business objects
when the users clicks on OK), using mementos (which most of the times
are nets of mementos that are created manually - "we know what we'll
touch in this Editor") and operating on business objects directly and
relying on the persistence mechanism (Glorp in our case) and its
rollback behaviour. All three have lots of weaknesses and seem to have
their place nevertheless.
So this is a very interesting discussion and I think this is an area
that has not been solved yet.
Joachim
Am 09.10.19 um 16:25 schrieb James Foster:
Thanks for the explanation. And, yes, this is an artifact of your
design; if you put intermediate values into domain objects then they
will remain in your domain objects to be seen later. From what you’ve
described, I don’t see how it would be any different in a non-image
environment (Java, C#, etc.), unless you re-read the entire object
graph from the database. As someone else mentioned, this would be a
good place for the Memento Pattern.
James
On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren
<jvalte...@objectguild.com <mailto:jvalte...@objectguild.com>> wrote:
Hi James,
I see how my explanation might be unclear.
We have a main form for the agenda and a subform for an item, which
is shown using Seaside call/answer. The save button of the subform is
clicked, which adds the item to the underlying agenda model object,
but the save button of the main form _is not_ clicked by the user.
The callback for the main save button sends the save message to the
agenda object, causing the database to be updated.
So yes, the browser does submit the data on the subform, it's the
main form component that doesn't receive the save button callback. I
realize that this is in large part an issue with our design. However,
the way object persistence seems to work in the image environment
plays a large role.
Kind regards,
Jonathan van Alteren
Founding Member | Object Guild
jvalte...@objectguild.com <mailto:jvalte...@objectguild.com>
On 8 Oct 2019, 15:41 +0200, James Foster <smallt...@jgfoster.net
<mailto:smallt...@jgfoster.net>>, wrote:
On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren
<jvalte...@objectguild.com <mailto:jvalte...@objectguild.com>> wrote:
We've encountered an issue where a user makes changes to an agenda,
but does not click the Save button. Instead, the user closes the
browser or uses the navigation to go to a different part of the
application. When navigating back to the original agenda, the
changes made previously (e.g. items added) are still being
displayed, even though they were never explicitly saved.
Here is what I don’t understand: how did the change get from the
user’s client agent (browser) to the server? If you make a change to
a field in a form and then close the browser, who sent the change to
the server? If you show the save domain value in a different
location, with a dynamically-generated id and name (so it isn’t
cached in the browser), or written to the Pharo Transcript, does the
value still change? That is, are you sure that the change is in the
reflected in the Smalltalk image and not just somehow cached in the
browser?
James
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
