Forum OpenACS Development: Saving List Views (add to core?)

Collapse
1: Saving List Views (add to core?)
Posted by Dave Bauer on 08/09/07 04:32 PM
I am working on a project to save the view of a list builder list.

THis will include choosen filters, ordering, grouping, and displayed columns (we are also adding ability to show/hide columns).

Right now all the settings for the filters etc, can be saved in a tcl list in a session property.

So the persistently save the view and name it, we need to save it in the database. We can just use a text/clob to store the list and rebuild it from the database.

The question is, how do I implement this table, what package should it go in etc? Is this a feature we should add to core OpenACS/acs-templating?

Collapse
2: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/09/07 04:34 PM
We also need to save the URL of the list so we know which list the view belongs to.
Collapse
3: Re: Saving List Views (add to core?) (response to 1)
Posted by Malte Sussdorff on 08/09/07 05:28 PM
From my point of view it can go into core. I would love to see this enhanced by a "search_view_p" setting, which, if set to true, brings up a search screen where you can select from all the filters which do not have a preset value.

I think all the values can be stored in a list where each "attribute" like filter, ordering aso. gets it's own column in the table. For identification you would name the row by the name of the list, prepending the package key?

Make sure that you use the CR for this, so we can have changes recorded on a saved view. We also need the permissions on it and I would love to categories these views.

Collapse
4: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/09/07 05:36 PM
It just seems strange to add a new content type in the acs-templating package. I think using the CR makes sense. I am thinking we'll just store a huge tcl list in the content column since there really isn't any way to make a data model for filters. For example, one applicaiton filters on all the questions in an assessment, so there is no way to create a column for each filter since they are unique per list.
Collapse
5: Re: Saving List Views (add to core?) (response to 4)
Posted by Malte Sussdorff on 08/09/07 07:17 PM
You could do it this way, but I would still prefer the settings for orderby and the like to be in separate columns so not to parse the large list in the content block every time. Filters is obviously a list of lists (filter name, filter value), but having a list of list of lists is a little bit too listy for make liking.

Why does it feel strange to add a new content type ?

Collapse
6: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/09/07 07:37 PM
Malte, maybe there is a way to save each in a seperate column , but it seems like overkill since the session level property is saved as a list (of lists of lists?) that needs to be parsed anyway. Maybe there should be seperate session properties too. Anyway thats an implementation level detail we can work out as we go.

My point is that acs-templating does not seem to rely on the content repository, although they are both part of core, in general there isn't any database code in the templating package.

Collapse
7: Re: Saving List Views (add to core?) (response to 6)
Posted by Malte Sussdorff on 08/10/07 09:23 AM
Ah, okay, but you could rely easily and you do not have to have a SQL directory if you call content::type::new (unless I misunderstood the implementation, but it should create the extension table for you, shouldn't it). Though now we are getting into the area of "is it a best practice to create the tables in the SQL statement instead of only calling the TCL methods".

I agree we need to do some parsing, but we have a database, so why not use it? Parsing should be left to the situations where we do not know which columns we have, but in this scenario we know at least some of them.

Collapse
8: Re: Saving List Views (add to core?) (response to 6)
Posted by Tom Jackson on 08/10/07 06:30 PM
Dave,

What does the data look like that you are storing? This sounds like a state store/restore operation.

Collapse
9: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/10/07 06:36 PM
Hmmm its a list of key value pairs same as your usualy tcl array style list.

We derive the list of applied filters from the names of all the filters that exist in the list. Luckily orderby, groupby, etc are all implemented as filters so we get consistent handling for all these items.

Collapse
10: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/10/07 08:57 PM
Hmmm.

Interestingly listbuilder has half this feature already (not the saving part, but defining different views.)

The -formats switch does allow you to define the attributes for a single format or view. I am not sure how flexible this is, but definitely something I will keep in mind when I am working on this.

Collapse
11: Re: Saving List Views (add to core?) (response to 1)
Posted by Dave Bauer on 08/30/07 07:06 PM
Here is a design question.

To save a list view, I'd like to have a central location utility script that can save the current view.

I am not sure if this is possible since each filter form is based on the list that was generated.

Perhaps it makes more sense to create a save action in list builder and require the template script to call save_view or something which can poke around in the caller's scope and figure out the appropriate data to save.

Ok I think I answered my question. Any comments?