On Dec 2, 2:09 pm, Chris Nelson <[email protected]> wrote:
> On 12/01/2011 05:02 PM, Remy Blank wrote:
>
> > osimons wrote:
> > ...
> > There's actually nothing wrong with using inheritance with components,
> > except for two things:
>
> > - Only one component in a "branch" of inheritance should be enabled
> > (i.e. you should never enable both parent and child).
>
> Why is that? My plan was to have one of the classes selected with an
> ExtensionOption. Doesn't that require them all to be active? Can't I
> do that? (Or am I confusing Interface with Component?)
I may not have explained myself clearly. I'm not discouraging
subclassing (even though I'm no fan and try to avoid it), but I was
suggesting not to subclass Component type classes as they come with
aspects and should not be part of the call chains if the point is to
override their behavior. Try to use a MixIn class instead as it will
be cleaner - not least if everything also requires the necessary
enable/disable configuration in trac.ini to make the sum of parts work
correctly. Using a MixIn also means that the classes don't have to be
feature complete components as they will never be called directly by
Trac.
So;
class SchedulerMixIn(object):
... shared methods ...
class SchedulerOne(Component, SchedulerMixIn):
implements(...)
... implementations...
class SchedulerTwo(Component, SchedulerMixIn):
implements(...)
... implementations...
Anyway, my wording was ment as advice for best-practice for keeping a
clean plugin architecture. It was not based on what you can do
technically. Do what suits you and the others that work with your
code. Your question and our answers are colored by personal preference
and coding style.
:::simon
--
You received this message because you are subscribed to the Google Groups "Trac
Users" 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/trac-users?hl=en.
