It would be unfortunate if we ended up with all of Chandler being
build only from Chandler specific blocks.
But ultimately, we're building chandler, we're going to need to write
chandler-specific code somewhere.
I understand the delegate option, but it seems like whats going to
happen is that as we add more and more chandler-specific behavior
(triage, etc) to the table summary view, we're going to keep having to
add more and more hooks to call the delegate to the base Table class, in
order to delegate this application-specific behavior. Its the same thing
that happened with the sidebar, and you yourself moved that to
main/view/SideBar.py. (and I think that was the right decision)
My concern with heading down the delegate path is that we're going to
have to constantly complicate the Table class to make the delegate be
able to handle more and more - this adds complexity to both the Table
class and its delegate.
For example, Jeffrey's recurrence dialog has to be hooked up when we
change attributes of an item. So to use the delegate, it seems like we'd
have to add code to Table to delegate attribute setting, and then add
code tot he chandler-specific delegate to hook up the recurrence dialog.
If we just derive from Table (or contain it) then the complexity falls
almost entirely to the subclass of Table.
Further, I'd like to address this:
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.
We don't have a GUI builder. Even if we did, there would always be a
need for handling subclasses of existing blocks - I think that would be
a requirement for the actual use of a GUI builder.
That said, I don't foresee any GUI builder springing into existence
anytime soon. Too often we use this "if/when we have a GUI builder..."
as an argument towards one design or another, and it gets used to trump
any other architectural arguments. Lets deal with what we have now.
Alec
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
