PDA

View Full Version : What are the options for persisting form, grid, tree data?



simeon
21 Feb 2007, 5:58 AM
I was curious what the different options/strategies are when it comes to persisting data that has been gathered through the UI and updating the UI after the response.

I remember hearing about form validation and new data management features of this release and I am a little confused as to where to focus my learning efforts.

I have looked at the updateManager which appears to submit a form (via AJAX) and returns an http response. If I understand correctly, the response can replace a dom element's contents or be passed to a custom renderer. Is there an example of a custom render anywhere that I can look at?

On a simple form submit I can see the replace approach working ok, but when I am passing around a lot of html form elements, labels, instructions etc. it starts to look like a heavy html replacement rather than a simple data transfer.

The situation I am interested in exploring is the following:
1) submit a request for a json
2) use a form template to convert the json to the form html with labels and instructions.
3) after the user udates the form elements and submits, I want to convert the submitted form back to a json and submit it to the server through a single form input.
4) in the event of an error on the server I want to be able to handle a response json which could flag which data as being in error. This way I can just go back to the form I created and change a few class names on the invalid inputs.

Does this make sense or is there a better way to do this?

I see examples of jsons being converted to grids and trees, but it isn't clear to me how to persist the changes that are made when draging nodes around in a tree control or editing fields in the editable grid.

FYI, some other data persistance situations I will need to address with the above technique:
Submit a json when a user drops a node from one tree into another tree.
Submit a json when a user adds a new node to a tree so I can immediately get a guid for the new node and default form data.

With regard to the tree control, can you point me to an example where you are storing and getting data from a tree node that isn't a default property like text. I will need to store a bunch of meta data on the nodes like a guid, security opions etc that aren't visible but will be used when posting changes to the tree via drag/drop.

I know everyone is busy digesting the alpha code, but I was hoping to get pointed in the right direction. I am having trouble figuring out which examples are the new way and which are the old way...

Thanks. Simeon

BernardChhun
21 Feb 2007, 7:47 AM
I'm not too sure myself about how to answer to the first part of your post simeon... :s



FYI, some other data persistance situations I will need to address with the above technique:
Submit a json when a user drops a node from one tree into another tree.
Submit a json when a user adds a new node to a tree so I can immediately get a guid for the new node and default form data.

For the first submit: You will have to suscribe a function to the endDrag event of the receiving TreePanel and make an AsyncRequest mentionning the changes in the tree.

for your second submit: Suscribe a function to the Append event of the receiving TreePanel. there again make an AsyncRequest requesting a guid then on the success of your callback change the node's id.



With regard to the tree control, can you point me to an example where you are storing and getting data from a tree node that isn't a default property like text. I will need to store a bunch of meta data on the nodes like a guid, security opions etc that aren't visible but will be used when posting changes to the tree via drag/drop.

I tend to use the attributes property of a node to keeps its data that it receives from the server.
keep in mind you can create a new property in attributes any time as long as you have a reference on the node like so:


node.attributes.somethingStrange = "pop!";

that property will exist as long as the node exist.

there you go, I hope I was clear enough. If you want I'll post some code sample from my project. oh and that is the old way of doing things. I'm too busy working on my current project based on the .40 release to check the alpha out...I feel like crying too.