self.site.__class__ patching is probably not going to work. The patch
up doesn't happen until get_publisher on the Site happens to be
called which normally doesn't happen until Site.start_web has already
been entered. If you add a self.get_publisher() call to Site.__init__
to force it earlier, then "assert get_publisher().get_site().get_name
() == self.get_name()" in Site.get_publisher blows up via
Site.get_sites since Site.get_publisher assumes only one publisher
being referenced per process.

I threw in the towel on that.

Generally speaking, I'm not convinced that the method interface to
Site isn't already generic enough to be used by many types of Site
implementations. In fact, I think that interface should be *required*
of all Site implementations. If so, then bin/qp and for instance bin/
tqp should really only differ in one line of functionality: an import
statement. However, I also believe that the Site to use should not be
chosen by the management tool. That decision should be in the
implementation; i.e. slash.qpy.

Once you have made that decision, then I think moving run_web to the
Publisher just forces unnecessary work on the developer. start_web in
the customized site already knows all the details of what needs to be
done to start a twisted web application. Also, making this choice
conveniently gets rid of the issue of start_web in the Site and
run_web in the Publisher both needing to coordinate whether or not to
behave as a standalone application.

So, here's what I've got working. I changed get_sites to the following:

     def get_sites(klass):
         """() -> {name:str : site:Site}
         Note that this is a method of the class.
         It returns an index of all of the installed sites.
         """
         sites_package= import_object(klass.sites_package_name)
         sites_directory = sites_package.__path__[0]
         names = [name
                  for name in listdir(sites_directory)
                  if (isdir(join(sites_directory, name))
                      and '.' not in name)]
         sites = {}
         for name in names:
             m = import_object("%s.%s.slash" %
(klass.sites_package_name, name))
             if hasattr(m, "Site"):
                 sites[name] = m.Site(name)
             else:
                 sites[name] = Site(name)

         return sites

And I have this in slash.qpy:

....
from qp.hub.twistedhub import TwistedSite

Site = TwistedSite

class SitePublisher (Publisher):

     configuration = dict(
         http_address=('', 8001),
         )
....

I also have a suitable twistedhub.py which has a TwistedSite class
with just one method so far: a twisted specific start_web. I still
have more integration and cleanup to do, but this basic approach is
working. At least "bin/qp -s echo start" works and the demo is
reachable from a web browser.

Dave

On Apr 12, 2006, at 8:12 AM, David Binger wrote:

>
> On Apr 12, 2006, at 3:09 AM, mario ruggier wrote:
>
>> [comments on customizing the Site]
>
> In my mind, the Site class captures all of the firm expectations
> of your site management tool.  In a very real sense, it *is* the
> site management tool.  The qp/bin script just gives it command
> line operability.  The main difference between QP and Quixote
> is that QP provides one firm set of decisions about how
> sites are configured and arranged.  The QP Site class
> implements this set of decisions.
>
> If you are using a different Site class, you are using a
> different command line tool.  I recognize that that might
> be necessary for some people, but I don't see a compelling
> reason for the qp/bin tool to try to dynamically adapt to every
> possible situation.
>
> Still, if you really must go this way, with only minor changes
> in the Site class, you can change the Site import in a copy
> of the bin/qp script, and there is a good chance your script
> will work.
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> QP mailing list
> QP@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/qp