On Dec 14, 2005, at 8:00 PM, David Binger wrote:
> On Dec 14, 2005, at 12:13 PM, mario ruggier wrote:

>> The publisher gets initialised in Site.get_publisher(), which is
>> nicely enough isolated. However, I cannot just subclass Site and
>> override this method, as the actual site instances themselves are
>> instantiated in the class method Site.get_sites().
>
> Why would you want to override Site.get_publisher()?
> QP expects you to subclass Publisher, but not Site.
> What would be the objective of subclassing Site?

I can subclass Publisher, but I have no control on the parameters that
are passed to its constructor, as these are hardwired in
Site.get_publisher(). I have found no other reason to subclass Site (so
the separation of interests between Site and Publisher does actually
seem to hold up very nicely). And just to get to the Publisher's init
call definitely seems like it should not be a good enough reason to
subclass Site.

But actually, come to think of it, I can much more simply set any other
attribute I'd want to, directly from within the Publisher's init... I
just have to get used to the hardwired constructor signature.

>> Incidentally, I was initially a little surprised with a class method,
>> innocuously called get_site(), that actually creates an instance of
>> its own type for every qp_site directory it finds. Maybe
>> create_sites() would be a more indicative name.
>
> The sites, conceptually, exist all the time in a qp application.  They
> are hard-wired
> by the file system in the qp.sites package.  When you call
> get_sites(), you are, in
> my thinking, just asking for the sites that already exist.  The
> creation of instances
> representing the sites is (supposed to be) a trivial part of the
> method behavior,
> not the main idea.

OK, I see. That does make sense...

mario