durusmail: qp: Re: convention for 'local_ui' in qp?
convention for 'local_ui' in qp?
2005-11-06
2005-11-06
Re: convention for 'local_ui' in qp?
2005-11-07
2005-11-07
2005-11-07
2005-11-07
2005-11-07
2005-11-07
Re: convention for 'local_ui' in qp?
David Binger
2005-11-07
On Nov 6, 2005, at 8:08 PM, Michael Watkins wrote:

> * Michael Watkins wrote [2005-11-06 16:13:48 -0800]:
>> Still, I wonder if a bag holder class Local might be best included in
>> Publisher, and a get_local() fn added to qp.pub.common.
>
> Maybe if qp.pub.common grew a get_local, or if one knew it would at
> some point
> ;-) ...
>
> def get_local():
>     return get_publisher().get_local()
>
> ..... then the actual implementation details could wait.
>
> class Publisher:
>
>     local_is = Local
>
>     # ...
>
>     def get_local(self):
>         if not hasattr(self, 'local'):
>             self.local = Local()
>         return self.local
>
> My own use of local in Dulcinea was confined to the usual
> local_ui.header/footer (which appears to be the overwhelming use of
> same in
> Dulcinea overall), plus accessing a few other callables
> (format_date), and
> finally, mappings to various durus mappings (local.get_users - now
> qp.pub.common.get_users()) for Dulcinea components (get_*_db) and
> my own.
>
> At this point it doesn't appear that a very complex mechanism is
> needed, just
> a mechanism...

So why not just add format_date(), format_user(), etc. to the site-
specific
publisher class?  I don't see the value of the extra level of
indirection here,
since each site is already definitely including a customized subclass of
Publisher.

reply