[Zope-dev] Lazy translation domains
In 2008, the `zope_i18n_allowed_languages` environment setting was introduced to limit the languages for which a message catalog is loaded when you register translations using the registerTranslation ZCML directive, and to be able to negotiate a list from a list of available languages. This branch implements a fallback mechanism where: 1) the allowed languages are determined at runtime. 2) translation domains are lazy, and load message catalogs only when required. http://svn.zope.org/zope.i18n/branches/lazy-tds/ \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] New release of zc.queue
I just committed a bugfix against zc.queue which makes it possible to slice a composite queue: https://mail.zope.org/pipermail/checkins/2012-June/061348.html It previously wasn't possible due to a simple programming mistake. Can we have a release 1.3.1? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] server accept() threw an exception in log
I had many of these in the instance log; googling around, I found this: https://mail.zope.org/pipermail/zope/2002-September/122392.html But it seems the patch attached to a post in that thread never made it to the repo. It's now almost ten years later, so this sort of incident must be pretty rare. The question remains, should the patched be applied? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZEO client cache not working properly with beforestorage
On 25 October 2011 17:53, Malthe Borch mbo...@gmail.com wrote: I'll try and see if I can understand what might be the right thing to expect and write a test case for that. Following up here on the list to get some feedback on the patch I submitted concerning this issue: https://bugs.launchpad.net/zodb/+bug/881493 The patch includes a test case and necessary code modifications. If someone could review the test case included in the patch, I'd appreciate it. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
On 7 November 2011 09:17, Ross Patterson m...@rpatterson.net wrote: The intention of this package is to see if the implementation of broken object handling is correct and robust enough to merge into zope.interface and zope.component themselves. Is this the right approach? If not why and what would be better? How might this approach be improved? (removed plone-dev from cc). Isn't it symptom treatment though? If you've got an add-on which adds marker interfaces to general objects, shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces. I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a hard remove of an add-on without a prior soft remove. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZEO client cache not working properly with beforestorage
If I set my beforestorage to a reasonably current time, e.g. now, I expect to get reasonably good performance from a ZEO client cache. Instead, I find that beforestorage: 1) asks the cache to ``loadBefore``; 2) but that method only looks for noncurrent entries; 3) meanwhile, my cache only has current records. I'm not sure if the problem is that the cache shouldn't be setting the loaded oids as current, or if the ``loadBefore`` method should also accept (some) current entries. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pluggable template engine
I will merge this branch if there are no objections. \malthe On 20 July 2011 17:24, Malthe Borch mbo...@gmail.com wrote: I've refactored the ``pagetemplate`` module to realistically support plugging in an alternative implementation of the parser and interpreter. http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/ Two new interfaces are added which serve as the plugging point see ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module: http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300view=markup I'd like to propose merging this into trunk. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pluggable template engine
On 21 July 2011 16:19, Leonardo Rochael Almeida leoroch...@gmail.com wrote: How often is the adaptation called? Once per template render. No penalty for macros. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Pluggable template engine
I've refactored the ``pagetemplate`` module to realistically support plugging in an alternative implementation of the parser and interpreter. http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/ Two new interfaces are added which serve as the plugging point see ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module: http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300view=markup I'd like to propose merging this into trunk. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pluggable template engine
It makes it possible to use Chameleon with the stock template classes without monkey-patching the ``TALInterpreter`` class and ``_cook``. \malthe On 20 July 2011 17:43, Jim Fulton j...@zope.com wrote: What problem does this solve? Jim On Wed, Jul 20, 2011 at 11:24 AM, Malthe Borch mbo...@gmail.com wrote: I've refactored the ``pagetemplate`` module to realistically support plugging in an alternative implementation of the parser and interpreter. http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/ Two new interfaces are added which serve as the plugging point see ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module: http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300view=markup I'd like to propose merging this into trunk. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 3 December 2010 11:41, Chris Withers ch...@simplistix.co.uk wrote: I'd much prefer it to just be an order of execution thing, the nyou have total and flexible control. Combined with some logging about why something is as it is and you have your solution. It's not always possible to control the order of execution. For instance, with z3c.autoinclude, the order of inclusion is somewhat random and although you can to some extend control the order via explicit dependency includes, it's hard to work around 3rd party packages that provide own overrides. The problem with e.g. request layers as a means to prioritize is that views adapt on (context, request) which makes it unfit for the purpose if you have any views that specialize on the context interface. Instead, priorities on the configuration level would be an easy solution if you are trying to simply get a component to kick in. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Context priority as an alternative to configuration directive overrides
I always found configuration overrides (e.g. ZCML's includeOverrides directive) to be difficult to manage and hard to get right. How about an alternative where you can put a priority on a configuration context like so: adapter zcml:priority=100 ... / Default priority would be 0, traditional overrides get the maximum priority. ZTK components might then all be at the default priority, making it trivial to add a preferred component in a custom setup. If accompagnied by a sane amount of logging output, this system might facilitate plugging in components for the rest of us. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 2 December 2010 13:34, Benji York be...@benjiyork.com wrote: I appreciate the flexibility inherent in that approach, but personally, I'd be frightened of such a system. I sometimes have problems figuring out which directives are active in the current system, if I had to reason about dozens of priority levels I think it'd be worse. I think there would in general be either no priority set or a single, non-trivial priority. It's true that priorities in general open up for some complexity (e.g. ordering ``zope.viewlet`` viewlets), but if used sparingly, I think it's a reasonable approach. I don't quite follow the for the rest of us part. Will you expand on that? As far as I understand, for a ZCML include override to work properly, you need to carefully make sure that your includes are in the exact right order and on the same level. In a system where two packages are trying to override the same component (should arguably never be the csae, but it is frequently), it can be difficult to get it right. Priorities on the other hand are absolute, globally. It's easy for anyone to see that the highest priority wins, no matter the order of inclusion. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 2 December 2010 14:37, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: This explanation helped me to understand where you come from. I think I would be okay with the priority feature, but could we maybe limit it to the configure element? Since you can use this element anywhere and it can be nested, it should work well. That's reasonable. The priority needs to get applied to the configuration context anyway and this might (I don't recall the exact implementation) correspond to the configure element anyway. I'll try to get an implementation working. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] chameleon.core removes the meta http-equiv=content-type tag
Fabio Tranchitella wrote: # TODO: Shouldn't meta/?xml? stripping # be in PageTemplate.__call__()? body = utils.re_meta.sub(, body) This snippet was removed from ``chameleon.core`` in r6505. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] chameleon.core removes the meta http-equiv=content-type tag
Fabio Tranchitella wrote: I hope this is the right mailing list for such a question. Why does chameleon.core removes the meta tag http-equiv=content-type from the output? I have no idea why; I've asked Sidnei to clarify that particular changeset in Chameleon (although I suspect it was just carried over as-is from ``zope.pagetemplate``). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.proxy
Martin Aspeli wrote: Is there any documentation on zope.proxy other than the test? I don't speak C anymore. :) I find ``zope.location.location.LocationProxy`` to be a good example of its usage. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.saconfig engine creation configuration
Laurence Rowe wrote:
I would rather we did not hardcode the defaults from SQLAlchemy into the
engine directive (I guess they could change in future). Instead use a
default of None and only supply the parameter if the config option is set.
Sounds right to me. Attached is an update patch.
\malthe
Index: src/z3c/saconfig/zcml.py
===
--- src/z3c/saconfig/zcml.py(revision 101264)
+++ src/z3c/saconfig/zcml.py(working copy)
@@ -27,13 +27,28 @@
required=False,
default=False)
+pool_size = zope.schema.Int(
+title=uPool size,
+description=uNumber of connections to keep open inside the connection
pool.,
+required=False)
+
+pool_recycle = zope.schema.Int(
+title=uPool recycle,
+description=uRecycle connections after the given number of seconds
have passed.,
+required=False)
+
+pool_timeout = zope.schema.Int(
+title=uPool timeout,
+description=uNumber of seconds to wait before giving up on getting a
connection from the pool.,
+required=False)
+
setup = zope.schema.BytesLine(
title=u'After engine creation hook',
description=u'Callback for creating mappers etc. One argument is
passed, the engine',
required=False,
default=None)
+
-
class ISessionDirective(zope.interface.Interface):
Registers a database scoped session
@@ -62,16 +77,27 @@
default=z3c.saconfig.utility.GloballyScopedSession)
-def engine(_context, url, name=u, echo=False, setup=None, twophase=False):
-factory = utility.EngineFactory(url, echo=echo)
-
+def engine(_context, url, name=u, echo=False, setup=None, twophase=False,
+ pool_size=None, pool_recycle=None, pool_timeout=None):
+# to avoid overriding defaults, we only provide pool configuration
+# parameters if set
+kwargs = {}
+if pool_size is not None:
+kwargs['pool_size'] = pool_size
+if pool_recycle is not None:
+kwargs['pool_recycle'] = pool_recycle
+if pool_timeout is not None:
+kwargs['pool_timeout'] = pool_timeout
+
+factory = utility.EngineFactory(url, echo=echo, **kwargs)
+
zope.component.zcml.utility(
_context,
provides=interfaces.IEngineFactory,
component=factory,
permission=zope.component.zcml.PublicPermission,
name=name)
-
+
if setup:
if _context.package is None:
callback = resolve(setup)
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.saconfig engine creation configuration
On MySQL, it's necessary to supply to ``pool_recycle`` parameter on engine creation, else the connection dies after some timeout and the pool is unable to hand out a session. The result of this is that the first request fails whenever the connection has been dropped. Attached is a patch that allows supplying these pool-related configuration options directly in the ZCML directive (db:engine). \malthe Index: src/z3c/saconfig/zcml.py === --- src/z3c/saconfig/zcml.py(revision 101264) +++ src/z3c/saconfig/zcml.py(working copy) @@ -27,13 +27,31 @@ required=False, default=False) +pool_size = zope.schema.Integer( +title=uPool size, +description=uNumber of connections to keep open inside the connection pool., +required=False, +default=5) + +pool_recycle = zope.schema.Integer( +title=uPool recycle, +description=uRecycle connections after the given number of seconds have passed., +required=False, +default=-1) + +pool_timeout = zope.schema.Integer( +title=uPool timeout, +description=uNumber of seconds to wait before giving up on getting a connection from the pool., +required=False, +default=30) + setup = zope.schema.BytesLine( title=u'After engine creation hook', description=u'Callback for creating mappers etc. One argument is passed, the engine', required=False, default=None) + - class ISessionDirective(zope.interface.Interface): Registers a database scoped session @@ -62,8 +80,11 @@ default=z3c.saconfig.utility.GloballyScopedSession) -def engine(_context, url, name=u, echo=False, setup=None, twophase=False): -factory = utility.EngineFactory(url, echo=echo) +def engine(_context, url, name=u, echo=False, setup=None, twophase=False, + pool_size=5, pool_recycle=-1, pool_timeout=30): +factory = utility.EngineFactory( +url, echo=echo, pool_size=pool_size, +pool_recycle=pool_recycle, pool_timeout=pool_timeout) zope.component.zcml.utility( _context, ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release?
2009/5/23 Adam GROSZER agros...@gmail.com: The problem that I see here with lxml is that it is used for output checking. Even worse z3c.form requires at least 2.1.1 of lxml, where KGS 3.4 has lxml nailed at 1.3.6. It might be possible to shed this testing dependency; ``lxml`` is used because of its doctest-mode, but since then, Chameleon has been equipped to render attributes in the ZPT order (instead of more or less random). This was the raison d'etre to use lxml in tests. This burpes already on buildout. Now even if I would ignore this requirement for testing, (and testing) how could I be sure that tests pass (with KGS 3.4)? Yes, I agree with that observation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release?
2009/5/21 David Glick davidgl...@onenw.org: Won't this cause problems if a z3c.form uses a template which calls a macro from a traditional Zope page template? That is, make it impossible to use z3c.form in a site that isn't using z3c.pt for everything? That was the reason for z3c.ptcompat; it lets you use one import-location to switch between the two implementations. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release?
2009/5/21 Adam GROSZER agros...@gmail.com: Well, the strong target is to make z3c.form 2.0 compatible with KGS 3.4. (z3c.pt is somehow intertwined with z3c.ptcompat too.) That's the goal am chasing though I'm quite busy right now. I don't know the implications of requiring zope.i18n = 3.5, but I can say that it's the only dependency that could somehow cause difficulties. Neither z3c.pt nor z3c.ptcompat have any odd dependencies (package or version-wise). Perhaps it's the obsolete dependency on lxml that's causing confusion; I read a post or two on the list rightfully mentioning that this was a very difficult dependency indeed. I think at this point that z3c.form could have a strong dependency on z3c.pt. Complete list of extra packages: - z3c.pt - chameleon.core - chameleon.zpt - sourcecodegen \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release?
Hello Adam, –– The z3c.pt package shouldn't have difficult dependencies; it depends on zope.i18n = 3.5 but reasons unknown to me (Hanno CC'ed). Note that the package no longer depends on ``lxml``. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] (no subject)
Chris McDonough chrism at plope.com writes: This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration should be done via highly specialized ZCML directives (or grokkers), as opposed to some very general adapter registration that can't be easily discerned from other adapter registrations by a newbie. I agree very much that the various default Zope components could be much more rigid; this would make it easier to understand the application flow and better realize when to subclass or replace. If rigid means less configurable, then perhaps components could be made flexible by better adapting to the objects given to them, e.g. use the interfaces system to tell what kind of functionality objects inhibit and provide flexibility through this route. As such, instead of attempting to look up a custom traverser for an object, ask the object do you provide your own traversal logic?. Instead of components being primarily pluggable, they could be adaptive. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.pt bug
2009/4/3 Roger Ineichen d...@projekt01.ch: Can you run the group.txt tests in z3c.form and confirm the issue. A div tag get skipped after some nested repeat tags. (line 898, in group.txt) I've reproduced this bug in a test case in ``chameleon.zpt`` (r4073). Will try and solve asap; thanks for identifying it. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.pt bug
2009/4/3 Roger Ineichen d...@projekt01.ch: Can you fix this or give me some hints which let me do this? This issue has been fixed and ``chameleon.core`` 1.0b27 released. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.pt bug
2009/4/3 Roger Ineichen d...@projekt01.ch: Can you run the group.txt tests in z3c.form and confirm the issue. A div tag get skipped after some nested repeat tags. (line 898, in group.txt) Running with the latest ``chameleon.core``, ``chameleon.zpt`` and ``z3c.pt``, I only get one test failure: File /Users/mborch/co/z3c.form/src/z3c/form/tests/../group.txt, line 447, in group.txt Failed example: event Expected: zope.app.event.objectevent.ObjectModifiedEvent object at ... Got: zope.lifecycleevent.ObjectModifiedEvent object at 0x26a6bb0 \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [zope.testbrowser] r84900
2009/3/18 Christian Theune c...@gocept.com: Did this get resolved by any means? As it didn't spur any discussion at all, you might want to at least file a bug tracker issue for that problem. It has now been filed as https://bugs.launchpad.net/zope3/+bug/344680. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and
2009/3/18 Christian Theune c...@gocept.com: I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. That's a good approach. What kind of configuration should enable it; an environment variable or a module global? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and
2009/3/18 Roger Ineichen d...@projekt01.ch: This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not? Correct, but should enforce these requirements? I think ZPT should just have predictable, expected behavior, but not make too much fuss about syntax. I agree though, that object() or False should probably raise exceptions. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPT attributes and
Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, , object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``. How do folks feel about changing this behavior in ``zope.pagetemplate``. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT attributes and
2009/3/10 Fred Drake fdr...@gmail.com: The change would need to be in zope.tal. True. I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery. I agree, but it would be interesting to gauge the usage of this functionality (e.g. if everyone could put a breakpoint in the right place, run their apps and check). Actually, I think this is a bug; why would the empty string not be printed? If we can agree it's a bug, then I guess it should be fixed as part of the general maintenance of the package. At any rate, if we did change/fix the behavior, a warning should probably be issued. If an attribute == then log a warning such as The behavior of this has changed. Make sure your templates are updated. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [zope.testbrowser] r84900
Code snippet: def open(self, url, data=None): See zope.testbrowser.interfaces.IBrowser url = str(url) This string coercion is unfortunate, because ``mechanize`` accepts a (mechanize-) request-object in place of a URL string here. Using a custom request object allows us to do such things as setting the REQUEST_TYPE header string, which is not possible throught the standard API. Changeset comment: - Remove vendor import of mechanize. - Fix bug that caused HTTP exception tracebacks to differ between version 3.4.0 and 3.4.1. - Workaround for bug in Python Cookie.SimpleCookie when handling unicode strings. - Fix bug introduced in 3.4.1 that created incompatible tracebacks in doctests. This necessitated adding a patched mechanize to the source tree; patches have been sent to the mechanize project. Not sure which of the above this coercion is trying to solve, but perhaps it could be solved in a way that didn't break the mechanize functionality. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Optional patching in z3c.ptcompat
Just a note that the upcoming release of z3c.ptcompat will have a module which monkey-patches ``zope.app.pagetemplate``, such that the view page template classes use z3c.pt for rendering (just committed to trunk). This is an optional behavior which may ease transition to Chameleon. Note that ``five.pt`` does this by default (for Zope 2 deployments). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Changelog formatting [was: SVN: cmf.pt/trunk/ Preparing release.]
2008/12/21 Philipp von Weitershausen phil...@weitershausen.de: I've noticed you're using the U.S. date format here which we discourage due to its ambiguity (in this case it happens not to be ambiguous, but that's just coincidence). The preferred format is the ISO 8601 dash notation (-MM-DD). Gotcha. I'll use this format in the future. This and other things, such as the proper formatting of changelogs, are documented in a guide called Maintaining Software in the Zope Software Repository [1] of which Releasing Software [2] is a chapter. I admit they're not in the most public place, I'm just the guy who wrote them (by codifying best practices). Anybody who'd like to put them somewhere more visible is most welcome to (e.g. the Grok folks have put the Releasing Software document on their website [3]). I should review this material. I'm having some problems these days formatting my changelogs. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] C-extension in zope.i18nmessageid
I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Martijn Pieters wrote: The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. I believe it is possible to do this in pure Python: We'll set up a security-proxied global dictionary ``messages`` that maps object_id of message - weakref(message) Then, the ``Message`` class would roughly look like this: class Message(unicode): def __new__(...): self = unicode.__new__(...) messages = removeSecurityProxy(messages) messages[id(self)] = (default, domain, mapping) @property def default(self): return messages[id(self)][0] The message data is effectively immutable, since the ``messages`` dictionary is security-proxied. To make sure the message properties are persisted along with the message, we must override the __reduce__-method to maintain the ``messages`` dict upon load. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Malthe Borch wrote: I believe it is possible to do this in pure Python: The implementation may reviewed in this branch: http://svn.zope.org/zope.i18nmessageid/branches/c-extension-less/ \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Marius Gedminas wrote: Careful: id(some_object) will likely be reused when the old object is garbage collected. This has been worked around using the weak reference dictionary. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Martijn Pieters wrote: I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. The obvious motivation for this is to: * Reduce code complexity * Allow operation in a pure-Python environment As for cons, any change is a risk and I believe the concensus seen in this thread is that it outweighs the above mentioned motivation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
Martijn Faassen wrote: My suspicion from observing the discussions in this thread so far indicate that a drop in code complexity doesn't seem to be a necessary consequence of rewriting to Python either. The proposed implementation has already been implemented (walk up this thread); it is indeed much less complex. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
2008/12/10 Brian Sutherland [EMAIL PROTECTED]: Below are the failures, Malthe, would you mind having a look at these? I'll take a look at them; seems to be __repr__-related all around. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
2008/12/9 Roger Ineichen [EMAIL PROTECTED]: I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages. Seems to work fine for e.g. ``repoze.bfg``. Malthe are you aware of this? Can you change it? I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
2008/12/9 Brian Sutherland [EMAIL PROTECTED]: Please let me know if there's a step I'm missing? There are other z3c.* packages which depend on it, namely z3c.template z3c.macro z3c.pagelet \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
2008/12/8 Adam GROSZER [EMAIL PROTECTED]: Coverage seems to burp on chameleon I just tried a buildout in newest mode and I did not see the error you pasted. It's important that the CHAMELEON_CACHE flag be set to '0' in an automated test setup (this is set in the buildout for the test runner). Note that I did get some test errors when running the tests, one seems to happen with and without z3c.pt enabled, but some others are output-related. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [z3c_pt] Adding resource in z3c.pt
2008/10/14 Binseer N [EMAIL PROTECTED]: Hi all, Can anybody tell me how can i add resource by using z3c.pt. i know how to add it by using zope.pagetemplate, i tried it and it was working well. The following is the code i am working with and it was not working with z3c.pt There is a bug in z3c.pt that disallows '+' in a path-expression. I'll fix that. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] lxml and z3c.form strategy?
2008/9/16 Roger Ineichen [EMAIL PROTECTED]: What is the reason why z3c.* packages should use z3c.pt and fallback to a new concept rather then stay with PageTemplate if no lxml is installed and z3c.pt is useless? There seems to be some confusion here, and I understand why this has arisen, but let me repeat what Chris also has mentioned: There's absolutely no trace of XML left after a template is compiled (not so for Genshi templates, but that's a different story). The *only* reason I opted for lxml is that it seemed to provide the best parsing functionality. However, ``xml.etree`` aka ElementTree seems to be a good candidate, too. Is the fallback to xml.etree faster and then the old stable PageTemplate implementation? See above. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Stephan Richter [EMAIL PROTECTED]: Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations. Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages. I think we should work to never have zope.*-packages depend on zope.app.* ––– and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems very difficult). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen [EMAIL PROTECTED]: Are you thinking about a basic UI interface package. where we probably define some interfaces e.g. IBrowserPage and friends and nothing else? It really depends on how much we want to play with frameworks like repoze.bfg that do not want complete buy-in. This whould offer a good base for any other UI framework to provide the right interfaces for their implementation. Interfaces like IContentProvider could depend on such an interface too. And the ITerms interface could also become a part of this package rather then move to a zope.term package which we already agreed on. In Zope, there's a default implementation for most interfaces and this makes it easy to get started. The downside is that often times those implementation have a bunch of dependencies. But I don't think there's a way out of that. That's why I think we should simply try to get rid of zope.app.*-dependencies for starters and also try to move commonly used components/interfaces to base packages. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen [EMAIL PROTECTED]: yes, this package must be a zope.* package. Then we could move the ITerms interface to this package too rather then add a new one like zope.term. Could this package be called ``zope.browser`` then? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.pt/trunk/TODO.txt
Chris McDonough wrote: Log message for revision 90974: Added: z3c.pt/trunk/TODO.txt === --- z3c.pt/trunk/TODO.txt (rev 0) +++ z3c.pt/trunk/TODO.txt 2008-09-09 00:03:08 UTC (rev 90974) @@ -0,0 +1,4 @@ +- Make e.g. tal:block tal:foo / and metal:foo metal:define-macro/ etc. + work Are we sure we want this? It's (afaik) not correct XML; but maybe an exception should be raised, rather than no interpretation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.pt/trunk/TODO.txt
2008/9/9 Stephan Richter [EMAIL PROTECTED]: It's not strict. It's a shortcut. No it's other way around. tal:block for= / is the short-cut for tal:block tal:for= /. Previously only the short-cut was allowed; this has been changed in the most recent release of z3c.pt. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
2008/8/30 Dieter Maurer [EMAIL PROTECTED]: This is correct for HTML PageTemplates; XML PageTemplates, too, require the namespace declarations -- at least this has been the case for the former Zope 2 version of PageTemplate (I do not yet know most details about the newer Zope 3 PageTemplate). That makes sense since you're not even allows to use foreign namespaces in XHTML. We I don't think we have a good way to make this distinction besides passing arguments to the constructor. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPT and strict namespace mapping
Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
2008/8/29 Andreas Jung [EMAIL PROTECTED]: --On 29. August 2008 12:31:21 +0200 Malthe Borch [EMAIL PROTECTED] wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). Can you elaborate this statement? Right, so this is basically a question of whether the following template is legal or not: div tal:replace=string:hello world! / In ZPT it would be, because it automatically assumes this namespace declaration: xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope. org/namespaces/tal xmlns:metal=http://xml.zope.org/namespaces/metal; . z3c.pt otoh, does not make such an assumption. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
Fred Drake wrote: This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. I didn't know there was a controversy, but I do remember that there was consensus that ``extras_require`` is not the most elegant solution. If you can advise a different way to avoid pulling in ``zope.app.testing`` I'm happy to revert the change; otherwise I think we should live and let live with it since it at the very least does the job. Or just revert the change and let Zope have its many dependencies. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
Fred Drake wrote: There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I understand, but this particular dependency pulls in the world, all 76 packages. I'll revert the change; it seems we're about to have a fork the size of the emacs/xemacs conflict, because for projects like repoze.bfg, dependency hell is no longer acceptable. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.formwidget.query - incorrect interface implementation?
Martin Aspeli wrote: I'm trying to build a widget that allows for auto-complete of items in a vocabulary, but also allows additional (string) values to be added. To understand how that works, I am digging into z3c.formwidget.query, and it looks to me like it's making incorrect assumptions about its own interfaces. This can very well be; the defense would be that the entire vocabulary code is full of odd interfaces that don't really form a complete story. If I'm not reading this wrong, it seems to me that z3c.formwidget.query is using getTermByValue() (which I can't find anywhere else) instead of getTermByToken() as defined by IVocabularyTokenized. I don't remember the details, but the implementation may be incorrect although functional. Certainly, it's made to good use by ``plone.app.z3cform`` and a number of other modules. You're more than welcome to improve or devise an alternative implementation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: could zope.sqlalchemy flush before committing?
Martijn Faassen wrote: Thanks for the offer. I think this is up to Laurence to decide, I'd say. I'm aiming my work at the 0.5 series so I'm fine with requiring 0.5. Me too, but I'd be careful to *require* an unreleased version. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Python-Dev] Syntax error in python2.6
Lennart Regebro wrote: 2. Using **kw in the argument and looking for noth with and with_, that way, which will be backwards compatible. +1 \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Chris McDonough wrote: I've been working on a new web framework named (provisionally) repoze.bfg. This looks very interesting; I'd be curious to see if this could be useful for Vudo. I'd like it very much if Vudo could sit on top of a more general framework (not just the Zope 3 libraries). Early on, the idea was that this could be Grok, but it quickly turned out that Grok makes too many assumptions for our use. I recently pasted a basic Pylons application and it gives you something that I think would be attractive in a Zope/Vudo/Bfg-based setup: A canonical directory structure, e.g. ./templates ./routers ./config etc. (can't remember the details) Perhaps this could benefit the following scenario: -- Set me up with a new Zope/Vudo/Bfg-application and give me some starting points. If Bfg can provide the lower layer, then I think Vudo will be great for providing the higher layers, e.g. -- skinning -- content types and widgets -- authoring -- admin \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.sqlalchemy and in-memory sqlite
With an in-memory engine, I seem to lose track of the tables after the first response. Turn of events: 1. Request comes in 2. Create some tables 3. Add content and commit transaction 4. Query content 5. Return response Now... 6. New request comes in 7. Query content (OperationalError) no such table: mytable ... With a disk-based database, no errors occur. The point of my little story line was to illustrate that this does not have anything to do with transactions being committed. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: Could you be more explicit about what exactly in Grok was making too many assumptions? First a word on terminology: I mean Grok, the framework, not the declarative extensions to the component architecture (which I simply haven't gotten to yet). We felt that Grok was too much about object publishing; there's a model and a view for that model (and that view has a template). This didn't fit so well into our approach. On Vudo, the view is always a layout. It's then up to the layout to provide regions in which you can plug in a region content provider. Typically, you'd plug in at least the following: -- Title provider: Renders the title of the page (in title/title) -- Content provider: Renders the content of the page as widgets There are many more options to this scheme. You could plug in a portlet manager, or a viewlet manager or a global navigation. Next, we didn't want to use ZODB, because we wanted to try something completely different. So now we've written Dobbin which pretty much emulates ZODB, but on a SQL storage (so much for trying something new). I like Grok and I think it's great for writing Zope *applications*; but we didn't find it such a good match for Vudo. I still want to try grokcore.component because there are some obvious candidates for declarative component setup in a system like ours (content-types, widgets, forms, etc.). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: repoze.bfg
Martijn Faassen wrote: So basically you felt Zope 3 wasn't a good match for Vudo, in the sense that the normal browser:page wasn't really want you wanted either, right? Similar to the way you could extend Zope 3 with your own new ZCML directives to set up the way you'd like views to work (I'm not sure whether you're doing this), you could as well extend Grok with your own new grokkers. Correct. And we did create a new directive to define layouts. I actually think ZCML is very suitable when you're configuring stuff that hasn't to do with code. Whether it's good for configuring code is for another discussion. I just didn't want Grok singled out here - I don't to leave people with the impression that Grok locks them into a certain approach any more than Zope 3-the-application-framework does; I don't believe it does. Of course Zope 3-the-libraries leave the options more open, witness this thread. The various grok libraries (martian, grokcore.component) should be seen as part of this wider ecosystem as well. That's a good point. Certainly Grok proves to be quite flexible, but it's still very centralized on defining a set of components and have them automatically glued together. I think Grokkish ideas will make much sense in Vudo *applications*. For the framework code I'm a bit more conversative. I hope that some of your explorations concerning layouts could be plugged into Grok as a library eventually. The layout stuff is definitely easy to reuse and I think Brandon already has a good grasp on how it might fit in. The key idea with ``vudo.layout`` is that you can just plug in HTML and have it work. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildout's buildout seems broken (tests also)
Christian Theune wrote: Develop: '/home/ctheune/Development/zc.buildout/.' While: Installing. Getting section test2.3. Initializing part test2.3. Getting section python2.3. Error: The referenced section, 'python2.3', was not defined. FWIW, I made the following changes to get things working on my system: Index: buildout.cfg === --- buildout.cfg(revision 87552) +++ buildout.cfg(working copy) @@ -5,6 +5,9 @@ test2.4 py2.4 oltest2.4 test2.5 py2.5 oltest2.5 +[python2.3] +executable = /usr/bin/python2.3 + [py2.3] recipe = zc.recipe.egg eggs = zc.buildout @@ -32,6 +35,8 @@ ] python = python2.3 +[python2.4] +executable = /opt/local/bin/python2.4 [py2.4] recipe = zc.recipe.egg @@ -60,6 +65,8 @@ ] python = python2.4 +[python2.5] +executable = /opt/local/bin/python2.5 [py2.5] recipe = zc.recipe.egg \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] View component registration
Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request). An example of this is ``IAbsoluteURL``; it clashes with the resources view*. In the words of Christian Theune: I think it looks like one should never ask for adaptions to Interface. I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``. \malthe *) ``zope.app.publisher.browser.resources.Resources``. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
Martijn Faassen wrote: There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: View component registration
Christian Theune wrote: I don't think zope.component wants to know about views. The interface should be in a package that already knows about views. I agree it's an inappropriate location, however, zope.component *does* define an ``IView`` interface as it is (zope.component.bbb.interfaces). Perhaps it should be moved to zope.app.component which defines the view meta directive. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: z3c.pt/trunk/ In debug mode the actual source code for file templates is written out to a filename.source file, to make it easier to inspect it.
Hanno Schlichting wrote: Log message for revision 87393: In debug mode the actual source code for file templates is written out to a filename.source file, to make it easier to inspect it. Make debug mode setting explicit in a config.py. Currently it is bound to Python's __debug__, which is False when run with -O and otherwise True. I'm not sure it's a good idea to litter the file system with these files; they'll probably confuse most users. At the same time, as far as I can tell, we do need to actually save the generated Python-code to disk to get proper debugging. Can we write them to a temporary directory? If we assign a filename based on the hash of the contents, the space occupied should be fairly limited. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: z3c.pt/trunk/ In debug mode the actual source code for file templates is written out to a filename.source file, to make it easier to inspect it.
Tres Seaver wrote: I don't think I would this to __debug__: I wouldn't want to pay a price either at startup time or (worse) at render time for information I don't need or want. Is ``devmode`` available on Zope 2? That might be a good flag to control this. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Buildout parameter parsing
I think a valuable extension to the parameter parsing in buildout's configuration language would be to allow += and -= operators, which would append and remove items, respectively. Example: [instance] eggs += Products.PDBDebugMode Singular or plural arguments would be supported. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout parameter parsing
Philipp von Weitershausen wrote: This isn't the buildout list :). I think buildout matters are discussed on the distutils SIG mailinglist. I guess they're also discussed here now :P There's also an issue tracker at https://edge.launchpad.net/zc.buildout. I'll submit it there, thanks. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout parameter parsing
This is now: https://answers.edge.launchpad.net/zc.buildout/+question/35159 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: DirectoryResource, Five and IAbsoluteURL
Malthe Borch wrote: However, trying to get the absolute url of the resource fails, and it seems to be an acquisition-wrapping thing. FWIW, this adapter will do the trick, although it's hardly a solid solution: class SimpleResourceAbsoluteURL(object): interface.implements( zope.traversing.browser.interfaces.IAbsoluteURL) component.adapts( Products.Five.browser.resource.DirectoryResource, zope.publisher.interfaces.browser.IDefaultBrowserLayer) def __init__(self, context, request): self.context = context def __str__(self): return self.context() \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] DirectoryResource, Five and IAbsoluteURL
These three don't mix well; here's the setup: Using ``zope.traversing.api.traverse``, we're able to traverse from the site root to the directory resource, and on to the actual resource by way of OFS.Traversable. However, trying to get the absolute url of the resource fails, and it seems to be an acquisition-wrapping thing. We're in ``Products.Five.browser.resource.Resource``, and the directory resource has the following aq_chain: [Products.Five.metaclass.DirectoryResource9 object at 0x9a1de30, Products.Five.metaclass.DirContainedImageResource9 object at 0x9a1d630, Products.Five.metaclass.DirectoryResource9 object at 0x9a1de30] A lethal cocktail. Can anyone shed light on this issue? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3 on Google AppEngine
Jodok Batlogg wrote: and yes again. unfortunately there is no open source / non-google DB application implementation so far. we keep this in mind. There is http://hypertable.org, but of course that's not an application engine. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3 on Google AppEngine
David Pratt wrote: Hi Jodok. I had looked at storm a while back but the zope integration seemed to lack any relationship with zope schemas. I guess it is possible to define a zope schema that is not persisted and create the tables from it. It did not seem to me a good way of using CA. How are you managing this part of things. fwiw, ore.alchemist and now z3c.dobbin integrates zope.interface and zope.schema with sqlalchemy, each taking a quite different approach. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3 on Google AppEngine
David Pratt wrote: Hi Malthe. z3c.dobbin looks quite good and transparent. In my opinion, this is much closer to what integration ought to look like for CA. BTW, I noticed that z3c.dobbin is zpl but ore.alchemist that it depends on is gpl. I think all the other zope flavors of sqlalchemy are under zpl. I believe there was a recent effort to bring the sqlalchemy flavors together under a single package. Not sure what progress has been made. It's progressing, but we've also talked to Kapil about relicensing ore.alchemist to LGPL or ZPL, whichever is enough. In any case, this direction looks like a good one. It would be interesting if dobbin could map for storm but it appears to rely heavily upon ore.alchemist. I think it's more accurate to say that both rely heavily on SQLAlchemy. We're actually not using the table reflection functionality of ore.alchemist because we've taken a different approach to it (joining on minimal interfaces rather than mapping classes to tables). What we are using is some of the zope.schema to sqlalchemy.Column mappings and the database session environment. I believe storms advantage is that it is faster than sqlalchemy since it doesn't have to worry about pooling connections, mappers, and more. I'd be interesting to see a similar approach with storm. Good job on this. Thanks, I think we might've found a good approach. Currently we're test-driving it in the Vudo project. So far so good. I don't know much about storm; at this point I must say that I care more about ease of use, mindshare and stability than just speed; we feel that SQLAlchemy gives us that. Add to it that their community is absolutely great. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope3 on Google AppEngine
David Pratt wrote: Hi Malthe. Kapil has confirmed the licensing is ZPL with a version bump to 0.5.2 with a change in the headers, etc. I am anxious to experiment with dobbin since it looks so straight forward and nice. I guess I see traversal and containers as possible issues but will be interested in potential solutions. Trails for grok is one possible solution for traversal but will be curious to see approaches for replacing containers. You're right on the mark here. We haven't yet experimented with traversing, and although it's reasonably trivial to implement it naïvely, thought could be put into coming up with a more efficient solution. Zope's traversing model is attractive, especially since inheritance plays such an important role. In a relational database, it's expensive, but if extensive traversing can be avoided, perhaps it's still reasonable. We're trying to put this matter a bit in the background right now, as there are other, more important tasks to look at first; but it's certainly something we need to decide on. At any rate, adding container-support to dobbin would be a great start. I had the idea of using the ``contains`` pragma from zope.app.publisher to spell out containment behavior. I think this fits well with the general declarative machinery in Zope. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout Builder: Call for Ideas.
Kenneth Miller wrote: Any and all feedback is appreciated and I will carefully consider every idea. For your application: A major drawback is that the underlying architecture relies on setup file based configuration. Does it, and is it? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout Builder: Call for Ideas.
Malthe Borch wrote: For^D^D^DFrom your application... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Splitting up zope.app.container
The ``constraints`` module in zope.app.container seem to be usable outside a ZODB-application---ditto most of the interfaces. If we want to support a nozodb-environment, it would be nice to not have to pull in ZODB just to get these frameworky definitions. Is it package overkill to move these out to, say, zope.container? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Exception verbosity in CA
Some motivation: File .../zope/interface/adapter.py, line 482, in queryMultiAdapter result = factory(*objects) TypeError: __init__() takes exactly 2 arguments (3 given) Perhaps the need for introspection tools would not be so immediate if the exceptions were more informative; for instance, in the example above, why not print the repr of the factory having problems. Or better, use the ``inspect`` module to show what the factory expects in terms of parameters and list the ``*objects`` passed to it. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Five and browser-oriented components
On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. The effect of having Z2-developers import from Products.Five is that they must opt out on packages that make use of templates, browser views, formlib, ... --- and it adds needless complexity. This split might also have prompted the Plone community to walk their own way to the extend that there isn't much code reuse outside of the core Zope packages (along with egg dependencies, but with our fake eggs, we're almost up to par here). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Daniel Nouri wrote: Therefore, I'd argue that we should, in contrary to what you suggest, make the Zope 2 compatibility layer more explicit in the form of utility functions, instead of more implicit. Because it makes things more transparent and easier to debug. You might be right; but it's a very bad place to be, stuck in the middle of two frameworks. We're duplicating code all over the place, and while this has obvious inherent qualities, it also wears us out as a community. I fail to understand why people are not more motivated to get rid of all the cruft. There are times when I wish the ship would sink, if only to get on with it. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: GSoC proposal
On 07/04/2008, Chris Withers [EMAIL PROTECTED] wrote: ...and I'll bet that's only to run the tests, so should be removed as a hard dependency Actually, only the tests require it –– sorry :-) Now, does anyone want me to set up a Launchpad project for this? How do I go about building a Python 2.5 egg and/or a Python 2.5 windows binary installer? What would the project be about then, if it indeed does work? \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: GSoC proposal
On 07/04/2008, Chris Withers [EMAIL PROTECTED] wrote: I'd certainly be up for championing making RestrictedPython available as a seperate project. Has anyone done any work towards this or should I go ahead and get a project / bug tracker / etc set up at Launchpad? RestrictedPython depends only on zope.testing. Also, do we have any clarity on whether or not RestrictedPython works in Python 2.5? I thought that was the one big nasty that didn't get done in last years GSoC project... valga:~/co/RestrictedPython mborch$ python2.5 bootstrap.py Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c8-py2.5.egg Creating directory '/Users/mborch/co/RestrictedPython/bin'. Creating directory '/Users/mborch/co/RestrictedPython/parts'. Creating directory '/Users/mborch/co/RestrictedPython/develop-eggs'. Generated script '/Users/mborch/co/RestrictedPython/bin/buildout'. valga:~/co/RestrictedPython mborch$ bin/buildout Develop: '/Users/mborch/co/RestrictedPython/.' Unused options for buildout: 'download-directory'. Installing interpreter. Generated interpreter '/Users/mborch/co/RestrictedPython/bin/python'. Installing test. Generated script '/Users/mborch/co/RestrictedPython/bin/test'. valga:~/co/RestrictedPython mborch$ bin/test Running unit tests: Ran 42 tests with 0 failures and 0 errors in 0.412 seconds. valga:~/co/RestrictedPython mborch$ \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: GSoC proposal
ranjith kannikara wrote: I am a student participating in Google Summer of code 2008. My proposal to the Zope foundation is to port Zope2 to Python2.5. I am aware of the works done earlier for porting Zope3 and the issue like restricted python implementation. Please give some suggestions on this project. Zope's not the only ones doing a restricted python implementation. It might be interesting to see what's out there. Then there's the AccessControl-module which has a C-implementation; it would need to be ported as well. (Asking to the room), is it out of reach to simply migrate to zope.security (which already runs on Python 2.5)? Obviously there are differences between the two to the extent that some features simply can't be implemented. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: GSoC proposal
On 04/04/2008, Chris Withers [EMAIL PROTECTED] wrote: zope.security uses RestrictedPython, iirc... For untrusted python, yes –– but is anyone using this (in Zope 3)? It's integral to most Zope 2 applications of course to allow secure execution of Python scripts, so we will need to port RestrictedPython eventually. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
Stephan Richter wrote: I am very happy about my tests in z3c.form. They demonstrate tests with different audiences in mind. Rightly so; they're excellent and make transition away from formlib easy. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Directory resource factories
Jim Fulton wrote: Thanks for creating this. I just (finally) commented. I've elaborated on that paragraph. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Looking for Google Summer of Code mentors!
Martijn Faassen wrote: I just added a whole range of Grok-related projects to the summer of code page, and only 1 Zope project, so if you want Zope 2 or 3 to be represented in the google summer of code, you might want to consider adding some proposals. :) I just sent a tentative proposal to the gsoc-list. I'd like some feedback before adding it to the page. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Directory resource factories
Jim Fulton wrote: +1. Some more details would need to be worked out. For example, to work for your use case, it would need to be involved in search, or the searching rules would need to be made more powerful, so, when looking for some file name, it is prepared to consider files that have the file name as a base and use some additional extension, as in your example. I would love to see someone work this out. A proposal would be appreciated. I added a proposal here: http://wiki.zope.org/zope3/FileSystemResources \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Directory resource factories
Jim Fulton wrote: +1. Some more details would need to be worked out. For example, to work for your use case, it would need to be involved in search, or the searching rules would need to be made more powerful, so, when looking for some file name, it is prepared to consider files that have the file name as a base and use some additional extension, as in your example. I would love to see someone work this out. A proposal would be appreciated. Sounds about right. There could be two cases, then: 1. A filename has some base extension 2. A filename has some base extension and an additional extension that corresponds to a named adapter, IResourceProvider, deriving from IContentProvider. The default IResourceProvider (registered for '') would simply open the filename and return the contents. I recently added a hack^H^H^H^Henhancement to zc.resourcelibrary to let you specify a custom directory resource factory to work around this limitation so I could have a dynamically generated js file. Very useful. I'll look for the changeset. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Directory resource factories
The z3c.pt-package now provides a template class for plain text files
like .css and .js---using the ${python expression}-syntax.
I'd like to integrate it with browser resources such that
filename.css.some extension for z3c.pt text templates
would be sent through the template engine.
Now, the DirectoryResource-class defined in
zope.app.publisher.browser.directoryresource provides a dictionary of
resource factories for a number of standard file extensions.
Shouldn't this be pluggable using the component architecture? It would
adapt to IResourceFactory.
\malthe
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: zc.resourcelibrary/branches/resources-bundles-branch/src/zc/resourcelibrary/ Implemented resource manager capable of bundling resources based on library intersection and resource c
Christian Zagrodnick wrote: when will this be merged to the trunk and released? Any plans for that? I still need to hook up the resource bundle with the publisher. The implementation hasn't been tested in a browser yet. There might be caveats. I'll try and bring the branch into a fully working state. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: A z3c.jbot without a monkey
Fred Drake wrote: On Jan 18, 2008, at 10:35 AM, Malthe Borch wrote: In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file. Whacky. Sure it's wacky; it's also the only straightforward way to customize Plone at the moment. Is this really a page template problem? It doesn't seem so. I'm not sure of it is, but certainly it's quite logically to want to take an existing template and change a bit, only you don't want to change the original package of course. Point being that the template itself is a very concrete object of interest and it's easy to understand how to customize it. Why not make the separation cleaner? One pattern that we see hinted at in zope.formlib is that views (UI for the logic) reference templates that are registered elsewhere by name. The implementation there suffers in that the templates themselves aren't (so can't be selected based on the skin/layers), but if they're made to be named views of the (logic) view, all the flexibility you describe can be had. Right certainly named templates is one way to do it. The approach I took was assigning canonical names based on the actual location on the file system and the package. I'm not saying it's the right approach, but it's certainly an approach that works well with packages that define skins using ViewPageTemplateFile-objects. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] A z3c.jbot without a monkey
The z3c.jbot package basically offers an easy way to provide template overrides much like zope 2 skins. It addresses the common issue with using a framework that already provides its own skin; you want to be able to easily customize it. In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file. This is of course not optimal, but it works rather well. However, if we routinely switch between different file sources, performance will certainly suffer. This could happen if for instance a template override was registered only for a certain layer (not currently possible, but certainly desirable). At any rate, this could be fixed at the level of the page template implementation. Getting back to the monkey, perhaps it would make sense to formalize the way a template object gets its source file. The template class could adapt to an ``IFileSource`` implementation that would provide a filename. If there was such an entry point, other template implementations such as z3c.pt could also play along. But perhaps the whole idea is symptom treatment and there's no way forward. Comments welcome, especially in the light of PLIP #216 in which the z3c.jbot approach has been selected for inclusion in Plone*. *) http://plone.org/products/plone/roadmap/216 \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: z3c.jbot/ Initial import.
But I also have a question. Should we not use another namspace for Zope packages which depend on Five or other packages then zope.* or z3c.*? The package makes no assumptions that Five is available, but there are tests for a scenario where it is. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Duplicate directive registration allowed
I agree with your analysis. Could you file a bug report in launchpad? Bug now filed: https://bugs.launchpad.net/zope3/+bug/162166. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
