DynamicTree - tree menu editable in browser

[cagrET]

Hi again, I've coded another menu, now it's more advanced.

You can display or edit tree structures dynamically in your browser. You can import data from html or export data to html, php or sql. You can easily write your own plugin to support another data format.

Example 1: http://gosu.pl/demo/mygosumenu/1.5/example1.html
Example 2: http://gosu.pl/demo/mygosumenu/1.5/example2.html

Download (1.5.0+): http://sourceforge.net/project/showfiles.php?group_id=69763&package_id=105852

Hope you like it !

[mjs1]

thx!

example #2 is just what i needed. i've been searching for a tree menu with methods set to insert/modify/delete nodes and you're script came at just the right moment. -- seriously many thanks, you've saved me hours :)

btw, the export feature is nice. i may extend it to output an xml doc.

thanks again. you're a life saver!

[mjs1]

thank you again for the quality work and hours spent. in future versions will you please give thought to changing how the tree data is gathered?

as javascript becomes the presentation medium used for web applications, trees will be built and altered at runtime. although your approach is extremely easy for designers to implement, it is a bit inefficient for development as it requires extra cpu time to first build the tree on the server then parse its structure on the client.

i think you have done quality work and hope my words are perceived as constructive.

thanks again, matt.

[cagrET]

I understand your point of view, but I don't see your suggestions a good way to go. Try to ask yourself a few questions:

Does it work for you ? Does it solve your problem ?
Are you looking for a perfect software that solves everyone needs ?
Is it slow at your case ? Did you make any tests ?

I don't agree that it is inefficient.

>> it requires extra cpu time to first build the tree on the server
Generating xml data is 100(?) faster than loading it. A function calling itself recursively that makes some simple echos.

>> then parse its structure on the client
If you have javascript enabled the browser parses the whole page structure independently whether you use dom later or not. It is already loaded. I have participated in many contests in the past and I always care about the speed, I think that this solution is quite fast.

[mjs1]

i definately agree that your solution is a valid approach and do not insist that a different approach is necessary. inefficient was definately the wrong word, that's like telling a hunter his gun shoots rice pellets. no i have not made any timed tests.

during the last week i've tested more tree scripts than i can count and can say with all confidence(!) that yours has the BEST set of functionality and potential. to be clear, i'm not asking for you to make the changes below or spoon feed me a script fit for my exact purpose. i am only sharing with you constructive ideas discovered while attempting to implement your script within our application. if these offend you i'll remove them immediately...

> hmmm

server process builds tree
- most developer's are not known for their html skills. bugs created by mediocre html knowledge require additional testing time and typically additional web designer type to fix. developers can prepare structured arrays or objects and leave the html presentation to the designers.

client process inserts images at runtime
- if the tree is built on the server, why insert images at runtime?

overwrites onclick on first anchor within folders and nodes
- tree will call functions using textClickListener but each node loses the ability to have unique onclick events. although i do think the Listener structure does offer additional power here.
- again if the use of html as the structured data format, why overwrite the events?

parsing of node type from tree's html is based off classes names
- consider using id's and leave classes to handle appearance only.


> some of the great things i like about this script

code quality
- clear, concise and easy to understand. the community should take notice.

error handling
- throwing clear errors is a major boost for ui development ease. i hope others learn from this.

actions.js
- seperation of actions into a seperate file and applying them at runtime is great. it's an interesting technique. thanks, i plan on exploring this further

Listener
- it reminds me a lot of ASBroadcaster replacements for Flash MX, very nice and very useful class - thank you.


i thank you again for sharing your code and time with the community. you are obviously an experienced javascripter and i hope you see this as a constructive review from a stranger rather than an attack on your approach or skills.

i won't harp on this anymore, my .02 got spent a long time ago. thanks again this really one of the best written open source javascripts i've ever seen.

thx, matt

[cagrET]

Thanks for all your suggestions. No, it does not offend me, it's okay ;)
I see here some good points. Later when I find some time, I will write some more regarding it.

Btw. I have found a bug (thanks to you), it occurs when you have more than 20 records in a tree when starting editing. It is because I forgot the "tmpTreeId" debug variable, I've replaced it with the right thing, download 1.5.2 version, changes only to this variable in actions.js file.

[mjs1]

awesome, i'll definately watch this script!

thx again :thumbsup:

[Vladdy]

Your markup is suffering for divitis.
Unordered lists are appropriate choice.

href="javascript:foo()" is incorrect and unnecessary - use <span onclick="foo()">

Graphics do not scale properly with font-size change (breaks in lines)

I bet use of innerHTML and outerHTML can be avoided to improve script compliance.

Other than that - pretty good.

[jkd]

href="javascript:foo()" is incorrect and unnecessary - use <span onclick="foo()">

Not the best choice, maybe, but certainly not incorrect.

[Vladdy]

"javascript:" is not among the Internet Official Protocol Standards:
ftp://ftp.rfc-editor.org/in-notes/std/std1.txt
and therefore its usage with anchor element http://www.w3.org/TR/html401/struct/links.html#h-12.2
is incorrect

[jkd]

A valid URI does not need to contain an "official" protocol.

Besides, Gopher isn't mentioned on that page once, but as you can see from here:
http://www.ietf.org/rfc/rfc2396.txt

It is certainly considered a formal URI. Clients and servers can define their own protocols as needed; isbn: is a popular one for demonstrating XML, XLink and/or RDF in describing books.

[Kuker]

hi, i've found your script very useful, but is there a (simple) way to make the open submenus close when the person open a new submenu? (i'm working on the 1.2 version of the script). tks!

[liorean]

A valid URI does not need to contain an "official" protocol.False. Only registred URL schemes are valid URLs and only registred URN schemes are valid URNs, and since URIs are either URLs or URNs it is a requirement that the scheme is valid for it to be a valid URI.
Besides, Gopher isn't mentioned on that page once, but as you can see from here:http://www.ietf.org/rfc/rfc2396.txt

It is certainly considered a formal URI. Clients and servers can define their own protocols as needed; isbn: is a popular one for demonstrating XML, XLink and/or RDF in describing books.All the schemes presented as official in the URL, URN and URI RFCs are considered registred whether they are in that list or not.

Clients and servers may agree to a pseudo URI scheme that follows the regular URI rules, but they are not valid just because of that. It's like my analogy of CSS and XML - your XML document may be syntaxtically perfect (well-formed) and still not be valid. Your CSS may follow the CSS grammar, but if you use nonstandard properties it is not valid CSS. Your URI may follow the syntax rules, but if your scheme is not registred, it's just a pseudo URI, not a valid URI.