Opened 13 years ago
Closed 9 years ago
#5422 closed enhancement (patchwelcome)
Create DOM-based data store for Tree
Reported by: | Adam Peller | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | future |
Component: | Dijit | Version: | 0.9 |
Keywords: | Cc: | Tom Trenka | |
Blocked By: | Blocking: |
Description
so you can create a Tree out of ul/li markup (ol or ul?)
Change History (11)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
- 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
- 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.
- 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.
- Allowing the user to define and which store might be created automatically for a widget would also solve this problem.
- 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.
comment:3 Changed 13 years ago by
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.
comment:4 Changed 13 years ago by
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.
comment:6 Changed 13 years ago by
Milestone: | 1.3 → 1.2 |
---|
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.
comment:7 Changed 13 years ago by
Cc: | Tom Trenka added |
---|
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.
comment:8 Changed 13 years ago by
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
comment:9 Changed 13 years ago by
Milestone: | 1.2 → future |
---|
comment:11 Changed 9 years ago by
Resolution: | → patchwelcome |
---|---|
Status: | new → closed |
BTW, a few things to think about w/inlining tree data as HTML:
plus maybe would need attributes like "id" on each <li> node?
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
Tree has the same considerations.
Anyway, food for thought.