Dynamic Tree Creation

40 views
Skip to first unread message

Peter

unread,
Apr 6, 2009, 8:41:31 AM4/6/09
to mootree
Hi,

I am trying to develop a dynamic build of mootree, ie 1 level at a
time, as generating it all at one time is too slow. However, I would
like to display the grid and use the plus/minus for expanding the
directory so I can kick of an ajaxz call, but because I am only doing
1 level at a time the directory is empty and therefore the expandable
indicator never appears. I should point out that I am using the
'adopt' method with a UL list.

Is there a way of forcing a plus/minus to appear on the grid, even
though the directory is empty? I hope this all makes sense.

Many thanks

Peter

Adriaan Nel

unread,
Apr 6, 2009, 8:46:47 AM4/6/09
to moo...@googlegroups.com
Try miftree, it's much better than mootree: http://mifjs.net/tree/

Regards
Adriaan

Rasmus Schultz

unread,
Apr 6, 2009, 10:41:55 AM4/6/09
to moo...@googlegroups.com
I think "better" is extremely subjective. Yes, it certainly has more features - many tree controls do.

MooTree was designed to be extremely lightweight and small, and in that way is certainly "better" than this tree control.

If what you need is not a simple, lightweight tree, then certainly this (and numerous other) tree controls are "better" for your needs...

evans...@gmail.com

unread,
Apr 6, 2009, 7:02:13 PM4/6/09
to mootree
Don’t listen to those naysayers Rasmus!

I looked at both and mooTree was much better for my needs. Too many
‘features’ simply makes a plugin harder to integrate into your system.

Since I originally setup mooTree on my project, I have totally tricked
it out with the following-

1. Fully recursive accordion opening and closing
2. Built completely from JSON data
3. Right click context menu for each node
4. (context menu) Cut nodes
5. (context menu) Paste nodes
6. (context menu) Rename nodes inline
7. (context menu) Create new folders
8. (context menu) Delete nodes
9. Double click node name to open/close
10. Node name dynamically appended with child count


On Apr 6, 10:41 am, Rasmus Schultz <ras...@mindplay.dk> wrote:
> I think "better" is extremely subjective. Yes, it certainly has more
> features - many tree controls do.
> MooTree was designed to be extremely lightweight and small, and in that way
> is certainly "better" than this tree control.
>
> If what you need is not a simple, lightweight tree, then certainly this (and
> numerous other) tree controls are "better" for your needs...
>

Rasmus Schultz

unread,
Apr 6, 2009, 8:01:24 PM4/6/09
to moo...@googlegroups.com
Precisely :-) ... everyone has different needs - MooTree was designed to be a lean and developer-minded, making it easy to use it as a "core" for your application-specific functionality.

Everyone has different needs - the more features you add, the more bloat everyone has to drag around, and even if it does a million things, there's still a high chance that a component doesn't do precisely what you want.

If you agree with this way of thinking, you might also want to check out my template engine for php:


It's based on the same ideas - it's a lean and very open core, providing common functionality, while attempting to leave every option open for developers to build on top of it.

In my line of work, I build to meet exact specifications for every project, and I can do this faster and more accurately, and without unnecessary bloat, when I have lean and extensible components to build upon, both on the server-side and client-side.

I have also started work on a php platform, but it's very early days for this ...


Not much code to see yet, but as you can see from our mission statement, we're aiming for a lean and extensible codebase. It's going to be a kind of framework, but we prefer the term platform, because we don't want to build yet another MVC framework, or some other fixed pattern - we're trying to leave all options open, solving common tasks in a way that doesn't try to lead you or get in your way.

I believe that every project should be approached in the way most suitable for that project - frameworks that try to be the "end-all be-all" solution for any project, quickly end up in bloatware-land, and usually lead you to use the same patterns for every solution. I prefer a more agile approach.

So now you know a little bit about where I'm coming from :-)

And of course, if mifjs meets your requirements better, use it! That's what I would do - I don't use my own tools for every solution,I use whatever solves the task at hand in the simplest, fastest and most elegant way!

- Rasmus
Reply all
Reply to author
Forward
0 new messages