Dynamic Content Stucture menu (AJAX) prototype

Wednesday 05 October 2005 7:04:26 am

Thanks Bertrand.

I agree that AJAX technology is cool, it should be used with some moderation... But for the contentstructuremenu its perfect.

The good news is that our friends at VisionWT has actually improved the menu, and hopefully their improvements will go into the extension it self in the near future. I'm quite curious to see what fun they have done :-)

About the timeout. I have just set the timeout to 2 seconds inorder to test it.. This should probably be raised to 10 or 30 seconds... To test it you can increase the value in the "startTimeout" function of csm_aj.js

Kristian

http://ez.no/ez_publish/documenta...tricks/show_which_templates_are_used
http://ez.no/doc/ez_publish/techn...te_operators/miscellaneous/attribute

Wednesday 05 October 2005 11:34:49 am

Yeah, icons and context menu work nicely.

One thing makes it look kinda ad hoc though: the chars used to represent the tree (ie + and -) aren't all of the same size and thus not in the same place. It would likely be better to use images for that, no?

(Personally, I rather like the arrow stuff with > and it's downward cousin, think OSX)

Visit http://triligon.org

Wednesday 05 October 2005 1:32:39 pm

Which realistically could still be improved upon, no?

Visit http://triligon.org

Thursday 06 October 2005 12:29:11 am

I'd say it should fetch a certain number of levels at the same time, then reload if needed.

With the same argument, the current menu creates a lot of unused traffic and server load for sites with many pages ;)

Visit http://triligon.org

Thursday 06 October 2005 1:11:02 am

Unfortunately I have to agree on the multiple server hits for the menu, Frederik. It is clear that it will generate more requests, but on the other hand less data is transfered by default from the server to the client, which reduces the file size and the resource usage for the browser.
 
 I know for instance that I often have to disable the content structure menu on big sites due to the browser getting slow (yes, I should limit the display of nodes with lots of children ^^).

On a project i'm currently working on, the default admin page is 538 KB with the menu displayed, and 58 KB when it's hidden... almost 90% is for the menu, so in my opinion something HAS to be done.

Of course, but now you are comparing with a menu that is already too big and which should be stripped.
I think you are right about the server load though. If we can implement the ajax menu in such a way that in can cache menu data between requests we can probably make it much more efficient than the current menu.

Regarding AJAX usage in general, I agree that the resource question is relevant when talking about the tree menu, but if you think far ahead and try to imagine a full AJAX interface, the advantages of such an approach are huge, even for the server... you only request the block you need (like the middle block with preview and stuff... when you enable / disable preview or locations or anything, it just gets fetched from the server and added at its location. The children list is not reloaded, nor is the content tree... 

There are a couple of challenges: Sometimes you need to update more than one of the parts. This can even depend on the contents of the new part you are loading. Sometimes some of the parts change behavior according to the changes in other parts. In other words, if you implement a full AJAX admin you need to actually program all of this logic instead of just having it in HTML templates like now. Another interresting issue is writing extensions that should plug into the administration interface, they also need to work with this. And of course most of the time you would like to use the functionality the administration interface provides outside of the AJAX admin. So you would need to support both also for people who don't have all the javascript capabilities.

 Finally, another though regarding the content tree: something similar to bookmarks could be implemented. Most users visit on a regular basis a maximum of 8 to 10 nodes. Maybe these nodes could be loaded by default in the menu in order to limit the number of requests to the server ?

Hmm.. isn't this what the bookmarks do already?

Thursday 06 October 2005 1:32:20 am

Parts of the administration interface could for instance be splitted in reusable blocks that would be used for both AJAX and non-AJAX interfaces. Of course big code pieces would only be used in one interface, but reusability is not a big no here.

We are probably going to introduce "widgets" in eZ publish 4.0 which will do exactly this. So in some way we are going in the right direction already.

Another eZ PHP Component ? :)

If implemented, definitely :)

Thursday 06 October 2005 1:42:33 am

Daniele, indeed you are right about that. But I also know that such a page size is somewhat hurting my browser, so it's not just about transfer size, but it would already be a big improvement if that was properly handled.

About your widgets thing, Frederik: great :)

As far as I can see based on new projects, AJAX is the next big thing in web applications interfaces, and it would probably be a mistake if eZ was not considering that... but since you are always keeping at the top of new technologies, I'm pretty confident ;)

Thursday 06 October 2005 3:12:14 am

> A more generalized way to do AJAX within eZpublish would obviously be greatly appreciated ;)

Yes, I agree, the compress method is a workaround, ajax solution is the right solution. We are waiting for it to become the real solution.

Friday 07 October 2005 9:50:36 am

And about the : Only show the elements which are bookmarked. This is pure _evil_! This is the same as Microsoft has been doing for Office for some years, and i really hate it!

This is just my 50 norwegian øre (equivalent of 50cent only worth a bit less ;-) )

Kristian

http://ez.no/ez_publish/documenta...tricks/show_which_templates_are_used
http://ez.no/doc/ez_publish/techn...te_operators/miscellaneous/attribute

Monday 10 October 2005 12:28:41 am

Well if the network connection is spotty, the current admin interface will be a pain to use as well.

But a real world example: I got a site with about 50 pages and about 200 forum posts (which is very little by my standards for a forum) but already, with 250 objects, loading up the standard admin interface becomes nearly unbearable so I think I'll install the dhtml menu soon. Of course I might also try to figure out how to exclude forums from the dynamic menu ;)

Visit http://triligon.org