Hi Bill,
Need your direct input as dijit.Tree contributor.

I am doing dynamic UI framework and $subj is part of it. Hopefully
solution will be generic enough to be contributed as part of dojox and
eventually dijit.
First draft shows it is possible and elegant enough:
http://xmlaspect.org/dojoPlay2011/AccordionTree.html
Please do not pay much attention to tree inside of Accordion - it could
be any content. The name is picked randomly. Semantically widget is
Accordion extension to use hierarchical data and customized content
matching data branch. Same extensions will be done on other dijits not
yet capable to use data store as UI source: tab, icon list, etc.

The concern is in reused code and patterns: many parts of Tree are so
generic that it worth to have them separated into mix-in or embed into
higher abstraction layer:

- selection and state persistence
- _store2model as automatic "model" creation if store is given
- DnD controller
- some others

Initially I have been thinking to use Tree code directly, but it does
not have functionality to functions complete separation and could not be
applied to Accordion and others directly say by *function.call(...)*
For now I have cloned the code but next step will be generalizing due to
3 components are using same functionality: Tree, Accordion, Tab.
Also given abstraction layer is applicable to whole Stackable layouts set.

My suspicion that Form components will reuse good peace of same code.

Could you give some advises on the generic patterns and places to keep
the code? May be on case-by-case basis...
2.0 is not that far and could gain from this discussion as well.

Thanks,
- Sasha


On 11/6/2011 5:17 PM, Bill Keese wrote:
That's certainly possible. Your question isn't about Tree so much
as XMLStore, and I'm not familiar w/XMLStore.

On Mon, Nov 7, 2011 at 8:16 AM, Sasha Firsov <sasha at firsov.net
wrote:

