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: Sacha Mallais <email@hidden>
- Date: Fri, 8 Apr 2005 11:01:23 -0700
On Apr 8, 2005, at 10:26 am, 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 there any reason you are avoiding calling revert() on the old EC?
I don't think it's "heavy handed": creating a new EC on every page
isn't excessive.
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?
Sure, why not? It often makes more sense to create a new EC instead of
reusing an old one.
sacha
--
Sacha Michel Mallais - 400 lb. chimp
Global Village Consulting Inc.: http://www.global-village.net/
1. Never tell everything at once.
-- Ken Venturi, Ken Venturi's Two Great Rules of Life
_______________________________________________
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