Re: EOEditingContext conceptual question
Re: EOEditingContext conceptual question
- Subject: Re: EOEditingContext conceptual question
- From: Mike Schrag <email@hidden>
- Date: Sun, 11 Sep 2005 18:14:45 -0400
I'm assuming that the list is generated by an EOFetchSpecification
against the SMTicket entity. EOFetchSpecs don't return uncommitted
instances of entities (even when using the EOEditingContext that you
inserted into). That's most likely the cause of the behavior you're
seeing. Once you saveChanges, the in-memory SMTicket becomes a
committed in-database SMTicket and will then be returned by your
EOFetchSpec. This can be deceptive if you don't expect it ...
Incidentally, the pattern you're using of createAndInsert'ing in the
constructor of your AddTicket with the defaultEditingContext is
probably going to cause you problems with the use-case where someone
hits the AddTicket form and then navigates away. You then have an
empty SMTicket in your session editingcontext. The next saveChanges
executed on that editingcontext (regardless of what you are doing it
for) will then attempt to commit the empty SMTicket EO. A better
approach is to either a) create a child or peer editing context and
insert into that -- which when someone navigates away will cause the
EC to get garbage collected, cleaning up your half-created SMTicket
-- in add() you would saveChanges() on your new EC (and if it's a
child then saveChanges() on the parent EC) -- note this way requires
you to consider locking -- see Chuck's book, the archives of this
list, or Project Wonder for options; b) bind your variables to an
NSMutableDictionary instead the EO itself and then createAndInsert an
EO with the contents of that dictionary in the add() method; or c)
variation on the dictionary -- have a component with copies of the
fields of the SMTicket and bind to those, and then fill in the EO in
add().
ms
On Sep 11, 2005, at 6:01 PM, Miguel Arroz wrote:
Hi!
I'm learning WO by building a small application to handle problem-
reporting ticket submission and management.
I have read the WO Enterprise Objects Programming Guide from
Apple, and understand that, unless I explicitly create new editing
contexts, I'm always working with the same one. So, I have a
question that is not put often, but here goes... why is my
application working fine? :) I think it shouldn't! Let me explain.
Imagine I have three pages (or components) on my App, main,
ManageOpenTickets and AddTicket. Suppose main is just a menu, with
an hyperlink that links to ManageOpenTickets. ManageOpenTickets
shows a table (based on an WORepetition) with all the tickets, and
contains an hyperlink to AddTicket, which allows me to fill in a
new ticket.
Now, what I do on AddTicket is the following. I create a new
ticket on the class constructor, and the page has fields binded to
the ticket keys (like "Subject", "Description", etc). Here's the code:
protected SMTicket newTicket;
public AddTicket(WOContext context) throws Exception {
super(context);
newTicket = (SMTicket) EOUtilities.createAndInsertInstance
( session().defaultEditingContext(), "Ticket" );
}
So, I create and insert an "empty" ticket on the editing context.
After I fill in the fields on the browser and click on the submit
button, the following action is called (forget validation for now):
public WOComponent add()
{
session().defaultEditingContext().saveChanges();
return pageWithName("ManageOpenTickets");
}
So far, so good (I guess, but I'm a newbie, so if this is bad
practice, please tell me!).
The problem starts here... I thought "Well, is the component
inserts the new instance on the context on the constructor, than
that instance existis after the page has been displayed on the
browser."
So, i browsed to the ManageOpenTickets component, and opened a
new tab with the context of the hyperlink "Add Ticket", so that I
could mantain two "windows" to the same session. I thought "if I
hit the reload button on the first tab (the one that shows the
tickets table), the new empty ticked I just created should display
on the table, because every component gets the same editing
context". Well, I reload and the ticket does NOT show up (unless,
of course, i submit the form and the changes are saved)!
Of course, this is the normal behaviour, and the good one. My
question is... shouldn't this break? Shouldn't the new ticket show
up in the table? If the editing context is a kind of cache of the
DB, and every component is reading from it (because it's the
default editing context), shouldn't the empty ticket be read as
well when I reload?
Yours
Miguel Arroz
"I felt like putting a bullet between
the eyes of every Panda that wouldn't
scr*w to save its species." -- Fight Club
Miguel Arroz
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.com
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