Jonathan,
I was a bit destracted by work this week, so I am a little late to the
show...
Am 10.10.19 um 12:26 schrieb Jonathan van Alteren:
Hi Joachim,
Thank you for your feedback.
It feels good to know we're not alone in this :-)
Well, I guess there are far more people in this boat than actually know
they are ;-)
Unfortunately, the things you describe are familiar to me. My business
partner Dave West has a lot of experience with applying a behavioral,
'pure' object design approach. We're looking hard into simplifying
these matters through the application of inversion of control and by
making objects as autonomous as they can possible be.
sigh, This is really, really hard. You'd need a guard in the background
that autonomously register all objects that get
visited/accessed/modified during an operation and create a memento just
before this actually happens. Ideally, this would only happen if the
upcoming operation on that objects modifies its state once the operation
happens. Or ot would have to clean up non-modified ones after the
operation finished. I guess this second alternative is even feasible
using slots and such, but there remain a few questions about
synchronizing all this and the underlying database transactions...
At the same time, we haven't found the pot of gold at the end of the
rainbow yet ;-)
You know, sometimes I fear it is better not to have anybody come back
from that end of the rainbow. They might have found out there is no pot
or anything similar to one ;-)
Nowadays, a fair amount of applications have a very direct way of
handling user interactions and resulting state changes. For example,
the settings of my Firefox browser doesn't have a save button anymore.
Anything I change looks to be automatically persisted. Perhaps there
is some value in that approach for 'enterprise' applications as well,
although I think there will remain a lot of use cases where an
explicit save will be needed for whatever reason.
Hmm. I am afraid there is a certain distance between changes that only
affect a single setting value and more complex values that imply a lot
of recomputation of values in a more complex model. Sometimes you also
need to modify or at least check consequences of changes that don't fit
onto a single screen, and there you need to find ways to allow a user to
step back from what they just started to do...
Let's keep talking about this. I need to do some research on the
memento pattern first :-) If you have any information sources you can
point me to, I would greatly appreciate that.
I don't follow any interesting research on mementos. Too much work to do
for that. The memento pattern itself is just "make a copy that the user
can play with without any consequences to the original object". Works
perfect for a single object or a well-defined object graph. But I am not
aware of any working solutions that would solve our problems for more
complex graphs, or even a general one... If you find something, let us know!
Joachim
Kind regards,
Jonathan van Alteren
Founding Member | Object Guild
jvalte...@objectguild.com
On 9 Oct 2019, 16:49 +0200, jtuc...@objektfabrik.de
<jtuc...@objektfabrik.de>, wrote:
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 Tuchelmailto:jtuc...@objektfabrik.de
Fliederweg 1http://www.objektfabrik.de
D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
--
-----------------------------------------------------------------------
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
