Hi Joachim, Thank you for your feedback.
It feels good to know we're not alone in this :-) 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. At the same time, we haven't found the pot of gold at the end of the rainbow yet ;-) 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. 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. 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> 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 > > > On 8 Oct 2019, 15:41 +0200, James Foster <smallt...@jgfoster.net>, wrote: > > > > > > > > > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren > > > > > <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 > >
