View update complexitiesView update complexities admin 23 September, 2009 - 22:01
On a page where there are lots of views but all from the same entity there is an interesting challenge when an individual item is updated within a view. Normally this is catered for during a full postback simply because the entire page is recreated dynamically, so it is enough that the post is processed during the construct phase.
However this isn't true when we are using an ajax update to modify an item.
So what we need to happen is when any item within a view is updated all views that reference the item should also be updated. There was an immediate and elegant solution using one of my current favourite techniques which is to effectively label elements within the DOM by adding a class to them. The all that had to be done was to return a simply text value representing the new value of the item.
Except that it completely broke most of the rules of good development, and whilst it worked for a simple case it didn't work for anything more complex.
So, what is needed is something that will allow all entity items to have their inner html updated using the same objects that originally generated them.
This is further complicated because, of course, there isn't a coherent list of the views that are currently used, and no cross reference between them, and furthermore I really don't want to add this as each view should be as independent as possible. Within the PHP I can send out a message via the global post office which could be received by the views, except that doesn't necessarily help to get the data onto the web page, and global messages aren't really the right solution in this case (because of the way that the objects are constructed and updated processed in the constructor).
I don't want to change the way that the objects are constructed; there's still a large post-it on top of the monitor that reads ZXAF - NO COMPROMISES.
There are two distinct parts to the solution, the first being obvious in that the ajax should return JSON containing all of the identified DOM elements that need to have the HTML replaced by that provided.
The second part of the solution was very difficult to get right, and I hope it's right. Initial impressions look good, but it's new and hasn't been onto the battlefield yet (whereas most of the original code came complete with years of battle scars).
The solution to the PHP update problem was a large rework of the way that DOM elements were named to make them consistent and identifiable. Then to change the naming of the form elements to be based on their entity item name. This was the difficult bit to figure out, and I think it's right. The logic is as follows:
Where a form references an entity any updates to any part of that entity are relevant to all forms that reference the same entity, so any form that uses the same entity is equally capable of updating the entity. As the update logic in entities is smart, such that only changes are written to the backing store.
What that means is basically that it doesn't matter which view prompted the update, any view can process it, and will process it, because by processing it we can get the HTML for the update that is required, and build this into a JSON update message.
The actual building of the JSON update is performed by the WebPage object, via messages.
So, changes made, and with a few small faults that were easily fixed, it all works fine.
I can have an entity on a view, update it from that view, and all the items on the web page that reference it will be updated.
At the same time I also implemented the ability to cause this update mechanism to support linked entity items, such as an href, where the text and the target are usually two fields. It looks promising that the design is good because this change only took about 5 lines of code, and I was expecting a lot more.