• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOEditingContext conceptual question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: EOEditingContext conceptual question
      • From: Miguel Arroz <email@hidden>
References: 
 >EOEditingContext conceptual question (From: Miguel Arroz <email@hidden>)

  • Prev by Date: EOEditingContext conceptual question
  • Next by Date: Re: EOEditingContext conceptual question
  • Previous by thread: EOEditingContext conceptual question
  • Next by thread: Re: EOEditingContext conceptual question
  • Index(es):
    • Date
    • Thread