Create DOM-based data store for Tree

[peller]

so you can create a Tree out of ul/li markup (ol or ul?)

[bill]

BTW, a few things to think about w/inlining tree data as HTML:

0. of course you need to decide on the format of the HTML. perhaps something like:

<ul>
      <li>meat</li>
            <ul>
                 <li>beef</li>
                 <li>pork</li>
             </ul>
      <li>fruit
            <ul>
                 <li>banana</li>
                 <li>apple</li>
             </ul>
      </li>
</ul>

plus maybe would need attributes like "id" on each <li> node?

1. on instantiation, ComboBox? just converts the HTML to JSON and then uses ItemFileReadStore?. One could argue that's efficient because it's reusing code, or alternately argue that it's inefficient because a custom store would be less lines of code. Tree has the same considerations.

2. dojo.require()'s: currently ComboBox?.js does a dojo.require() of ItemFileReadStore?, so that

<select dojoType=dijit.form.ComboBox>  <input>  <input> ... </select>

format works out of the box, and we don't get bug reports / support questions about ComboBox? not working because it couldn't find the store code. The downside is that ItemFileReadStore? is included even when it's not being used, for cases like

<select dojoType=dijit.form.ComboBox store=myCustomStore>

Tree has the same considerations.

3. Writes: people may want to programatically update the tree in which case you need ItemFileWriteStore? not ItemFileReadStore? (or you need a custom store with update capability). But of course if you don't want that capability then it's just more code being included that isn't being used.

Anyway, food for thought.

[dmachi]

0. I had been thinking about this, and I do think that something like this would make it easier to adopt. I am also planning on supporting the data markup in the store itself in its native format (specific to each store). Something like:

monospace <script type="dojo/data" dojoType="dojox.data.jsonPathStore"> {

meats: [

{name: "beef"}, {name: "pork"}

]

fruit: [

{name: "banana"}, {name: "apple"}

]

} </script> monospace

1. I think this should be done. I don't think that a custom store would change much in terms of efficiency would it? Seems like the main disadvantage of this is that there has to be code to convert into the store's native format (so the store can be instantiated with said data) or we start with an empty store and use store methods to populate it.

2. I hate that it requires ItemFileReadStore?. I dont' want to download 25 or 30k of code for a store i dont' want or need. IMO devs should have to require the store on your own, and while it may default to ItemFileReadStore?, the actual store it uses should be definable. Something like:

monospace <select dijitType="dijit.form.ComboBox?" defaultStore="dojo.data.ItemFileWriteStore?">...</select> monospace

This way you can still use markup but us a store of your own creation/desire. I think using this approach may also require that the code use the store methods to populate the store instead of translating it into a predefined structure and then instantiating the store with that structure.

3. Allowing the user to define and which store might be created automatically for a widget would also solve this problem.

4. The relationship between dojo.data and dijit is a big achilles heel for us right now imo. We do, I think, a decent job of making difficult things easy, but at the same time we make some of the simple things difficult if not impossible. I think significant focus needs to be provided for these issues sooner rather than later.

[bill]

Sorry, by "efficient" I was referring to lines-of-code, not speed-of-execution.

I'm not opposed to the "defaultStore" idea you listed (although I wouldn't call it "default"; that seems a misnomer). As I said above there's a tradeoff involved, because it's a gotcha for people using the widget for the first time and not understanding that they have to dojo.require("dijit.TreeDataStore?") even though they aren't (directly) referencing that anywhere in their code.

[dmachi]

I don't think the efficiency, by the lines of code def, should change that much if we are doing something that walks the markup and uses dojo.data api calls to insert. If we were to try to parse it and convert it into some format that is appropriate for importing to a store then i think it would take more lines of code in addition to being tied to a particular store.

I'm also not tied to defaultStore as then name, just that we have the ability to drive what it is that gets created. I understand the dojo.require() issue but to me it seems like a sin to penalize all users of the code (on the order of 30k or more iirc) in order to make it minimally easier for beginning users. If we put this in documentation that a store (ItemFileReadStore? by default) must be require() for 'auto'/markup based creation of those widgets then Ithink that will cover some of the people, and I'd be happy to tackle easy questions like that from the support perspective until its more common knowledge.

[alex]

Milestone 2.0 deleted

[peller]

ok, there are a bunch of ideas here. What I was originally going for was an 'unobtrusive' Tree that built itself up from UL/LI (or OL, I suppose?) This would not only make the simple case simpler, but might attract a whole new audience for this widget. And I think we have some use cases on our own site screaming out for this functionality (book, api docs) I don't know that we're going to be able to do this for 1.2, but I'd like to try.

[peller]

to make it unobtrusive, the markup would have to have some way to represent closed nodes (perhaps by setting "visible" on the node) and the Tree would have to somehow get this state from the store. I have no idea if that breaks the existing model.

[bill]

I can see why one would want to mark opened/closed nodes, but note that we don't have a way to specify opened/closed state as part of the model (ie, in the dojo.data Item), since, after all:

• conceptually data is neither opened or closed; that's just a difference in how we view it
• it's not items that are opened/closed but rather TreeNodes. Consider for example the following tree where there are two TreeNodes both mapping to the same "John" item, one of which is opened and one of which is closed:

  - Root
        - Marketing
              + John
        - Development
              - John
                    - Paul
                    - George