Alec Flett wrote:
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)
Obviously there is a line beyond which we should make a specialized
block -- the Sidebar is already over that edge. Maybe the Summary will
get there someday too. But we shouldn't go there until we need to.
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.
It might make more sense to add this behavior to the AttributeEditors
instead of the 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.
All I'm suggesting is that, if possible, we should choose a design that
doesn't make a GUI builder difficult or impossible. I also don't think
the needs of a GUI builder will require drastic changes to our architecture.
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
