Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Ext 4 trees a step forward?

  1. #1
    Sencha Premium User westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    1,035

    Default Ext 4 trees a step forward?

    Hi,

    Firstly, would really use some better documentation for Tree's, and how the 6 classes for them interact, and some much better, complex examples (whilst we're at it how about using the Ext 4 way in all your examples? Seriously, throw away all the ones that use Ext 3 class syntax...)

    It's not got much clearer how trees are meant to be working from reading and playing with the Ext src for the last few days.

    Having written a complex custom tree in Ext 2 I was expecting it to be easier to pick up, but am finding it hard to get my head around at the moment...

    A brief idea of what I'm trying to reproduce:
    In Ext 2 I had the concept of a tree configuration that could be laid out and identify what the expected node types are at each level, i.e. the structure of the tree hierarchy.
    It included the concept of category nodes at each level, that provided a parent node for an area (something seriously lacking from tree's in general imo).

    The config would identify the text for the category nodes, their CSS class, whether they are displayed at all (or flattened), the CSS class for data nodes, and a handler that would handle custom rendering and control and action what operations (via context menu or automatic bbar) could be performed on the category node or data nodes etc.
    As part of this I also had a custom TreeLoader as well as a TreePanel.

    It works great, and is very flexible.


    So, am now trying to figure out how to accomplish similar in Ext 4... I thought that models, and their associations may provide part of the solution, identifying how things are related, and what are children of what. This is part of what had me excited when I first saw the new model stuff.

    This doesn't appear to be the case at present though, since it looks like a TreeStore can only have a single model, and associations are seemingly being ignored (at least in my simplistic test setup currently).

    I think I resigned myself to the fact I need to override a lot to get the same results I had before, but think decoupling the models from it is nigh-on impossible.

    The six classes of note I believe are:
    • TreePanel
    • TreeStore
    • TreeView
    • Tree
    • NodeStore
    • NodeInterface


    This need some serious documentation attention in my opinion; have a look at these forums at the number of people having trouble even getting started with a simple tree, let alone doing anything more complex...

    I'm having trouble seeing how models are meant to fit into anything but the most simple trees.
    Are you meant to be able to have different models are different levels?
    e.g. something like
    -Organisation (organisation model)
    ------Users
    ------------User1 (User model)
    ------------User2
    ------Groups
    ------------Group1 (Group model)
    ------------Group2

    From what I can see this is not the case.
    Perhaps I'm meant to have a Tree node model that covers all cases; containing something like text, cssClass, someObject (that will be used by custom rendering, akin to the model I was expecting to see)?

    Not really sure what answer I'm expecting to this post, if any; suffice to say that currently I am finding it hard to see the Ext 4 tree as a step forward at all.

    It didn't need bring closer to grids in my opinion (via the common table base), trees are not tables, and have very little in common. This is not inheritance as I see it but some kind of convenient bending of the definitions for some reason.
    Tree's now have columns with data indexes? Really? This is tree data, nodes should not need to be related or have a common data interface.

    Sorry if this is a bit rantish, but, well, I'm starting to wonder whether porting my old tree to Ext 3, then running 3 and 4 side-by-side, is the way to go; which is obviously not a desirable solution.

    I think for now I'm going to setup a generic model for my tree nodes, create my config class shell, and see if I can force the model change on different nodes, and see how it goes.

    Hope I make some progress, since a very complex, flexible tree is absolutely key to the product we are currently working on, and future products (since is the way we allow users to change system configuration options).
    The pressure is starting to mount on this component now everything else is starting to fall into place...

    If you made it this far, thanks for reading.

    Cheers,
    Westy

  2. #2

    Default

    Very good Post.

    I'm having trouble seeing how models are meant to fit into anything but the most simple trees.
    Are you meant to be able to have different models are different levels?
    e.g. something like
    -Organisation (organisation model)
    ------Users
    ------------User1 (User model)
    ------------User2
    ------Groups
    ------------Group1 (Group model)
    ------------Group2
    This is one of my biggest problems with Ext Trees. I wish the TreeStore supports associations.

  3. #3
    Sencha User ykey's Avatar
    Join Date
    Mar 2010
    Location
    USA
    Posts
    245

    Default

    Definitely agree, I posted about this a month ago and didn't receive a response.

    http://www.sencha.com/forum/showthre...d-Associations

  4. #4
    Ext JS Premium Member stevil's Avatar
    Join Date
    Nov 2007
    Location
    Denver, CO
    Posts
    1,045

    Default

    Agreed - when you drill into the source from the doc, that source is also VERY different from the actual Beta2 code (at least for TreeStore) - It prompted me to write a migration thread on it that seems no longer necessary.

  5. #5
    Sencha User
    Join Date
    Mar 2011
    Location
    Germany
    Posts
    198

    Default

    Had the same problem with Ext.draw.* and MVC (threads are in "Help"). I'm waiting for beta3 and then start using Extjs4. At the moment it makes no sense to me.

    I don't use the Docs anymore. I miss the tabs and there are bugs in the displaying engine of the docs site itself.
    For me it is easier to "cat/vi/grep" through the src folder.

  6. #6
    Sencha Premium Member steffenk's Avatar
    Join Date
    Jul 2007
    Location
    Haan, Germany
    Posts
    2,676

    Default

    docs are fine to see the inherits, that is difficult to see with grep. But i also use docs+IDE (phpStorm) to find out.
    vg Steffen
    --------------------------------------
    Release Manager of TYPO3 4.5

  7. #7
    Sencha Premium User westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    1,035

    Default

    I've given up on the docs as well to be honest, the ever present likelihood to go to some URL that bears no relation to what you clicked on gets frustrating, and not being able to middle click on links and open in a new tab frustrates too.

    I've given up posting in the API doc issues thread though since the problems should be staring the devs in the face without us having to post each one, just trying to use the API docs should be enough...

    I generally look at the src, and the comments that are used to generate the doc content... Sublime Text is so fast for navigating the src it's much quicker anyway.

  8. #8
    Sencha User
    Join Date
    Mar 2007
    Location
    Haarlem, Netherlands
    Posts
    1,243

    Default

    @all

    We are currently writing guides and docs for the new Tree so hopefully this will make it easier for you all to grasp the new concepts behind Tree.

    We are also planning on having a final piece added which is the TreeWriter. That will allow you to easily send back changes made to the tree structure to the server.

    Tree's with multiple models is not something we will be supporting for 4.0. For now every TreeStore is based on one model. This should be sufficient for most Tree use cases and for the special cases there are workarounds.

    If you guys have some special use case that you would like to see done with the new Tree, let us know and we can try to show you an example of how it can be done.

  9. #9
    Sencha Premium User westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    1,035

    Default

    Hi Tommy,

    Thanks for the reply.

    I issue I'm having at the moment is the difficulty in extending some of the core classes that make up the tree support.

    For example, I want to add data to each node in the tree, effectively attaching an instance of a tree config class to each one that provides handlers and additional data to be used by them, so need to hook into the node creation process ideally.
    As far as I can see node creation is done in the very non-Ext looking Ext.data.NodeInterface class, which returns a prototype from a method... not the easiest thing to override a few methods in really.
    I think I may be able to override the TreeStore's fillNode method to accomplish what I need though, but would rather get closer to where the real work is done.

    Also, I need to hook into the load process, and manually create what I call category nodes, that act as a parent node for the branch on the tree, again adding a class to it that provides handlers and additional data to it. I also add additional parameters to provide better context for a load call, providing the ancestor list for example, and the information on what data (or set of data) is required at this stage of the load (again by my config class attached to each node).

    Now I admit it's not a simple use-case, and I may not be explaining it very well. I'm not about to post my Ext 2 config, handler, treepanel and treeloader overrides though.

    I'll keep battling with what we've got, but think I'll still finding myself missing the old TreeLoader class. I don't think it was broken.

    I'm also still curious to know how a tree is a table in a class hierarchy sense.

    Regards,
    Westy

  10. #10

    Default

    TommyMaintz - would you mind expanding on "Tree's with multiple models is not something we will be supporting for 4.0"?

    This is of great concern to me, because with the application we're building this is very important to us. If you think of an organisation as a tree, it contains the locations, roles, departments, etc. Each one is it's own model, but linked together through the organisation tree.

    I assume the suggestion here would be to just link an ID reference to the related store, plus the name for display?

Page 1 of 2 12 LastLast

Similar Threads

  1. Step by step tutorial Desktop
    By blow in forum Ext 2.x: Help & Discussion
    Replies: 2
    Last Post: 14 Oct 2009, 3:40 PM
  2. Step-by-step instructions for running Explorer demo. . .
    By dmdabbs in forum Ext GWT: Discussion
    Replies: 0
    Last Post: 14 Sep 2009, 12:12 PM
  3. step by step configuration
    By baksheen in forum Community Discussion
    Replies: 0
    Last Post: 6 Jul 2009, 6:51 AM
  4. AJAX PHP Step by Step example
    By bluesapphire in forum Ext 2.x: Help & Discussion
    Replies: 2
    Last Post: 20 Jun 2008, 4:44 PM
  5. Portal Drag&Drop step by step
    By Evolic in forum Ext 2.x: Help & Discussion
    Replies: 0
    Last Post: 10 Apr 2008, 7:12 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •