Tables already have a delegate that is intended to providing specialized
behavior, which we might be able to use here. It would be nice if we
didn't also need additional subclasses. If and when we have a GUI
builder, the fewer the number of specialized blocks the better. It would
be unfortunate if we ended up with all of Chandler being build only from
Chandler specific blocks.
John
Alec Flett wrote:
I think we're blurring the line between a block and a view with the
Table/wxTable class. Tables are useful for sure as widget-level
blocks, but as we move forward the table summary view is going to
become more specialized.
Table should be a regular low-level block, and a new class,
TableSummaryView, should derive from it, and add capabilities like
recurrence support. This would also allow TableSummaryView and
CalendarCanvas to then both derive from sort of SummaryView mixin
which would allow for a common place for things like menu updating and
so forth.
So my propsal, in python:
class Table(Block):
... as it stands now...
class SummaryView(object):
"""
mixin class for event updating, and so forth
"""
def onRemoveUpdateUI(...):
etc...
class TableSummaryView(Table, SummaryView):
"""
provides chandler-specific behavior in the summary view -
dashboard, and so forth
"""
class CalendarCanvas(CollectionCanvas, SummaryView, ....)
"""
similar to the existing class
"""
Thoughts?
Alec
John Anderson wrote:
Hi:
I noticed that in revision 7115 you added RecurrenceDialog to Table.
On first glance it doesn't seem like all Tables should know anything
about recurrence since Tables are used in lots of situations besides
the summary view.
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
