durusmail: qp: Twisted - Was: Re: Quixote, QP, the future...?
Twisted - Was: Re: Quixote, QP, the future...?
2006-04-09
2006-04-09
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-10
2006-04-12
2006-04-12
2006-04-13
2006-04-13
2006-04-13
2006-04-13
2006-04-14
2006-04-14
2006-04-15
2006-04-16
2006-04-16
Twisted - Was: Re: Quixote, QP, the future...?
mario ruggier
2006-04-12
On Apr 10, 2006, at 8:00 PM, David Binger wrote:
>>
>> Does this make the case for a Site subclass instantiated from
>> slash.py?
>
> That path gets tangled pretty quickly.
> The Site class is what qp depends on to find slash.py.

Do I understand correctly that all it needs is to know
sites_package_name?
To be then able to do equivalent of:
import ..slash.SitePublisher

> If anyone wants all of their apps to run with a different Site class, I
> think they should change the import in (a copy of) the bin/qp file.

Would it be a good thing to just make this standard convention, i.e.
to just get the Site class from the qp.sites init if one is specified?
Thus, replacing in qp/bin

from qp.lib.site import Site

with:

try:
     from qp.sites import Site
except ImportError:
     from qp.lib.site import Site

Here the sites_package_name is hardwired...
But maybe this package name is the one thing that should not be
customizable.

> If anyone really wants a particular QP publisher to run with a
> different site class,
> then I'd suggest putting "self.site.__class__ = MySiteClass" in the
> SitePublisher.__init__().

This starts to get convoluted doesn't it? I mean, the Publisher is
already initialized by a an instance of the qp standard Site class, and
that instance attached as the .site value. To reset this midstream
seems to invite for some confusion.

mario

reply