[Dojo-interest] JSONRestStore lazyload design issue

John Locke mail at freelock.com
Sun Jul 19 15:42:31 EDT 2009


Hi,

This sounds like a great improvement, allowing the name and children
attributes in children of a tree item.

I've got a couple scenarios for additional features I'd like to see, and
may contribute if I can figure out a good approach.

1. Enhance JsonRestStore to send the name/children attributes when the
parent item is saved with a PUT.

Right now, I have a couple trees that allow users to drag-and-drop to
change the order of items. On the server side, I simply store the JSON
in the database, and send it back out on future requests. JsonRestStore
already does the hard work for me, adding $refs for each child item to
the parent item being saved. So it would be great to allow the tree to
have something like storeChildAttrs: ['$ref','name','hasChildren'] so
that no additional work needs to be done on the server to get the
lazy-load enhancements we're discussing.

2. Enhance JsonRestStore to support arbitrary child attributes in the
parent item.

Pretty much what I just described, but just specifying I'd like the
attribute list to be specified in a setting. I'm overriding treenodes
with additional parameters that get loaded and shown when rendered in
the tree. I'd like to be able to specify which attributes to save for
lazy-loading purposes.


3. Allow for saving entire child items in the parent item. This is a
completely different problem I'm trying to solve, and I don't know if
JsonRestStore is the place to do it--I'm looking for a suggested way of
solving this.

I'm trying to put together a template system. Users will use a tree to
add/re-order items in the tree. I want to save the resulting tree as a
single document, and then be able to copy it to new instances along with
all child items. The child items should be new instances, so I basically
want to clone the tree structure, and then save them as JsonRestStore items.

I was thinking of attaching a tree to an ItemFileWriteStore for editing,
and then doing the work of splitting out the items on the server for
future access via JsonRestStore. But if I can have a setting for
JsonRestStore to store all the attributes of child items directly in the
parent, with recursion, this would be a far nicer way of doing it.
Especially if I can have a function in the tree model to change this
setting in the store based on what item is being stored (and replace
item ids as necessary).

Cheers,
-- 
John Locke
http://freelock.com


-------- Original Message  --------
Subject: Re: [Dojo-interest] JSONRestStore lazyload design issue
From: Kris Zyp <kris at sitepen.com>
To: dojo-interest at mail.dojotoolkit.org
Date: Sun 19 Jul 2009 06:33:18 AM PDT
> Yes, I agree, this is just another symptom of the same problem with
> the Tree that I had mentioned earlier when explaining JRS+Tree
> behavior. The TreeStoreModel needs to allow an alternate loading
> scheme where each displayed is allowed to be a non-fully loaded item
> (isItemLoaded returns false), and a node is loaded (via loadItem) when
> it is expanded (but each of the children items are not loaded until
> they are expanded). This would allow you to have nodes that when
> expanded, JRS would request the full item with children (rather
> providing the children (and their ids) before expansion). For example
> when the root was expanded:
> {id:"1", name:"Root", children:[{$ref:"2", name:"Child 1", children:
> true}, {$ref:"3", name:"Child 2", children: false}]}
> Thus children ids are only computed when needed.
>
> Taking a look at TreeStoreModel.js, it looks like this would be really
> easy to add an option to support this type of loading mechanism. I'll
> put together a patch/ticket and see if we can get this available soon.
>
> Kris
>
> Jean-Rubin Leonard wrote:
> > Hi all,
> > I had noticed it but had not made a big case of it but there is an
> > issue that was brought to my attention by Jochen Zimmermann
> > <zet4080 at gmx.de>. He is having problems posting to the mailling list
> > so I'm taking the ball and putting this issue for discussion to
> > validate our shared concern.
>
> > Right now the way the lazyloading of the store works is that a node
> > presents itself with its information and if it has children it says
> > (conceptually of course) here are my children they are named 1, 2 and
> > 3 (children : {ref:1....}. While this works it is very expensive on
> > the server. I had experienced it but Jochen is the one who formally
> > explains it: If we have 100 root nodes with each a 100 children, we
> > will have to load 10100 records from the database to create the
> > structure.
>
> > The approach that I had initially tried was to have the root nodes
> > (and each subsequent parent) say: this is my information and (if they
> > do) I have children and leave it at that. If we do so, only the 100
> > root nodes would be loaded at first. Those with children would have
> > the expando beside their name. We would know they have children but
> > these children would be loaded if and only if we click on the expando.
> > At which point we would get the child information and we repeat as
> > needed. This would be a far less expensive way of getting the lazy
> > load behavior and one we think we should move towards.
>
> > Is there a ready made solution or should we request a feature in dojo?
> > Do you guys see the sense in what we are saying?
> > Thanks for feedback,
> > JR
> > _______________________________________________
> > FAQ: http://dojotoolkit.org/support/faq
> > Book: http://dojotoolkit.org/docs/book
> > Forums: http://dojotoolkit.org/forum
> > Dojo-interest at mail.dojotoolkit.org
> > http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
>

_______________________________________________
FAQ: http://dojotoolkit.org/support/faq
Book: http://dojotoolkit.org/docs/book
Forums: http://dojotoolkit.org/forum
Dojo-interest at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

!DSPAM:4a6320c2248236208116028!





More information about the Dojo-interest mailing list