Ticket #1421 (closed defect: fixed)

Opened 14 years ago

Last modified 14 years ago

dynamic treeview refresh mechanism

Reported by: tziade Owned by: tziade
Priority: P1 Milestone: CPS 3.4.0
Component: CPSPortlets Version: TRUNK
Severity: major Keywords:
Cc:

Description

the dynamic treeview needs to be automaticaly, asynchronously, refreshed when elements are moved with the drag and drop feature

Attachments

treeview.png Download (989 bytes) - added by jmorliaguet 14 years ago.
treeview example

Change History

comment:1 Changed 14 years ago by tziade

  • Owner changed from jmorliaguet to tziade

comment:2 Changed 14 years ago by jmorliaguet

FYI, this is not trivial at all, but I'm working on something similar: a client-side tree view widget that uses the server as a web service.

Updates are model-driven, i.e. the view gets updated as soon as the tree data changes (there is no need to refresh the view periodically).

it's still very experimental, I need some more infrastructure to handle toggle events in the template (e.g. using something like 'behaviour.js'), but there should be something ready before next week.

comment:3 Changed 14 years ago by tziade

  • Status changed from new to closed
  • Resolution set to fixed

for JMO: ok very interesting, but i'm not sure to understand how your treeview gets refreshed differently to what's implemented here. AFAIK, a web service is nothing more that a server method, so pretty similar to a 'regular' call over Zope. Now for Behaviour, IIRC it's a way to select the nodes and apply unobtrusive javascript to the dom, and that's pretty much what's done here.

-> CPS gets refresh through an client-side observer pattern that triggers a refresh of any portlet on a given event.

Maybe you could detail how you prototype works by email, so we can join forces to come up with a the greatest possible treeview :) ?

for the record: done in

[33137] [33133] [32959] [32960] [32947]

comment:4 Changed 14 years ago by jmorliaguet

I'm going to check in some code soon (nothing functional but enough to get any idea).

the main difference is that the HTML of the treeview is generated on the client (using CTAL) so the server is only called to get new data (not for rendering HTML), that's what I mean by "web service" as opposed to a "web server that generates HTML". That's why something like Behaviour.js is needed not only for esthetical reasons but because the CTAL template does not have access to the information about the controller, or the view. It knows only about the model's data.

then it's model-driven. It's the model that needs to get updated, not the view. To refresh the view(s) only the data in the model need to be modified in a way or another.

if 5 portlets observe a same model that changes its internal state after some drag-and-drop event has occured, all 5 portlet will get refreshed. The drag-and-drop control logic need not know anything about which portlets need to be refreshed.

I'm not sure it would work in CPS right now though...

comment:5 Changed 14 years ago by tziade

<<<<<< I'm going to check in some code soon (nothing functional but enough to get any idea). <<<<<<

Maybe we could work together on what's already existing to enhance it ? :) A CTAL interpreter could be a nice thing

<<<<<<< the main difference is that the HTML of the treeview is generated on the client (using CTAL) so the server is only called to get new data (not for rendering HTML), that's what I mean by "web service" as opposed to a "web server that generates HTML". That's why something like Behaviour.js is needed not only for esthetical reasons but because the CTAL template does not have access to the information about the controller, or the view. It knows only about the model's data. <<<<<<<

yes CTAL is very interesting, pretty similiar to xml transofrmations in xmltree. Now the tree here just need to get new nodes that are simples <li> but it could have a local transform for sure.

<<<<<<< if 5 portlets observe a same model that changes its internal state after some drag-and-drop event has occured, all 5 portlet will get refreshed. The drag-and-drop control logic need not know anything about which portlets need to be refreshed.

I'm not sure it would work in CPS right now though... <<<<<<<

Well, that's exactly what i have done if you look carefully ;)

i have a event manager, portlets registers as observers for 'drop' events in the manager, and the drop trigg the event.

comment:6 Changed 14 years ago by tziade

<< i have a event manager, portlets registers as observers for 'drop' events in the manager, and the drop trigg the event. <<

sorry, to be clearer you can change here the "...'drop' event.." to "...'model' event..." so you have the same idea: all elements observe over a model changes (except the model here is on server side)

comment:7 Changed 14 years ago by jmorliaguet

here is the code:  http://svn.z3lab.org/trac/z3lab/browser/cpsskins/branches/jmo-perspectives/ui/framework/tests/zope3/functional/treeview/

it is far from finished, but the tree is at least getting rendered on the client.

Changed 14 years ago by jmorliaguet

treeview example

comment:8 Changed 14 years ago by tziade

cool thanks a lot, i am going to take a look i've thaught again about the model driven approach with data kept on the client side, it could be awesome too, as long as we can manage to do it gracefully and with some , i'll try to blog about it to explain in details my point of view about it and why i didn't do it this way. i hope it'll help us to get the best solutions

comment:9 Changed 14 years ago by jmorliaguet

it is possible to do graceful degradation, because actually there is no degradation (the opposite approach is taken: the HTML widget is replaced by the Ajax widget when the page is parsed):

this is easy since the rendering occurs on the client.

for an example, see:  http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/functional/cpsskins_progressive_enhancement.html

All this is still very experimental, but the model-driven approach basically means that you always update the model and never refresh the views directly. For instance the controller does not do: refreshPortlet(..) but it does: model.setData({'trigger-refresh':1}). Then the model tells the view(s) to get updated and the controller does not need to know about it.

It also means that the model must be accessible for the controller directly, i.e. it must reside on the client.

Note: See TracTickets for help on using tickets.