On 3/21/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > everytime the meta data tab is requested, a continuation is created. > Even if you modify and save the meta data, another continuation is > created, because the screen is displayed again. This behaviour > unnecessarily increases memory consumption. > > I see two options to avoid the problem: > 1. Don't create continuations > 2. Separate "modify meta-data" usecase > > The major problem with approach 1. is that it doesn't detect read-write > conflicts - with concurrent modification, the second commit overrides > the changes of the first one. This is especially problematic with our > current approach: All meta data values are saved, not only the modified > ones. > > Approach 2. requires additional clicks, but I think we could live with that. > > How about this approach: The meta data screen has no submit button by > default, but next to each (editable) field is an "Edit" button. When you > click it, an optimistic usecase is started, which only manipulates this > single field. The "Edit" button changes to "Save". The changes are sent > to the server using an asynchronous request. If you're familiar with > Flickr - I imagine it to work like editing photo titles. > > WDYT? > -- Andreas
My vote would be for #1 because I have psychoses about locking systems and limited-duration server-based data storage. If using #2, do not add clicks. AJAX needs neither the submit button nor "edit" links. Just use onChange() and similar events to trigger the sendInformation(). Even a monitor thread checking every 5 seconds to test for changed fields is better than adding clicks. (I also have a psychosis about creating listener threads for trigger events.) solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
