Olivier Grisel wrote:
> Jean-Marc Orliaguet a écrit :
>   
>> Hi,
>>
>> Here is a preview of the web widget implementation for nuxeo5 / nxthemes
>>
>> http://www.medic.chalmers.se/~jmo/nuxeo5/nxthemes-2007-11-15.html
>>     
>
> Hi JMO, amazing work!
>
> This will be of a great tool to refactor the current dashboard theme page. As
> for the persistent widget providers what do you have in mind?
>
> The dashboard has currently 2 main types of page fragments, those based on
> Search Service queries (with query models) and those based on Workflow engine
> task or process listings.
>
> Worklow based fragments are functionnally quite static, ie, there is no need 
> to
> store per-widget persistent parameters.
>
> As for the SearchService-based fragments they could be factorised as a single
> configurable widget type with the following parameters:
>
>  - a title
>  - the querymodel used to build the query
>  - the document model instance used to store the stateful attributes of the
> querymodel (when it's not stateless)
>  - the list of columns to display in the result (and the default sorting 
> params)
>
> The natural way to store the document model is to use a dedicated folder of 
> the
> core  (maybe reuse the UserData folders?). For the remaining parameters, 
> title,
> querymodel id and columns, I don't really have any opinion yet.
>
>   

Hi,

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

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.

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.

best
/JM
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm

Reply via email to