PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: tjiddy on April 22, 2008, 10:11:08



Title: normalizing remoteObjects
Post by: tjiddy on April 22, 2008, 10:11:08
this isnt 100% puremvc related, but I was wondering how people here handled this.


1) load a list of Authors and store them in authorList:ArrayCollection
2) Load a list of Books and store them in books:ArrayCollection

now, lets assume a book object is composed of an author object.
The author objects that the books refer to, are different instances than the authors in authorList.  The reasoning makes sense, the framework has no idea it has received that Author object before via a completely different proxy, so it just creates a new one. This breaks when a user modifies an author via a book, then goes to look at the list of authors, only to find their changes weren't applied to that list!

I am currently registering the RECEIVED_BOOK_LIST notification to a command class (NormalizeAuthorsCommand) that loops through the list it just received, finds the correct Author object from the authorList, and replaces the reference in the Book.  Once this is done, the command fires off a LOAD_BOOK_LIST_SUCCESSFUL.  I'm building a rather large app (the author/book was just a simple example)  and am finding myself doing this all over the place.  I thought about not returning the whole author object with the book, but just the authorId.  I think this would just save network chatter as I would still need to loop through the list, find the right author, and update the reference in the Book.  I think either I am missing something or there has to be a better approach.  How are you guys handling this?

Todd


Title: Re: normalizing remoteObjects
Post by: puremvc on April 22, 2008, 10:51:51
Send the id of the author along with the book. Have a separate AuthorProxy that manages the authorList. Have a BookProxy method that gets the author for a given book by retrieving the AuthorProxy and asking for the author with the id given in the book object.

Also, try not to use Commands to maintain the integrity of your Model. They are for Business logic, not Domain logic. I'd suggest a quick read of the best practices document to clear up most questions about where stuff goes :)

-=Cliff>


Title: Re: normalizing remoteObjects
Post by: tjiddy on April 22, 2008, 12:14:04
... and that's why you make the big bucks.

I think I went with the command route because I thought proxys were not allowed to use other proxys.  (I think i came to that conclusion by looking at the conceptual diagram).

I already have the getAuthorById method on my authorProxy so the refactor will be easy.  I'll read the best practices doc again seeing as how 90% of my commands are model integrity related.

I knew you would have a simple, elegant solution.
Thanks a bunch.


Title: Re: normalizing remoteObjects
Post by: JJfutbol on July 08, 2008, 11:01:11
I have some questions on this approach though. Say you wanted in a View component to display in a List with a custom item renderer all books with their creation date, the author name, etc.

How would you go about getting the author name (or any related author data) for that type of view?

I get lost in that part because if you have a BookVO but it only has an authorId property rather than a complex property called author (being an AuthorVO) what do you do?

Do you create a new arrayCollection in the mediator for that view? But you can't add BookVO's since you need the author data. Curious to hear your thoughts as I've struggled a lot with this. Again, thanks for all the great comments!


Title: Re: normalizing remoteObjects
Post by: creynders on July 09, 2008, 12:24:57
I've used two possible solutions for this situation (I have no idea whether these are the best solutions, though...)
1. Create a mediator for each itemrenderer and let the mediator communicate with the authors proxy to look up the author name, using the author id
2. let the item renderer send a dataChange event to the view's mediator, which in turn does the same as in 1.

Whether I choose 1 or 2 depends on the complexity of the itemrenderer. If it needs to get data from various proxies and performs all kinds of difficult logic, I'll choose 1. It's a more convoluted solution since you'll need to create the extra mediator-class and most probably a factory class as well.