This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » Developer » Dynamic Content Stucture menu (AJAX)...
expandshrink

Dynamic Content Stucture menu (AJAX) prototype

Dynamic Content Stucture menu (AJAX) prototype

Tuesday 21 June 2005 11:04:03 pm - 93 replies

Hello everyone,

I have uploaded a Dynamic loading Content structure menu for eZ publish administration interface, using asynchronous javascript. EDIT:
The contribution was originally a prototype developed by me. It has now been contributed to by David Heath from VisionWT, and is now a good replacement for the original menu.

Here is a link to the contribution:

http://ez.no/community/contribs/hacks/dynamic_content_stucture_menu_ajax

Note:
My part of the development is done on my spare time, and is not connected to my work in eZ systems.

Modified on Thursday 20 October 2005 11:02:18 pm by Kristian Hole

Wednesday 05 October 2005 4:11:40 pm

Thanks for the infos; I have tried the SVN version, thanks for the icons blunk.gif Emoticon

Regarding AJAX for web interfaces, in my opinion it could become the future of admin interfaces. It will be great for frontend sites for forms validation, complex search forms or remote information fetching.

A full AJAX interface for ezp would be amazing but not tomorrow blunk.gif Emoticon

Wednesday 05 October 2005 8:34:49 pm

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)

Wednesday 05 October 2005 10:30:39 pm

I think it would be better to just keep the design of the standard content structure menu.

Wednesday 05 October 2005 10:32:39 pm

Which realistically could still be improved upon, no?

Thursday 06 October 2005 8:39:11 am

There is always room for improvement. If you have any good ideas: shoot happy.gif Emoticon

Realistically, I'm not certain if an AJAX menu is _the_ sollution since it will generate more requests and the total amount of data transfer will increase. Obviously some of you have been running this, what are your performance experiences with the menu? (how many simultaneous users?)

Thursday 06 October 2005 9: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 blunk.gif Emoticon

Thursday 06 October 2005 9:39:30 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 ^^).

To Gabriel: your answer came while I was writing mine. I see we agree blunk.gif Emoticon

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.

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...

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 ?

Thursday 06 October 2005 10: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 10:27:24 am

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

It was just a suggestion in order to limit the number of server requests using the ajax menu: somewhat store IDs of nodes frequently visited in the tree, and automatically load them in the menu.

Regarding the complexity of a full AJAX interface, I can only agree with you blunk.gif Emoticon As I said, it was "seeing far far ahead in the future". It would definitely require a whole new approach, and there is indeed a big risk of increased update complexity and lack of reusability. Honnestly, this is a really huge topic, and definitely worth investigation.
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.
Regarding extensions, such a feature would definitely require an AJAX library that would let developers provide a uniform implementation of the interface. Another eZ PHP Component ? happy.gif Emoticon

Thursday 06 October 2005 10: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 happy.gif Emoticon

Thursday 06 October 2005 10:34:16 am

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.

with ob_gzhandler, mod_deflate or mod_gzip you can compress the eZ publish standard output for the admin interface to 1/10 or less of the inital size. I filled a bug report a long time ago regarding this question but nobody cares.
Output compression is mandatory to have a usable admin interface over internet connection.

Thursday 06 October 2005 10: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 happy.gif Emoticon

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 blunk.gif Emoticon

Thursday 06 October 2005 11:13:36 am

IMHO, the correct way to COMPRESS the data is on Apache's level. It's not so much an eZpublish issue but one of proper Apache config.

But as said, it doesn't really solve the issues with giant pages taking ages to render in browsers (not using Firefox but Opera or Konqueror could help there but those lack support for WYSIWYG editors sad.gif Emoticon).

A more generalized way to do AJAX within eZpublish would obviously be greatly appreciated blunk.gif Emoticon

Thursday 06 October 2005 12:12:14 pm

> A more generalized way to do AJAX within eZpublish would obviously be greatly appreciated blunk.gif Emoticon

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 6:43:29 pm

@Gabriel: The menu should offcourse look like the normal menu. I just used the + and - letters for simplicity.

AJAX indeed brings some cool stuff. But what happens if the networkconnection is slow or faulty and the extra complexity really have to be considered.

On the long run, i think eZ publish will benefit from using AJAX technology, and i predict we will see some thing like this in eZ publish in the long run... Don't be shoot me mister productmanager Frederik blunk.gif Emoticon

Friday 07 October 2005 6:50:36 pm

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 blunk.gif Emoticon )

Monday 10 October 2005 8:52:46 am

No no no Kristian, the bookmark thing was not to SHOW the bookmarked items, it was to automatically load the bookmarked items blunk.gif Emoticon

The idea is just here to limit the number of requests used to load the default menu. If something is bookmarked, it is automatically loaded in the menu, that's all. Any non bookmarked stuff could still be opened by clicking your nice little pluses or arrows or whatever happy.gif Emoticon

Monday 10 October 2005 9: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 blunk.gif Emoticon

Monday 10 October 2005 3:06:35 pm

Ahh.. that makes much more sence Bertrand happy.gif Emoticon

But like the menu says: "Content structure". This means it should only show the structure, for example only folders. This is done the same way in for example Windows Explorer, which shows the folders on the left side, and the content in the right side. Thats why i think it would be better if the normal eZp installation only showed folders, and other classes that are used to group information, and not for example articles (That was a long sentance..)

Monday 10 October 2005 3:35:05 pm

Hum... this is an interesting question. One of the issues there is imho that in windows, a folder is explictely defined. In ezp, a folder is just a specific content class that happens to be a container...

Maybe only show container classes ? Maybe that would make sense...

But on the other hand content structure does say to me it's just gonna show the folders, it says to me it's gonna show the content blunk.gif Emoticon

Anyone else, opinion ?

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from