I am the Plone champion for the buildout builder. The buildout builder
will be a web application, likely written in Grok, that will allow
textually-challenged users to configure a buildout via a GUI and receive
a .cfg in return.
Jim, you mentioned at PSPS-2008 that you would gladly help
I have a schema, let's call it B. It contains an @invariant function. I
observed that it is not being called during form validation.
After help from Philipp and some investigation, I determined that the
problem is that schema B isn't itself the main form, but is nested
within schema A as the
Martin Aspeli wrote:
Derek Richardson wrote:
So, is there an easy way to do it? I know I can write a recipe, but a
recipe seems heavyweight for this. It seems to me that access to these
two values should be built into buildout as implicit variables. Is
this contrary to the lightweight
I am using hexagonit.recipe.cmmi to install pound (www.apsis.ch/pound) in front
of zope. After I cmmi, I need to install a config file. I'd like to include the
pound config file in buildout.cfg, like the zcml section in
zc.zope3recipes:application. Is there a simple recipe for making a file out
After I install pound using cmmi, I want to create a run script in bin/. This
should be easy - the script should be boilerplate and not require mods for
individual installs. I can use the os command recipe to put it in bin/.
My question: where is best to store the script? Does it belong
I developed my Vice outbound syndication library on z3.3 (originally)
using the full tarball of z3.3. I now want to move to a buildout-based,
eggified method of developing and testing Vice.
I use functional tests (using zope.testbrowser.testing.Browser) in Vice.
These functional tests log
Philipp von Weitershausen wrote:
* If vice depends on the configuration of another package, but always
assumed that this package's configuration was being loaded by Zope 3.3's
site.zcml, make this dependency *explicit* now in vice's configure.zcml.
For example, let's say that vice needs the
Derek Richardson wrote:
I have a schema (the Tuple of Objects is the important part):
class ISyndications(Interface):
Annotation that indicates the object can provide IFeed
and that stores the current syndication configuration.
enabled = Bool(title=_(u'Enable syndication
Martin Aspeli wrote:
Derek Richardson-2 wrote:
Benji York wrote:
Derek Richardson wrote:
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local to the
feed annotation, thus recording and making available uuids
Martin Aspeli wrote:
Derek Richardson-2 wrote:
Yes, it does feel like I'm going about this the wrong way.
a - The feed is actually just configuration metadata - whether the
feed is enabled, whether it is recursive, what its display name is, etc.
The actual feed document is not stored
Benji York wrote:
Derek Richardson wrote:
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local to the
feed annotation, thus recording and making available uuids only for
entries in that feed.
How about a multi
I would like to create utility instances that are local to annotation
instances. Each utility would be valid only within the scope of the
related annotation.
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local
A colleague is interested in using Zope 3 (and, if possible, Grok) to
write a web app whose objects live, not in the ZODB or in an SQL DB, but
on the other end of XML-RPC calls. I am unclear how to implement this
one. Would an application of this type even have content objects? If
not, how
Philipp von Weitershausen wrote:
Martin and Gary pointed out other good reasons why not to go with
subclassing: the standard intid utility doesn't work in all
environments. Apparently in Zope 2 you'll need a slightly differnet
implementation. If you just defer to it via utility lookup, your
Benji York wrote:
Derek Richardson wrote:
I wrote most of it today and there is more code shared between the two
than is different. The main differences are:
* OOBTrees, instead of an IOBTree and an OIBTree
* Different events are fired when an object is registered and
unregistered
All,
I've decided to go ahead and write an RFC 4122 UUID utility based on
zope.intid (this is for a Plone SoC project, but this bit is pure Zope
3). I wrote most of it today and there is more code shared between the
two than is different. The main differences are:
* OOBTrees, instead of an
. Can you advise whether the
UUID utility will be ZPL licensed since this is important if you are
talking about something with generic functionality for z3. Many thanks.
Regards,
David
Derek Richardson wrote:
All,
I've decided to go ahead and write an RFC 4122 UUID utility based on
zope.intid
Fred Drake wrote:
On 4/5/07, David Pratt
[EMAIL PROTECTED] wrote:
The UUID generator that I have been looking at is with the Chandler
project (currently under Apache license) that could be easily wrapped:
Python 2.5 comes with a uuid module that works just fine with Python
2.4; that comes in
Stephan Richter wrote:
On Thursday 05 April 2007 15:28, Jürgen Kartnaller wrote:
Please do not use an annotation!
This is a performance issue. Your data is very small so do not create a
new object in the database store it directly as a property on the
instance. Every object lookup is
I believe that that will not guarantee a *universally* unique id, but
only an id unique within that ZODB. Am I wrong?
The RFC prescribes a specific algorithm for generating universally
unique IDs.
Derek
Benji York wrote:
Derek Richardson wrote:
I am hoping that Zope 3 assigns an RFC 4122
20 matches
Mail list logo
