...
In practice this does not pose a very big problem because most of the time it is important to handle entity changes inside pages in a different way anyway.
SubPages
So far we have talked about DomUI pages. These are classes derived from UrlPage which are uniquely identified by an URL containing a class name and a set of parameters. Changing to another Page means changing the URL, and causing a Browser page change. A DomUI Page, once rendered, is fully AJAX, but changing pages is not AJAX but is closer to a traditional HTML page. This was a good match for the first application DomUI was written for.
Modern applications try to be fully AJAX: they load the main page once, and from then on all changes are made to that page with AJAX calls. They never reload the entire page. While it is possible to make this with DomUI 1.x it is hard because having everything in a single Page means that state management difficult because everything uses the same Conversation (and thus the same QDataContext).
DomUI 2.0 has a new concept called SubPages which aims to fix this. This are part of the SPI (Single Page Interface) implementation for DomUI.
| Warning |
|---|
This is preliminary info; the implementation can still change quite a bit. |
...
A SubPage is a class that extends the class SubPage instead of UrlPage. A SubPage is a DomUI fragment represented as a Div which can be added anywhere in the DomUI DOM. A SubPage is always part of an UrlPage - but an UrlPage can contain multiple SubPage's if so desired.
A SubPage must to be added to an UrlPage, but you can just create a single UrlPage and from then on just replace SubPage's inside that page to create the parts of the UI that are desired.
SubPages also implement state management which is similar to the state management that is done by UrlPages. Like an UrlPage a SubPage has a ConversationContext (called SubConversationContext). These ConversationContexts are children of the main ConversationContext that is attached to the UrlPage.
Like UrlPages subpages are created and destroyed, and this causes their SubConversationContext to be destroyed too. And with that all resources belonging to it are released. In addition all SubConversations will become attached and detached when the Conversation they belong to becomes attached or detached: all SubConversations closely mirror the root conversation state.
A SubPage and its SubConversation are created as soon as an instance of it is added to an UrlPage, either directly or because it is part of some subtree that gets added to a page. As soon as the thing gets added a new SubConversation gets allocated, registered with the UrlPage's Conversation and made Attached.
Calls to getDataContext() on nodes that belong to a SubPage will get their data context from the SubConversation belonging to the closest SubPage parent (remember that SubPages can be nested too!). This means that a SubPage has its own database connection and session. In this way the SubPage acts as a "fence" between different connections and objects.
A SubPage gets destroyed when it is removed from a page. The destruction is not immediate but done when the request finishes. This allows you to temporarily disconnect a SubPage and reconnect it somewhere else within the same request.
Entity (data) objects in SubPages
The normal way for creating SubPages is to have some class with a constructor, passing the data objects into the constructor. This is completely different from UrlPage's: these get their objects from "outside", and because of this these objects are always part of the QDataContext (session) of that UrlPage.
But when you create a SubPage and pass Entity objects in the Constructor those objects belong to the QDataContext of the parent of the SubPage. But the SubPage has its own QDataContext, and using the object as-is would cause trouble as all changes to the object would be done in the parent database context, not in the context inside the SubPage.
DomUI tries to fix this as follows: as soon as your SubPage is added to the page DomUI will scan the SubPage class for (private) fields and getters. All fields and getters that contain an object which is determined to be an Entity object (as detected by MetaManager.findClassInfo) will need to be re-injected in the SubPage. Re-injecting means: a new instance for the object is loaded from the QDataContext that is part of the SubPage. This will always be a new instance. The new instance is then put back into the field or the property. This should mean that all references to those objects now refer to the copy in the SubPage, not to the original.
...
What else: SubPages..
This all talked about UrlPages. In DomUI 2.0 we also have SubPages, and they work differently.