Re: [Zope3-Users] Principal-Source Plug-Ins
On Tuesday 28 February 2006 12:50, Nick Pavlica wrote: I was wondering if it was still current/valid? If not what are changes? While this still should work, it is written for the old pluggable authentication service. We now use always the new pluggable authentication in zope.app.authentication. This new package has a lot of documentation on how to develop principal sources. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] datafield as objectname
On Tuesday 28 February 2006 10:28, Egon Frerich wrote: What should I do? Well, your edit form has to be smart enough to detect name changes. If the name changed, it needs to do a redirect. All your other steps are correct. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Wierd import problem
On Tuesday 28 February 2006 06:50, Florian Lindner wrote: ImportError: cannot import name UserRegistrationField my views.py has: class UserRegistrationField(TextLine): implements(ITextLine) def _validate(self, value): super(UserRegistrationField, self)._validate(value) [...] and my interfaces.py: from views import UserRegistrationField both are in the same directory. If I remove the the import everything goes well. If I cutpaste the code from views.py to interfaces it works too. What am I doing wrong here? This is a classical circular import error. If your views.py, for example, imports interfaces.py, you have a circular import loop between views.py and interfaces.py. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zodb objects backup
Hi, Under Zope 2 I use repozo (and rsync) to incrementally back up the Data.fs to provide a 'warm' backup, If you can live with losing perhaps 10 minutes worth of data it's a nice and simple solution. repozo.py is a zodb file storage level tool so should work fine with zope 3. Ensuring that every transaction is replicated is more difficult, Zope Corp's ZRS does it, but was uneconomic for my use case. It's a tricky problem to solve efficiently - any solution will incur a write performance hit. One day I hope to be able to put PGStorage to the test, but even in postgres-land there appear to be many projects providing replication functionality, perhaps a testament to the tradeoffs required. Regards, Laurence Alen Stanisic wrote: Hello, what would be the best way of taking a backup of persistent objects inside Data.fs with possibility to rebuild it on a fresh Zope 3 install in case of a disaster recovery lets say. Thanks Alen ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Visionaire! (All your problems, solved)
We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much not Zope 2. But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between Zope 3 as Application Server and Zope 3 as cool collection of packages. Today, I wrote a much longer message in response to the Two Visions thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a one little thing that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - zope as library and big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today. Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of should I support the ZMI? use it as my user interface? should I use the TTW page templates?. IFolder and IContainer... What is the difference and which should I use? Which should be my base class (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. I'm making a wiki. How does SQL Script apply? I18N File?. And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new object oriented operating system) out into a small set of distinct offerings: TalOS (Taligent Object Services), TalAE (Taligent Application Environment), and so on. And I thought about doing this for Zope, and came up with the following: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. We don't need a hundred different editions like Microsoft. Nor do we need a hundred different acronyms like Java development seems to have. I think we could boil things down to these three offerings,
Re: [Zope3-Users] Visionaire! (All your problems, solved)
On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote: [...] - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. This would meet what I'm looking for...but I don't think I'll be one of the hard ones to convince. ;-) Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Visionaire! (All your problems, solved)
I think packaging efforts are really the key to being able to tell a story like this. The efforts happen to be couched in a process of converting z3 packages into eggs, but really the process of identifying dependencies and eliminating the silly ones is the valuable work here, and it seems to be getting done by embracing egg packaging, which is really wonderful. One we have well-factored modules that are packaged and maintained independently, all sorts of things like the AS vs. CA you mention or a Zope 3 core that is more like zope.bobo, or a Zope that combines both z3 and z2 in various ways becomes a lot more possible. On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote: We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much not Zope 2. But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between Zope 3 as Application Server and Zope 3 as cool collection of packages. Today, I wrote a much longer message in response to the Two Visions thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a one little thing that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - zope as library and big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today. Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of should I support the ZMI? use it as my user interface? should I use the TTW page templates?. IFolder and IContainer... What is the difference and which should I use? Which should be my base class (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. I'm making a wiki. How does SQL Script apply? I18N File?. And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new object oriented operating system) out into a small set of distinct offerings: TalOS (Taligent Object Services), TalAE (Taligent Application Environment), and so on. And I thought about doing this for Zope, and came up with the following: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack
Re: [Zope3-Users] Re: ZopeX3 Component Architecture in comparision to MVC - general question/example
Hi Reinhold,
Here's another go at answering your case, this came about when last
night I added a source view to a RESTDocument content, it might come
closer to what you are looking at because it doesn't use tal templates
at all and secondly the request is available - so you can pass in
arguments to your calculator. My starting point for the code is from
zope.app.file.browser.file.
Best regards,
Darryl
!-- restdocument source view --
page
name=source.txt
for=..IPortalRestDocument
class=.views.PortalRestDocumentSourceView
permission=zope.Public
attribute=show
/
class PortalRestDocumentSourceView(BrowserView):
A RestDocument source view.
def show(self):
Call the source view of restdocument
request = self.request
if request is not None:
request.response.setHeader('Content-Type',
'text/plain')
return self.context.body
On Tue, 2006-02-28 at 17:52 +0100, Lennart Regebro wrote:
On 2/28/06, Reinhold Strobl [EMAIL PROTECTED] wrote:
Thanks for the reply. But how would you implement previously described task
with
the calculator?
I would implement it as a view on whatever object I want to view it
on. Which may even be *, that is any object.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
--
Darryl Cousins
Tree Fern Web Services (NZ) Ltd
106 Sandes St
Thames 2801
New Zealand
+64 7 868 3139
[EMAIL PROTECTED]
http://www.treefernwebservices.co.nz/
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Wierd import problem
Hi Florian, To get around the circular import error use a marker interface to suit your code. Best regards. Darryl On Wed, 2006-03-01 at 08:15 -0500, Stephan Richter wrote: On Tuesday 28 February 2006 06:50, Florian Lindner wrote: ImportError: cannot import name UserRegistrationField my views.py has: class UserRegistrationField(TextLine): implements(ITextLine) def _validate(self, value): super(UserRegistrationField, self)._validate(value) [...] and my interfaces.py: from views import UserRegistrationField both are in the same directory. If I remove the the import everything goes well. If I cutpaste the code from views.py to interfaces it works too. What am I doing wrong here? This is a classical circular import error. If your views.py, for example, imports interfaces.py, you have a circular import loop between views.py and interfaces.py. Regards, Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
