Re: Best Practice on Uncommitted Changes in EC
Re: Best Practice on Uncommitted Changes in EC
- Subject: Re: Best Practice on Uncommitted Changes in EC
- From: James Cicenia <email@hidden>
- Date: Fri, 8 Apr 2005 15:27:16 -0500
Well - I saw this issue early on as being a problem so we made the
command decision to use a popup for the majority of our edits and
inserts. This way you can just create a new ec for that popup and not
care if they close it, or save or cancel it. This practice has worked
well for us.
- James Cicenia
On Apr 8, 2005, at 12:26 PM, Kieran Kelleher wrote:
I would appreciate some advice on best practices.
As a user works in the application viewing, editing, creating and
deleting entities, I have been implementing the following pattern of
behaviour:
Creating and Editing: a new editing context is created and the new
entity or localInstance of existing are put in the new EC and a new
page with form for editing that entity is shown. Usually the edit page
has a breadcrumb trail showing higher level related entities. For
example:
Customer_Name > Location_Name > Advertizing_Program_Name > Geography
or
Customer_Name > Account > Transaction Detail
with all breadcrumbs except the last being a WOHyperLink to an action
that goes to a page view of one of those entities.
Now the best practice question is how to handle someone clicking one
of the breadcrumb links to go to a related object which in effect is
avoiding the submit/save of the edited or new entity.
Let's say I am in edit mode on a new/editing Account transaction and
the user decides to click on Account (to go to a list of account
transactions and forget saving the new or edited Transaction), what I
am currently doing is:
1) Get a reference to the entity (Account)
2) Make another new EC and make a local instance of the Account entity
3) Call revert on the new EC to eliminate any unsaved changes on the
local instance (such as relationships between Account and the
Transaction if it was a new transaction)
4) Push the Account reference into the new page and go to that page.
Is this all a bit "heavy handed" or is there a better standard
practice to prevent a dreaded failure of a later save due to an
"invalid/incomplete" entity lying around??
Is it OK to be creating new EC's (letting the wonderful
MultiECLockManager manage them) every time the user goes to an edit
page and leaves that edit page without committing changes?
Regards, Kieran
________________________________________________________________
Blog: http://webobjects.webhop.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden