[Isomorphic]

To further help with this, here's some draft documentation from 10.0:

<h3>Stored vs Derived or Transient state</h3>
<p>
The purpose of having an <code>EditNode</code> for each UI component is to maintain a
distinction between the current state of the live UI component and the state that should
be saved. For example:
<ul>
<li> a component may have a current width of 510 pixels when viewed within a tool, but what
should persist is the configured width of 40% of available space
<li> a tool may allow end users to create a Window, and then drag components into the Window.
Every Window automatically creates subcomponents such as a header, but these should not be
persisted because they don't represent state created by the end user. Only the components
the end user actually dragged into the Window should be persisted
<li> while being edited, a component may change appearance in response to a mouse hover or
while selected, but we don't want these appearance changes permanently saved
<li> an end user may try out the effect of a property change, then abandon it and revert to the
default value. We don't want the temporary change saved, and we don't even want to save
the reversion to the default value - nothing about the saved state should be changed
</ul>
By being careful to save <i>only intentional changes made by the user</i>:
<ul>
<li> the saved state remains minimal in size, and re-creating components from the stored state
is more efficient
<li> the saved state is much easier to edit since it contains only intentional settings, and not
generated or derived information
<li> the stored state is more robust against changes over time and easier to re-use. When we
avoiding spuriously saving default values that the user has not modified, we avoid
possible conflicts when a saved UI is deployed to a new version or in a different
environment with different defaults
</ul>

The fact that your Layout creates a Canvas is *probably* analogous to the situation described above where a Window auto-creates a header, and if so, then that relationship is not something you should represent with EditNodes.

In general, you need to make a clear distinction between state that is created by the user (goes into the EditContext) vs state that the system creates automatically (not in the EditContext).

Because this is a distinction of *intent* it's very, very hard to work with highly synthetic test code, because we have no idea what's intended.

[Isomorphic]

One other note: getEditNodeTree() is not a documented API. It might be OK in some throwaway test code but you should not otherwise rely on it.

[kemendranm]

Just in case there's any doubt: I see that using setNodeProperties() is absolutely necessary and i will be using it in the prototype in due course.

But i can also see that it is not sufficient: something else is wrong, and understanding why the minimal test example is breaking, even when setNodeProperties() is being used as it is supposed to be, is the easiest way to discover what it is.

This could be a peculiarity or deficiency in the way i have used the persistence functionality, in which case i need to know what specifically is wrong about it so that i can figure out how to change the way i use it while still meeting all our project requirements.

Or it could be a bug in the persistence functionality that your existing tests and demos don't exercise, but this test example does, in which case you need to figure out what specifically is going wrong and fix it.

So, how do we converge reasonably efficiently on a resolution?

[Isomorphic]

We're guessing you posted this before seeing our response(s). Let us know if you are still confused.

[kemendranm]

Here's your duplicate canvas issue:

1. Create Layout
2. Layout creates Canvas
3. Serialize
4. Reincarnate
5. Reincarnate creates Canvas
6. Reincarnate creates Layout
7. Layout creates a new Canvas

Thus you get 2 canvases.

Note also that your Layout child canvas is added into the editContext at the same level as the Layout and therefore it will not automatically be reincarnated (your terminology) into the Layout members. To do that you will have to specify a parent to your addNode but that's not possible within initWidget because the editNode is not yet created at that point for the layout.

So there are a few issues to be worked out with the test cases before dealing with the visible property.

Informative. Thank you.

In the larger prototype i'm building, the top level structure is in fact a Layout, but it contains three children (one PortalLayout, one custom nested Layout structure, and one simple HLayout), which the user can trigger to be shown and hidden in certain ways. These layouts in turn contains Portlets and Canvases that the user can rearrange in a variety of ways.

So, the Canvas in my posted example actually represents something that has complex user modifiable internal structure that needs to be persisted. I put the construction of the Canvas in the initWidget of the Layout because i intend the Canvas to be created automatically when the Layout is created, and to be a member of the Layout. But at the same time, it is something whose internal structure and state would need to be recreated when the parent Layout creates it.

You seem to be suggesting that the Canvas shouldn't be created in the initWidget of the Layout, but is there any other way that it can it be something whose creation gets automatically triggered when the Layout gets created (as opposed to being something that needs to get created separately)?

Do you see any way to restructure the code to meet all these requirements?

[Isomorphic]

Returning to the analogy of the Window, from the draft docs we just posted: think of the Window.body. It *contains* things that the user might have put in there, but the body itself is always auto-created, and its existence does not depend on the user doing something.

If your Canvas is intended to be like the Window.body, it should not have an editNode and should always be created automatically.

If your Canvas is intended to be like the Window.items that are created inside the Window.body, it should have an EditNode, and should not be created unless the end user takes some action, therefore it would not be created in initWidget.

[kemendranm]

The fact that your Layout creates a Canvas is *probably* analogous to the situation described above where a Window auto-creates a header, and if so, then that relationship is not something you should represent with EditNodes.

In general, you need to make a clear distinction between state that is created by the user (goes into the EditContext) vs state that the system creates automatically (not in the EditContext).

Because this is a distinction of *intent* it's very, very hard to work with highly synthetic test code, because we have no idea what's intended.

As i mentioned in my last response, the Canvas actually represents something complex with intentionally user modifiable state in it, including but not limited to its visibility. I also intended the showCanvas() and hideCanvas() methods to represent user-triggerable actions.

[Isomorphic]

Great, so:

If your Canvas is intended to be like the Window.items that are created inside the Window.body, it should have an EditNode, and should not be created unless the end user takes some action, therefore it would not be created in initWidget.

[kemendranm]

Thank you all for your attention today.

I think the next step should be for me to post a standalone version of the prototype i'm working on, so we can get more clearly to grips with which pieces should and shouldn't be EditNodes and why or why not.

I hope to be able to post that sometime tomorrow morning your time.

I'm going to bed now... :)

[Isomorphic]

That may not be the right next step..

Support is here to answer how-to questions and identify and address any possible product defects.

It seems like your need is more along the lines "please examine my application code, analyze my requirements, and tell me how to re-structure it". We're not equipped to handle that kind of need under Support - among other problems, that's a long-running discussion with possible web conferences needed, and lots of context to maintain about your requirements, and Support is handed on a round-robin basis, and intended to be episodic.

Our Consulting services are better suited to that kind of long-running, high context service need.

[kemendranm]

Is it possible for me to get access to a live working draft of the documentation you quoted from in this thread *before* it is officially released with 10.0? It is much more valuable for me to have access to incomplete, imperfect documentation than to be hampered in progressing with my task while waiting for the polished version to be released with 10.0. In fact, if you could connect me with the author, we could even collaborate to improve it before it goes live with 10.0.

[Isomorphic]

Basically as soon as any given piece of documentation is complete enough, it immediately appears in the latest builds (specifically, 10.0d builds available from smartclient.com/builds).

As far as that particular draft, note that it's just a slightly redacted version of docs you already have in 9.1, so it's not as though there's a problem with "incomplete" docs that is being addressed by a new draft. The docs in this area are getting attention because there are a lot of new features to cover in 10.0.

But again, we do offer the type of service you seem to be looking for, via our Consulting and Feature Sponsorship services. To clarify, your Support service is for addressing product flaws, and offered on an unlimited basis. With our Consulting and Feature Sponsorship services, which are hourly, you can collaboratively prototype your application alongside Isomorphic staff that actually built the features you're using, discuss and suggest new framework features, etc.