I would like to have a dataseq but not commit to a specific data-class at 
instantiation time because I intent to feed it with objects of different 
effective class but that all will specialize a specific set of methods, 
which I want to govern the column structure. Sort of having the underlying 
dataset of the dataseq widget have a sequence of objects that are not of a 
specific class but implement a specific "accessor" interface. Example:
I have "company" and "person" which all inherit from "resource". There are 
for example  "phone" and "email" slots in resource class that get inherited 
by both classes, but there are also some slots different in the 2 classes, 
that are also accessable through a common interface. Example: Company has a 
"headquarters" slot and Person has a "home-address" slot that are both 
accessible through a "address-of" method that specializes on both subclasses 
calling the apropriate slot accessor. So I want a dataseq where the columns 
will each be either a slots accessor of the resource class, or methods 
accepting a resource class and delegating to the appropriate slot accessor 
based on the real class of the object. So the resulting columns structure in 
the dataseq is known at instantiation time, and the contained data, instead 
of (or in addition to) slot-data,is the result of predefined method calls.

I just want a general direction: The first thing that came to mind is to 
subclass the dataseq and hack its rendering methods and dataseq-data 
accessing plumping, but I want to make sure that there is isnt any existing 
best practice, pattern, code or contrib in weblocks for those purposes, 
especially the views subsystem which I am not so familiar with. For the 
specific need I described, do I stand a chance with custom views or I would 
be much trouble that could better go directly in  custom widget? Note that I 
won't need to directly edit the contents of the dataseq, just display them. 
For editing I will click and load Leslie's contrib form-widget.

So, any comments?         

-- 
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en.

Reply via email to