You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2005/08/13 03:45:54 UTC

[jira] Updated: (MODPYTHON-73) Using objects to create an explicit hierarchy.

     [ http://issues.apache.org/jira/browse/MODPYTHON-73?page=all ]

Graham Dumpleton updated MODPYTHON-73:
--------------------------------------

    Attachment: util.diff.txt

Attached path for this change. Why can't you attache patches when issue created. :-(

> Using objects to create an explicit hierarchy.
> ----------------------------------------------
>
>          Key: MODPYTHON-73
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-73
>      Project: mod_python
>         Type: Improvement
>   Components: publisher
>     Versions: 3.2.0
>     Reporter: Graham Dumpleton
>     Priority: Minor
>  Attachments: util.diff.txt
>
> Cut and paste of idea presented on mailing list. See:
>   http://www.mail-archive.com/python-dev@httpd.apache.org/msg00294.html
> Have a strange patch here for consideration.
> In CherryPy, one can manually construct the page hierarchy by writing:
>   cpg.root.onepage = OnePage()
>   cpg.root.otherpage = OtherPage()
>   cpg.root.some = Page()
>   cpg.root.some.page = Page()
> The closest equivalent to this in mod_python is the publisher handler,
> whereby a URL will be mapped to attributes and member functions of a
> class. One generally though has to create an actual class to encapsulate
> all the bits together.
> One can to a degree with publisher create a mapping without creating a
> proper class by using:
>   class _Mapping:
>     pass
>   def _method1():
>     return "_method1"
>   def _method2():
>     return "_method2"
>   object = _Mapping()
>   object.onepage = _method1
>   object.otherpage = _method2
> What isn't possible though without creating a real class is have a
> normal function which is called when the dummy mapping object itself
> is the target. Ie., following does not work:
>   object.__call__ = _method1
> This is because util.apply_fs_data() assumes that __call__() is always
> an object method.
> I know this is sort of an abuse of __call__(), but it does actually
> work in Python itself, just not in mod_python when URLs are mapped to
> object.
> >>> class A:
> ...   pass
> ...
> >>> def _method():
> ...   return "method"
> ...
> >>> a=A()
> >>> a.__call__ = _method
> >>>
> >>> a()
> 'method'
> Anyway, I have attached a patch which would allow this sort of thing to
> actually work within mod_python.
> I feel it could be a useful way of quickly constructing special object
> hierarchies from other functions, objects and attributes without having
> to actually create real classes.
> For example:
> def _method():
>   return "method"
> class _Mapping:
>   pass
> _subdir1 = _Mapping()
> _subdir1.__call__ = _method # .../root/subdir1
> _subdir1.page1 = _method # .../root/subdir1/page1
> _subdir1.page2 = _method # .../root/subdir1/page2
> root = _Mapping()
> root.__call__ = _method # .../root
> root.page1 = _method # .../root/page1
> root.subdir1 = _subdir1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira