• 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: sorting output
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sorting output


  • Subject: Re: sorting output
  • From: Nathan Dumar <email@hidden>
  • Date: Sat, 21 Aug 2004 23:13:53 -0400

Thanks, Dirk.

The request-response loop has been a weakness of mine -- I didn't even think of the appendToResponse override. I should brush up on that.

Another thing I didn't think of -- putting a fetch into the EO class, to get related objects as needed. Genius. That's going into the first revision of my app. That would have saved me a lot of work, and would make my app a bit faster in a particularly sluggish component. I wish I had thought of that, back when I wrote that part.

Take care,
Nathan

On Aug 20, 2004, at 9:56 PM, Dirk Bajohr wrote:

Good job, Nathan. Just for completeness:

If you override WOComponent.appendToResponse(...) and add your code it will be executed every time the page is (re-)generated.

Don't forget to call super.appendToResponse(...) at the end of appendToResponse. Read the apple docs or one of the excellent WO books about the request-response-loop!

And there's one more thing... the design of your code could be improved: move the fetch into a method of your Author class. Try to separate the model from the view. You have to be careful if you're using EOModeler and generate the sources for Author. All changes that you make will be overwritten if you re-create the Author class - use the FileMerge tool to apply the model changes.

Cheers,
Dirk


Am 20.08.2004 um 18:26 schrieb Nathan Dumar:

Okay, I understand better now. I'll explain amid parts of your code below ...


    public Main(WOContext context) {
        super(context);

In here, code is executed once when the page is first loaded. If your actions return null (when you make a new action in WOBuilder, instead of selecting the page to follow, you select null), then this page will be returned, but this code will not be executed again. It will just pull the page from the page cache and return it to you. However, if, when you create a new action, you select this page from the list (instead of null), it will return a new object representing this page, and the code here will be executed again. (At least, I'm pretty sure, but not completely sure.)


Somebody correct me if I'm wrong (good possibility), but I *think* that returning the page instead of returning null increases memory requirements (which you probably don't have to worry about yet). Returning null just gives what's already in memory.

		// Sort ascending lastName ignoring case.
		lastNameSort = new EOSortOrdering("lastName",
EOSortOrdering.CompareCaseInsensitiveAscending);

		// Sort ascending by firstName ignoring case.
		firstNameSort = new EOSortOrdering("firstName",
EOSortOrdering.CompareCaseInsensitiveAscending);

		// Create an array with the two sort orderings.
		sortOrderings = new NSMutableArray();

sortOrderings.addObject(lastNameSort);
sortOrderings.addObject(firstNameSort);

// Create the fetch specification.
fetchSpec = new EOFetchSpecification("Author", null, sortOrderings);

Good job on the fetch spec. Also check out the EOUtilities class for some shortcuts in the most commonly performed fetches.


// Get the editing context.
editingContext = session().defaultEditingContext();

// Fetch authors.
authorList = new
NSMutableArray(editingContext.objectsWithFetchSpecification(fetchSpec ));

As I mentioned, this fetch is done when the page first loads. Your fetch spec tells the database to sort the objects before it returns them, so it's the database, not WO, that is doing the sorting. Since this code is not re-executed, the sort happens only at the beginning, and not again until a new Main page object is created.


WebObjects keeps a copy of recently used objects in memory, so that it can manipulate these instead of going back to the database, which takes much longer. When you instruct it to do so, it will save all the changes to all the objects, all at the same time, minimizing the performance hit by doing everything all in the same trip.

If you want to return null from the action (the action that is bound to the submit button of the form), but you still want to make WO fetch from the database again, you can do a couple different things. You can put the fetch within the method that is attached to the submit button (forcing WO to go back to the database and get all the objects again), or you can do an EOSortOrdering, which will re-sort the objects that it has in memory, so they appear in the right order again.

		// Get the Author class description from the Author Entity.
		authorClassDescription =
EOClassDescription.classDescriptionForEntityName("Author");

		// Create an Author object (where form data is stored).
		author = new EOGenericRecord(authorClassDescription);
    }


When is the main section run? Only at the beginning of the running web app?

Yes, but if you have methods within it, and you call those methods, they will run when called.


Would I have to set the fetchSpec in the "Add" method to get the
sorted list each time?

That depends. If the Add method does a saveChanges(), and you put the fetch AFTER the save, then yes.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >sorting output (From: Wes James <email@hidden>)
 >Re: sorting output (From: Nathan Dumar <email@hidden>)
 >Re: sorting output (From: Wes James <email@hidden>)
 >Re: sorting output (From: Nathan Dumar <email@hidden>)
 >Re: sorting output (From: Dirk Bajohr <email@hidden>)

  • Prev by Date: Re: Just once more, an EOF/ObjC replacement?
  • Next by Date: inter-instance communication
  • Previous by thread: Re: sorting output
  • Next by thread: RE: sorting output
  • Index(es):
    • Date
    • Thread