Re: [Zope3-Users] Re: Get classes implementing Interface
Florian Lindner wrote: Am Freitag, 30. Dezember 2005 17:45 schrieb Jim Fulton: Philipp von Weitershausen wrote: Florian Lindner wrote: my first use case is that I want to enhance the HomefolderManager to make it possible to select something else than a Folder to be created automatically. Right now I have forked a version of the HomefolderManager and just changed in the code. But I would like to have a more generic solution and I'll also commit it back to the trunk. For that I want all classes implementing IContainer (and IContentType ?) and let the user select on in the configuration dialog of the HomefolderManager. More use caess probably show up in my project later, but nothing fixed at this time. So what you want is to create objects. Classes are just an implementation detail to creating objects :). Factories create objects, whether they're from a class is immaterial. So, what you want is not a list of classes but a list of factories that can create IContainers. This is possible by using zapi.getUtilitiesFor(IFactory) and then checking each factory's getInterfaces() method whether IContainer is a part of the returned result. I would probably base an implementation of all on the UtilityVocabulary. I'll also note that the use case is also directly addressed through containment constraints. You can say that a container should only contain objects of some given types and you will get just those types in the add list. But the HomeFolderManager is not a container itself it's just a utility that creates container upon requests. And I want to make choosable which container to create. Or do I misunderstand you? I missunderstood you. I'm not familiar with HomeFolderManager. In any case, the approach taken for containment constraints, which Philipp sketched above, should be applicable. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Zope3 build error
Just in case anyone else runs into this problem, the solution is to install python-devel (might be called python-dev for non SuSE distros). Charles On Thursday 29 December 2005 4:01 pm, cmire wrote: > I'm getting an error when I run make on Zope 3.1.0. The system is running > SuSE 10.0, Python 2.4.1 (default with SuSE distro), gcc version 4.0.2 > 20050901 (prerelease) (SUSE Linux), kernel 2.6.13-15. I am running make as > the local user, not root. > > [EMAIL PROTECTED]:~/Zope-3.1.0> make > /usr/bin/python install.py -q build > Traceback (most recent call last): > File "install.py", line 22, in ? > import zpkgsetup.setup > File "/home/cmire/Zope-3.1.0/Support/zpkgsetup/setup.py", line 34, in ? > from distutils.cmd import Command > ImportError: No module named distutils.cmd > make: *** [build] Error 1 > > Here is line 34 of the setup.py file referenced in the error: > > from distutils.cmd import Command > > > I googled for this error, but only got two hits back (in French). It > appears that situation was due to some issues with gcc 3.0.2 for Debian. > > Thanks, > Charles Mire > ___ > Zope3-users mailing list > Zope3-users@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Specialized URL traversal.. Best way?
Jeff Shell wrote: > [snip] > > I was wondering - is this the best way to do this? Is there a better > recipe floating around out there? I appreciate Zope's direct-to-object > URL publishing (been using it since '97!), but custom URL maps past a > certain object like a view seem to be quite tricky, whereas Django and > generic toolkits like Routes are specializing in ways of managing > custom URL maps. I know there are a few places where one can take over > this process, but it's not obvious when and how to use them, or which > to use. BeforeTraversal event? publishTraverse? ITraversable? > ITraversing? Ultimately I'd like to put a couple of views into the > root of my app that can do something akin to Django's url_dispatch: > > http://www.djangoproject.com/documentation/url_dispatch/ > > where a set of patterns and a name are used to allow for various > dynamic queries. The name would be used to look up a component to > respond to the matched items in the path. It wouldn't interfere with > any other traversal (ie - wouldn't replace the default way of doing > it). Doing it from a browser view seems safest, since this is almost > exclusively about keeping nice URLs for web browsing. I just want to > know the best place to plug in. I don't have an answer, but I am also hoping to get some advice on the best way to get what in a Z2 PythonScript is called 'traverse_subpath'. Chris Withers and I were both asking about this back on Dec 15 in the "What's the rationale of @@?" thread (http://mail.zope.org/pipermail/zope3-users/2005-December/001684.html), but I didn't see an answer. Still haven't figured it out for myself, still hoping for some help. -- Wade Leftwich Ithaca, NY ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Get classes implementing Interface
Oops. It didn't seem to provide the code. Ahhh, GMail. Not even you
can convince me that web based mail is going to replace real
clients... And if there are multiple copies of this message, I
apologize.
from zope.interface import Interface, implements
from zope.app import zapi
from zope.event import notify
from zope.publisher.interfaces.browser import IDefaultBrowserLayer
from zope.app.container.interfaces import IAdding
from zope.app.event.objectevent import ObjectCreatedEvent
from zope.app.publisher.browser import BrowserView
from zope.app.publisher.browser.interfaces import IBrowserView
class IHomeFolderableFolder(Interface):
""" Marker interface for home folderable folders """
class HomeFolderableFoldersAddView(BrowserView):
"""
Note - this particular implementation is for an IAdding view. But adding
without IAdding is not too difficult on its own.
"""
implements(IBrowserView)
zapi.adapts(IAdding, IDefaultBrowserLayer)
def addableContainers(self):
"""
Returns a sequence of mappings with the keys ``name``, ``title``, and
``description``. ``name`` refers to the factory name which can be used
to create the chosen container when the form is submitted.
"""
addable = [
{'name': name, 'title': fact.title,'description': fact.description}
for name, fact in zapi.getFactoriesFor(IHomeFolderableFolder)
if fact.title
]
addable.sort(key=lambda x:x['title'])
return addable
def action(self):
"""
The form submission action. Looks for the factory identifier in the
request by the name ``factory``, and calls self.createAndAdd(factory)
with that value.
"""
factory = self.request.form.get('factory', '')
if not factory:
# report error here
return u"" # redirect back to form
self.createAndAdd(factory)
return self.request.response.redirect(self.nextURL())
def createAndAdd(self, factory):
container = zapi.createObject(factory)
notify(ObjectCreatedEvent(container))
# The parent of this view is IAdding, and it will actually add the
# content to the container. If not used in an IAdding situation,
# provide your own way of checking constraints, choosing a name, and
# adding the object to the place it needs to go.
container = self.context.add(container)
# Do anything else needed here...
return container
def nextURL(self):
# This just dispatches to the IAdding view's nextURL method...
return self.context.nextURL()
> Well first (and I apologize if this has been mentioned before),
> 'containers' are a more abstract notion while 'folders' are more
> concrete. A message or document that allows comments might be a
> container, but it's not something that you'd see in the ZMI or any
> content management type interface as a folder. You'd see it as an
> article.
>
> Something that's "Folderish" (to drag up an old term) will probably
> have a folder icon, will probably (but not necessarily) will have
> sub-folders, will have a view to manage its contents, and so on.
>
> It's important to keep these concepts distinct. In our content
> management system, we have a lot of containers. Due to a lack of
> understanding on my part about when I really wanted a generic
> container versus when I wanted a folder, we had some behavioral issues
> in our code at times because generic views were being applied to the
> wrong thing. During a big refactoring sweep I just completed, I
> separated these concerns completely and made a specific marker
> interface, 'IFolderishContainer' (ahh, memories again of
> _isPrincipiaFolderish ;) that classes or interfaces had to
> _explicitly_ declare support for. I made the common Folder class that
> we were using taboo for subclassing unless one really meant to take on
> all of the responsibilities of that Folder (user interface support for
> reordering, navigation menu building, and so on). And that folder
> class, itself, does not subclass from zope.app.folder.Folder since I
> didn't want these folders to be potential site managers.
>
> So then a photo gallery or jobs folder would just declare support for
> that interface, typically in ZCML. Then they could selectively choose
> what other capabilities they wanted. And that's how we separate
> Folders from other kinds of Containers.
>
> I think that was some of the earlier questions in this thread - how to
> tell if a container is really folderish versus a more generic
> container. In the closed world of our custom applications, this is how
> I solved the problem after some painful lessons along the way.
>
> Using marker interfaces like this has been awfully helpful. I use it
> in another situation where I have a single "addMenuItem" item that
> uses a view that lists all factories that declare support for a couple
> of specifi
Re: [Zope3-Users] Re: Get classes implementing Interface
On 12/30/05, Florian Lindner <[EMAIL PROTECTED]> wrote: > Am Freitag, 30. Dezember 2005 17:45 schrieb Jim Fulton: > > Philipp von Weitershausen wrote: > > > So, what you want is not a list of classes but a list of factories that > > > can create IContainers. This is possible by using > > > zapi.getUtilitiesFor(IFactory) and then checking each factory's > > > getInterfaces() method whether IContainer is a part of the returned > > > result. I would probably base an implementation of all on the > > > UtilityVocabulary. > > > > I'll also note that the use case is also directly addressed through > > containment constraints. You can say that a container > > should only contain objects of some given types and you will get > > just those types in the add list. > > But the HomeFolderManager is not a container itself it's just a utility that > creates container upon requests. And I want to make choosable which container > to create. Or do I misunderstand you? Well first (and I apologize if this has been mentioned before), 'containers' are a more abstract notion while 'folders' are more concrete. A message or document that allows comments might be a container, but it's not something that you'd see in the ZMI or any content management type interface as a folder. You'd see it as an article. Something that's "Folderish" (to drag up an old term) will probably have a folder icon, will probably (but not necessarily) will have sub-folders, will have a view to manage its contents, and so on. It's important to keep these concepts distinct. In our content management system, we have a lot of containers. Due to a lack of understanding on my part about when I really wanted a generic container versus when I wanted a folder, we had some behavioral issues in our code at times because generic views were being applied to the wrong thing. During a big refactoring sweep I just completed, I separated these concerns completely and made a specific marker interface, 'IFolderishContainer' (ahh, memories again of _isPrincipiaFolderish ;) that classes or interfaces had to _explicitly_ declare support for. I made the common Folder class that we were using taboo for subclassing unless one really meant to take on all of the responsibilities of that Folder (user interface support for reordering, navigation menu building, and so on). And that folder class, itself, does not subclass from zope.app.folder.Folder since I didn't want these folders to be potential site managers. So then a photo gallery or jobs folder would just declare support for that interface, typically in ZCML. Then they could selectively choose what other capabilities they wanted. And that's how we separate Folders from other kinds of Containers. I think that was some of the earlier questions in this thread - how to tell if a container is really folderish versus a more generic container. In the closed world of our custom applications, this is how I solved the problem after some painful lessons along the way. Using marker interfaces like this has been awfully helpful. I use it in another situation where I have a single "addMenuItem" item that uses a view that lists all factories that declare support for a couple of specific interfaces. Something like this could probably help you too if this is what you mean by providing a choice as to what folders / containers can be created. This provides data to a template via the 'addableContainers' method which just looks for factories for the IHomeFolderableContainer faux interface I made up here. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Get classes implementing Interface
Am Freitag, 30. Dezember 2005 17:45 schrieb Jim Fulton: > Philipp von Weitershausen wrote: > > Florian Lindner wrote: > >>my first use case is that I want to enhance the HomefolderManager to make > >> it possible to select something else than a Folder to be created > >> automatically. Right now I have forked a version of the > >> HomefolderManager and just changed in the code. But I would like to have > >> a more generic solution and I'll also commit it back to the trunk. > >>For that I want all classes implementing IContainer (and IContentType ?) > >> and let the user select on in the configuration dialog of the > >> HomefolderManager. More use caess probably show up in my project later, > >> but nothing fixed at this time. > > > > So what you want is to create objects. Classes are just an > > implementation detail to creating objects :). Factories create objects, > > whether they're from a class is immaterial. > > > > So, what you want is not a list of classes but a list of factories that > > can create IContainers. This is possible by using > > zapi.getUtilitiesFor(IFactory) and then checking each factory's > > getInterfaces() method whether IContainer is a part of the returned > > result. I would probably base an implementation of all on the > > UtilityVocabulary. > > I'll also note that the use case is also directly addressed through > containment constraints. You can say that a container > should only contain objects of some given types and you will get > just those types in the add list. But the HomeFolderManager is not a container itself it's just a utility that creates container upon requests. And I want to make choosable which container to create. Or do I misunderstand you? Florian ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Get classes implementing Interface
Philipp von Weitershausen wrote: Florian Lindner wrote: my first use case is that I want to enhance the HomefolderManager to make it possible to select something else than a Folder to be created automatically. Right now I have forked a version of the HomefolderManager and just changed in the code. But I would like to have a more generic solution and I'll also commit it back to the trunk. For that I want all classes implementing IContainer (and IContentType ?) and let the user select on in the configuration dialog of the HomefolderManager. More use caess probably show up in my project later, but nothing fixed at this time. So what you want is to create objects. Classes are just an implementation detail to creating objects :). Factories create objects, whether they're from a class is immaterial. So, what you want is not a list of classes but a list of factories that can create IContainers. This is possible by using zapi.getUtilitiesFor(IFactory) and then checking each factory's getInterfaces() method whether IContainer is a part of the returned result. I would probably base an implementation of all on the UtilityVocabulary. I'll also note that the use case is also directly addressed through containment constraints. You can say that a container should only contain objects of some given types and you will get just those types in the add list. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: URGENT RFC: Is anyone using response.write in Zope 3?
Philipp von Weitershausen wrote: Jim Fulton wrote: When we refactored the Zope 3 pubisher to work more closely with WSGI, we decided to remove the response.write method. We should have written a proposal for this, but we failed to do so. Over the last few weeks there has been much discussion of this in which I asserted many times that I didn't think any applications outside of Zope 3 itself used this method. No one has disagreed with me. I want to double check this. Does anyone have any Zope 3 applications that are using response.write? Assuming that the answer is "no" (or that no one answers today), I'm going to more clearly document how to return long output and I'm going to add a method that generates a hopefully helpful error. Note that we may add this method (or something like it) back in the future to support chunked streaming output, Alas, I just realized from Adam Summer's posting to zope3-users two days ago (http://mail.zope.org/pipermail/zope3-users/2005-December/001746.html) that my book is using response.write(). I had totally forgotten about it, though it isn't much of a problem. The book is about Zope X3 3.0 and can't make guarantees about future versions. Just to be safe I've added an entry to my errata page: page 204, Example 12.24, line 17: Using the ``write()`` method of HTTP-based responses does not provide a performance advantage in Zope X3 3.0 and 3.1 and is not supported anymore in Zope 3.2 and higher. To effectively return large data without holding it in memory, it is now recommended to create a temporary file and return that:: import tempfile f = tempfile.TemporaryFile() f.write(pdf.data) return f This will only work with Zope 3.2 and higher. Yeah, this is definately a problem. I don't want to make it hard for people who bought the book. I'd also rather not delay the release any more. Hopefully, the new error message in 3.2 will make this clearer. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Get classes implementing Interface
Florian Lindner wrote: > my first use case is that I want to enhance the HomefolderManager to make it > possible to select something else than a Folder to be created automatically. > Right now I have forked a version of the HomefolderManager and just changed > in the code. But I would like to have a more generic solution and I'll also > commit it back to the trunk. > For that I want all classes implementing IContainer (and IContentType ?) and > let the user select on in the configuration dialog of the HomefolderManager. > More use caess probably show up in my project later, but nothing fixed at > this > time. So what you want is to create objects. Classes are just an implementation detail to creating objects :). Factories create objects, whether they're from a class is immaterial. So, what you want is not a list of classes but a list of factories that can create IContainers. This is possible by using zapi.getUtilitiesFor(IFactory) and then checking each factory's getInterfaces() method whether IContainer is a part of the returned result. I would probably base an implementation of all on the UtilityVocabulary. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Get classes implementing Interface
Am Freitag, 30. Dezember 2005 10:20 schrieb Philipp von Weitershausen: > Florian Lindner wrote: > > Am Mittwoch, 28. Dezember 2005 14:48 schrieb Jim Fulton: > >>Florian Lindner wrote: > >>>Hello, > >>>how can I get all classes that implement a specific interface? > >>>What interface do I need to search for, when I want all objects that can > >>>be added and work as container? IContainer seem to be implemented by a > >>>lot more objects... > >> > >>There isn't an api for that. > > > > And there is no workaround that comes? How would you do that? > > What's your use case? Hi, my first use case is that I want to enhance the HomefolderManager to make it possible to select something else than a Folder to be created automatically. Right now I have forked a version of the HomefolderManager and just changed in the code. But I would like to have a more generic solution and I'll also commit it back to the trunk. For that I want all classes implementing IContainer (and IContentType ?) and let the user select on in the configuration dialog of the HomefolderManager. More use caess probably show up in my project later, but nothing fixed at this time. Thanks, Florian ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Get classes implementing Interface
Florian Lindner wrote: > Am Mittwoch, 28. Dezember 2005 14:48 schrieb Jim Fulton: > >>Florian Lindner wrote: >> >>>Hello, >>>how can I get all classes that implement a specific interface? >>>What interface do I need to search for, when I want all objects that can >>>be added and work as container? IContainer seem to be implemented by a >>>lot more objects... >> >>There isn't an api for that. > > > And there is no workaround that comes? How would you do that? What's your use case? Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: substitute for deprecated response.write()?
Adam, first, thanks for bringing this to my attention! I wasn't aware at all that one of my examples was using response.write(). It wouldn't have changed anything, I think, as I think response.write() was bound to go anyways, but at least I should have reacted in some sort of way. Sorry about that. > I am red faced (and blurry-eyed, its 1am here)- I found the answer in > the archives, in September: > > On Fri, Sep 16, 2005 at 11:50:19AM -0400, Stephan Richter wrote: > >>> Just return the data; it is handled properly now Yes and no. Sure you can just return the data which has about the same effect as response.write() had: it's not very memory efficient. If the produced PDF file gets large, it holds up a lot of memory until the request is over. A better way is to return a temporary file which holds the data and from which the data is then streamed to the client. Here's what I've added to my errata page: page 204, Example 12.24, line 17: Using the ``write()`` method of HTTP-based responses does not provide a performance advantage in Zope X3 3.0 and 3.1 and is not supported anymore in Zope 3.2 and higher. To effectively return large data without holding it in memory, it is now recommended to create a temporary file and return that:: import tempfile f = tempfile.TemporaryFile() f.write(pdf.data) return f This will only work with Zope 3.2 and higher. Hope that helps. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: URGENT RFC: Is anyone using response.write in Zope 3?
Jim Fulton wrote: > When we refactored the Zope 3 pubisher to work more closely with WSGI, > we decided to remove the response.write method. We should have written > a proposal for this, but we failed to do so. Over the last few weeks > there has been much discussion of this in which I asserted many times > that I didn't think any applications outside of Zope 3 itself used this > method. No one has disagreed with me. I want to double check this. > Does anyone have any Zope 3 applications that are using response.write? > > Assuming that the answer is "no" (or that no one answers today), I'm > going to > more clearly document how to return long output and I'm going to add a > method that generates a hopefully helpful error. > > Note that we may add this method (or something like it) back in the future > to support chunked streaming output, Alas, I just realized from Adam Summer's posting to zope3-users two days ago (http://mail.zope.org/pipermail/zope3-users/2005-December/001746.html) that my book is using response.write(). I had totally forgotten about it, though it isn't much of a problem. The book is about Zope X3 3.0 and can't make guarantees about future versions. Just to be safe I've added an entry to my errata page: page 204, Example 12.24, line 17: Using the ``write()`` method of HTTP-based responses does not provide a performance advantage in Zope X3 3.0 and 3.1 and is not supported anymore in Zope 3.2 and higher. To effectively return large data without holding it in memory, it is now recommended to create a temporary file and return that:: import tempfile f = tempfile.TemporaryFile() f.write(pdf.data) return f This will only work with Zope 3.2 and higher. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
