Jean-Marc Orliaguet a écrit : > > the best way to solve the different use cases is to have different types > of providers available (persistent, persistent+per user, persistent+per > folder, ...) and associate them to the various panels. Everything that > goes into the dashboard should be "per user" since window states and > locations are to be stored per user too (and not just the widget settings).
Ok. > as for the persistence part, I have no direct solution, except that it > can be based on the existing placeful registry, or any other layer that > could manage persistence in the future (NXRuntime?, ...). It can be done > using a low-level access to a database too. I don't know too much about > the nuxeo road-map regarding a possible API for storing persistent > settings. I'm open to suggestions. > > when it comes to creating the actual widgets (SearchService, ...) you > only need to think about what will be configurable by the user. The rest > is done on the server - typically by a servlet. The configurable > settings are combined together as URL parameters that will be used to > retrieve the correct data. Every field data has to be encoded as a > string, so you can't have a document model or a query model object, > unless it is uniquely identifiable. RepostoryName + IdRef is enough to identify a persistent document model, and query model are registered under a unique id as well. However the parameters stored in the document model of stateful query models will have to use a nuxeo specific server-side edit form instead of the generic widget editing form. > then the dashboard view should be associated with the 'web-widgets' view > mode, I suppose, to allow users to directly modify the widgets on the > dashboard page. Yes. The "add new widget" left column should be folded by default though. -- Olivier _______________________________________________ ECM mailing list [email protected] http://lists.nuxeo.com/mailman/listinfo/ecm
