Forum OpenACS Development: Re: More Dynamic List Builder defintion

Collapse
4: Re: More Dynamic List Builder defintion (response to 1)
Posted by Dave Bauer on 08/30/08 04:08 PM
Malte,

Yes I have seen contacts, and probably got some ideas from that code. This just adds the support into listbuilder so it can be reused. Assessments generic storage and contacts generic storage are very similar in the end. Of course this works with any query that requires additional joins to show additional columns.

Overall I have found that most lists are not specific to show only one object type, but they need to work on multiple tables and objects to generate all the information. In some cases where the joins can be expensive, it can help to avoid making the query too complex. In assessment this is taken to an extreme since each additional column added to the list requries a multiple column join on the content repository and assessment data storage tables. Also, the original application that inspired this code, there were possibly 100 columns that might be displayed.

Of course, the code is already documented, I'll be happy to review and make sure the documentation is complete and clear before it is added (if approved).

I have submitted a TIP see: https://openacs.org/forums/message-view?message_id=1840450

Collapse
5: Re: More Dynamic List Builder defintion (response to 4)
Posted by Malte Sussdorff on 08/30/08 05:02 PM
Hi Dave,

that is great, will look forward to the result. Just some notions to your comment.

a) The whole functionality of contacts which resided on AMS has been changed to purely use acs_object_types, acs_object_type_tables and acs_attributes in intranet-dynfields. This means, we don't have a meta storage anymore, making things much faster. It also means that we know from the database where to get the object information from (which can be multiple tables).

b) Usually, if you want to display a list then you need to at least know how parts of the list relate to other parts. Most of the time you will find, that you just have the same object_type dispersed over multiple tables. Take into account that XoDynfields is object oriented, so Users contain Person and Parties (as they inherit down the object_type hierarchy). It is still one object type though.

Another way of doing this is to have a foreign key reference. This means you link a second object (1:n relation) of a certain object type into the list. This is also handled automatically by database table inspection. So if you have a company which references a main_office_id, you can display a list of companies with main_offices automatically in the list.

Last but not least you could have a real relationship (acs_rel_type). Then instead of saying you want to display the object_type company you want to display employees (or company projects). This will return a list of the n*m matrix of companies and persons (or projects) where the end user can easily extend the table to display any column of both types. This again could be extended by the 1:n relationship mentioned above (so you could display a list of all employees along with their company and their office).

XoDynfields automatically figures out the necessary relationships and the correct joins and returns you a join and table_clause (read: where_clause and from_clause).

So, as you can see, the TIP is highly welcome as I don't have to work with that on my own anymore. But I would ask you to add a "column_clause" as well, so I can define which columns I want to retrieve (as I might have PL/SQL functions which return a value from and ID, reducing the need for me to translate in TCL the ID into the correct value).