Jean-Marc Orliaguet a écrit : > > Hi, > > I would say that the "difficulty" in implementing such a functionality > is not in the rendering engine itself. > It is easy already to define a special rendering engine in XML with an > extra "drag-and-drop" filter that manages the position of the fragments. > Then it would be possible already to associate this engine to the > dashboard view id. The only real issue is rather where to store to > information about the fragments (position, state...). > > Let us say that for the sake of simplicity we store the information in a > cookie and that the fragments are pre-defined in the theme itself (i.e > they exist in the theme already and the user has the freedom to > manipulate them, but not to create new ones). > > A neat solution would be to have a filter that does a pre-transformation > on the cells containing fragments by reordering them before they get > rendered, for instance a: > > 1 -> 3 > 2 -> 2 > 3 -> 1 > > 1 -> fold > 2 -> minimize
Yes that was the kind of things I had in mind. > The rendering engine works on a copy of the theme already, and if it's > not the case I should fix this, to make sure that rendered themes are > not "mutable" w.r.t transformation filters - if you see what I mean. > > What kind of persistence are you thinking of: client-side or server-side? I would say cookie-based in the first place and then study the server side persistence on a medium term. Client-side is simpler as far as security and right management are concerned as it does not need a dedicated persistent container on the server. -- Olivier _______________________________________________ ECM mailing list [email protected] http://lists.nuxeo.com/mailman/listinfo/ecm