Hi Bill,
Proposed solution works only on 1st level of encapsulation, i.e.
for "/A/B". For some reason query={tagName:'C'"} does not return
any results.

In sample (uses "/root/A/B/C/D" structure)
http://xmlaspect.org/dojoPlay2011/ObjectTypesNavigator.html
I could not select "B" or "C" tagName in TreeStoreModel.
queryOptions: {deep: true} on Store level do not help. And there
is no such option in TreeStoreModel(as in "B sub Tree deep").
My suspicion that query works only on root children (as in "A
subtree" case).
Is there any way to make query={tagName:'C'"} working?

Only correct way I found was in complex "B w/ getChildren"
overriding. Which is awkward and definitely not generic. Thinking
of dojox.data.StoreXPathQuery mixin to substitute tagName with
XPath selector...
Than I will be able to reuse patched store in other dijits as well.

Thanks,
Sasha

On 11/6/2011 2:43 AM, Bill Keese wrote:
Despite your comment about what not to suggest, it sounds like
you should use TreeStoreModel (rather than ForestModel), with a
query to get <C> as the root, and then set showRoot=false on the
tree.

On Sat, Nov 5, 2011 at 10:25 AM, Sasha Firsov <sasha at firsov.net
wrote:


I am trying to visualize tree and sub-tree for same data
model(dojox.data.XmlStore ). Both trees are rendered properly.
But I could not find how to select in
dijit.tree.ForestStoreModel the
sub-tree of store.

XML is straight-forward and tag-based:
<A><B><C><D1/><D2/>...</C></B><B1/></A>

Is there a query string in model to select children of "C" tag?

Could be "C" tag name used for children selection?

Do not propose to use:
- "C" tag selection. Need children only( D1, D2,...)
- different XmlStore instances, the idea is to have SAME
synchronized
data across different views.
- attributes: they are used for text extraction but could not
be used
for filtering/branch location.


Thanks,
Sasha

________________________________________________________

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

Dojo-interest at mail.dojotoolkit.org
<mailto:Dojo-interest at mail.dojotoolkit.org>
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest




________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

Dojo-interest at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111109/c98dd9f9/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3861 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111109/c98dd9f9/attachment-0001.p7s

Search Discussions

  • Bill Keese at Nov 9, 2011 at 11:09 pm
    It's an interesting demo. I'm not sure what to say about splitting out
    common Tree functionality. Would have to try it and see how it worked
    out. Of course some stuff, like selection and DnD controller, are already
    split out.

    _store2model is for a deprecated usage of Tree when the user specifies a
    store directly instead of specifying a model, but now with the new
    dojo.store maybe we should be specifying a store directly again. I'm not
    sure. BTW I just checked in tree/ObjectStoreModel for bridging between a
    new dojo.store and Tree, so you should check that out.
    On Thu, Nov 10, 2011 at 10:19 AM, Sasha Firsov wrote:

    Hi Bill,
    Need your direct input as dijit.Tree contributor.

    I am doing dynamic UI framework and $subj is part of it. Hopefully
    solution will be generic enough to be contributed as part of dojox and
    eventually dijit.
    First draft shows it is possible and elegant enough:
    http://xmlaspect.org/dojoPlay2011/AccordionTree.html
    Please do not pay much attention to tree inside of Accordion - it could be
    any content. The name is picked randomly. Semantically widget is Accordion
    extension to use hierarchical data and customized content matching data
    branch. Same extensions will be done on other dijits not yet capable to use
    data store as UI source: tab, icon list, etc.

    The concern is in reused code and patterns: many parts of Tree are so
    generic that it worth to have them separated into mix-in or embed into
    higher abstraction layer:

    - selection and state persistence
    - _store2model as automatic "model" creation if store is given
    - DnD controller
    - some others

    Initially I have been thinking to use Tree code directly, but it does not
    have functionality to functions complete separation and could not be
    applied to Accordion and others directly say by *function.call(...)*
    For now I have cloned the code but next step will be generalizing due to 3
    components are using same functionality: Tree, Accordion, Tab.
    Also given abstraction layer is applicable to whole Stackable layouts set.

    My suspicion that Form components will reuse good peace of same code.

    Could you give some advises on the generic patterns and places to keep the
    code? May be on case-by-case basis...
    2.0 is not that far and could gain from this discussion as well.

    Thanks,
    - Sasha



    On 11/6/2011 5:17 PM, Bill Keese wrote:

    That's certainly possible. Your question isn't about Tree so much as
    XMLStore, and I'm not familiar w/XMLStore.
    On Mon, Nov 7, 2011 at 8:16 AM, Sasha Firsov wrote:

    Hi Bill,
    Proposed solution works only on 1st level of encapsulation, i.e. for
    "/A/B". For some reason query={tagName:'C'"} does not return any results.

    In sample (uses "/root/A/B/C/D" structure)
    http://xmlaspect.org/dojoPlay2011/ObjectTypesNavigator.html
    I could not select "B" or "C" tagName in TreeStoreModel. queryOptions:
    {deep: true} on Store level do not help. And there is no such option in
    TreeStoreModel(as in "B sub Tree deep").
    My suspicion that query works only on root children (as in "A subtree"
    case).
    Is there any way to make query={tagName:'C'"} working?

    Only correct way I found was in complex "B w/ getChildren" overriding.
    Which is awkward and definitely not generic. Thinking of
    dojox.data.StoreXPathQuery mixin to substitute tagName with XPath
    selector...
    Than I will be able to reuse patched store in other dijits as well.

    Thanks,
    Sasha


    On 11/6/2011 2:43 AM, Bill Keese wrote:

    Despite your comment about what not to suggest, it sounds like you should
    use TreeStoreModel (rather than ForestModel), with a query to get <C> as
    the root, and then set showRoot=false on the tree.
    On Sat, Nov 5, 2011 at 10:25 AM, Sasha Firsov wrote:


    I am trying to visualize tree and sub-tree for same data
    model(dojox.data.XmlStore ). Both trees are rendered properly.
    But I could not find how to select in dijit.tree.ForestStoreModel the
    sub-tree of store.

    XML is straight-forward and tag-based:
    <A><B><C><D1/><D2/>...</C></B><B1/></A>

    Is there a query string in model to select children of "C" tag?

    Could be "C" tag name used for children selection?

    Do not propose to use:
    - "C" tag selection. Need children only( D1, D2,...)
    - different XmlStore instances, the idea is to have SAME synchronized
    data across different views.
    - attributes: they are used for text extraction but could not be used
    for filtering/branch location.


    Thanks,
    Sasha

    ________________________________________________________

    ________________________________________________________
    Dojotoolkit: http://dojotoolkit.org
    Reference Guide: http://dojotoolkit.org/reference-guide
    API Documentation: http://dojotoolkit.org/api
    Tutorials: http://dojotoolkit.org/documentation

    Dojo-interest at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

    ________________________________________________________
    Dojotoolkit: http://dojotoolkit.org
    Reference Guide: http://dojotoolkit.org/reference-guide
    API Documentation: http://dojotoolkit.org/api
    Tutorials: http://dojotoolkit.org/documentation
    Dojo-interest at mail.dojotoolkit.orghttp://mail.dojotoolkit.org/mailman/listinfo/dojo-interest

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111110/e0355088/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedNov 9, '11 at 8:19p
activeNov 9, '11 at 11:09p
posts2
users2
websitedojotoolkit.org

2 users in discussion

Sasha Firsov: 1 post Bill Keese: 1 post

People

Translate

site design / logo © 2021 Grokbase