Hi,
I'd like to have a new ssh public key installed for svn access to
svn.zope.org. Whom would I need to send it to? The web interface says
webmaster at zope.org but that doesn't seem to get me a response. Thank
you.
--
Thomas
___
Zope-Dev maillist
Hi Tres,
thank you for your reply, everything works fine now.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
://namespaces.zope.org/zope', u'subscriber') -
- % -
I think Thomas Lotze added this file yesterday. I think it likely needs
to have the following near the top::
include file=meta.zcml package=zope.component/
This not entirely correct. The file has
First of all, please excuse the long time without a reply - I spent the last
two weeks sick.
Jim Fulton wrote:
On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe l...@lrowe.co.uk wrote:
I would say that javascript and client side programming frameworks are
out of scope for Zope the project. There
Jim Fulton wrote:
but I would hope that we wouldn't contradict the decision, made some time
ago that Zope, unless qualified (as in Zope Community or Zope
Toolkit), refers to Zope 2. If we did, it would have been because we
were speaking informally.
Agreed.
I'd like to pursue this by
Thomas Lotze wrote:
To get the discussion started, I'll give a few random examples of
functional areas that we thought of immediately:
- software architecture (interfaces, components)
- data persistence (ZODB)
- URL resolution (object traversal)
- form generation (form libs for HTML forms
Hi all,
at the Zope summit in September, we were talking about what Zope
actually is or should be and how to define the goal of the Zope
project. This led to the idea of identifying the functional areas
of Zope. I'd like to pursue this by starting a discussion about
Zope's functional areas among
Hi,
this is a long message with a lot of replies to things that I don't agree
with. Since I realize that making those points over and over again doesn't
get us anywhere, I'd like to point out first that I'm going to implement
Martijn's suggestions anyway on one of my branches, hoping that seeing
Chris McDonough wrote:
Thomas Lotze wrote:
Because then, if you use third-party code that uses
zope.interface.Interface and other code (third-party or your own) that
uses the subclassed interfaces, you'll have to deal with both types at
the same time in your client code. You could use
Chris McDonough wrote:
I'll throw out the obvious...
Why not subclass Interface in zope.component and make the required API
additions there? If it were anybody but us thinking about doing this,
they'd probably just subclass.
Because then, if you use third-party code that uses
Martijn Faassen wrote:
Hey,
Tres Seaver wrote:
[snip]
Any code today which wants a utility is calling 'getUtilty' (if it
*knows* the utility must be registered) or 'queryUtility' (if it thinks
it might not be). Less facetiously than my first challenge: please
point to actual code in the
Martijn Faassen wrote:
Here's a summary of what has been going on in this thread with some
attempts at conclusions that have support of the consensus so that Thomas
can proceed
Thank you, half an hour later and I'd have written the summary ;o)
* We want to implement .adapter(), .utility()
Martijn Faassen wrote:
Thomas Lotze wrote:
Martijn Faassen wrote:
* have dummy implementations in zope.interface that raise
NotImplementedError
That would still introduce too many zope.component concepts into
zope.interface IMO: obviously that of utilities as one of the dummy
methods
Thomas Lotze wrote:
I'm
not sure whether we should make the name of that parameter consistent
between zope.component and zope.interface,
Sorry, nevermind. Of course we'll want to rename that parameter as our
secret plan is to access the ZCA through Interface.__call__ one day.
--
Thomas
So we've decided to let interfaces grow `adapt` and `utility` methods. I've
written a simple and straight-forward implementation of them (see the
tlotze-component-API branches of zope.interface and zope.component) that is
closely modelled on the exisiting `__call__`. In particular, the new methods
Martijn Faassen wrote:
* The hook invokes the `query*` functions to play nice with any other
component hooks and the interface methods raise a TypeError if all of
them fail to find a component.
A TypeError instead of a ComponentLookupError?
I was thinking we should keep the behavior
Lennart Regebro wrote:
I'm +1 on this decision, and would also like to announce that I have
cleaned up my Python3 compatible branch of zope.interface. Even though the
decision now is to only add new stuff and not break any backwards
compatibility I think adding the Python 3 support into 4.0
Gary Poster wrote:
I would think we would want to follow the pattern of the adapter_hooks in
zope.interface.interface, including the C optimizations.
Speaking of adapter hooks: If I'm not completely mistaken, adapter hooks
know about exactly one object to be adapted. To follow the pattern of
Martijn Faassen wrote:
Thomas Lotze, are you happy enough with this to still help with the
implementation?
I am indeed. This isn't the ideal solution I had hoped for, but it is a
big step in a good direction from my point of view and I don't see any
part of it that might take us away from
Gary Poster wrote:
I don't know if too much experimentation is needed for this in particular.
I would think we would want to follow the pattern of the adapter_hooks in
zope.interface.interface, including the C optimizations.
I would be comfortable with you leading the effort, in a shared
Gary Poster wrote:
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote:
On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze t...@gocept.com wrote:
To be honest, I just don't see why this whole singleton business
shouldn't be orthogonal to the concepts of the component architecture.
Well said
Martijn Faassen wrote:
* a utility never has a connection. That's because it already got
instantiated long before the lookup takes place.
Isn't it the other way around: A utility never has a connection to any
adapted object, and that's *why we can* instantiate it long before the
lookup takes
Gary Poster wrote:
Without this distinction, AFAICT either you want to conflate the ideas, or
you have a concept of the differences between the two that is more
esoteric than I think is useful. I get the impression that it is on the
second point of those that we disagree.
Right, I
Chris McDonough wrote:
Furthermore he'll believe he owns the resulting object, because normal
classes are always constructors that create a new object.
Except when they don't. Apart from cases like short strings and small
integers where Python itself doesn't create objects more than once, you
Lennart Regebro wrote:
On Sat, Nov 28, 2009 at 16:39, Charlie Clark
The
most common example I know of the syntax is with INameChooser() which
brings us back to the differences (real or imaginary) between utilities
and adapters.
I agree that calling an interface like that is a strange
Martijn Faassen wrote:
Are people okay with the proposed semantics?
I am.
Would people be okay with such an upgrade path? Any better ideas?
I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y)
but maybe that changes after thinking about it some more.
Most importantly,
Martijn Faassen wrote:
Thomas Lotze wrote:
You didn't explicitly mention the subject of backwards compatibility in
your original message, so let's make it explicit now: Is backwards
compatibility a goal in this discussion?
True. It's indeed a goal, as I'd like to be able to use this sooner
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it
allows us to implement
Benji York wrote:
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I seem to remember there had been some discussion at some point about
dropping
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument
I'd like to see the hard dependency of zope.dublincore on zope.annotation
gone. This would lift the indirect dependency on the ZODB.
zope.dublincore uses zope.annotation in three places:
- For defining the IZopeDublinCoreAnnotatable marker interface which isn't
used in any of the packages
Could somebody please give me PyPI rights for zope.browserresource? I'd
like to release a new version of it which includes the recent fixes to its
dependencies. Thank you very much.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
Stephan Richter wrote:
On Tuesday 24 November 2009, Thomas Lotze wrote:
Could somebody please give me PyPI rights for zope.browserresource? I'd
like to release a new version of it which includes the recent fixes to its
dependencies. Thank you very much.
I am in the process of making you
Martijn Faassen wrote:
Thomas Lotze wrote:
I wonder: should we start requiring that the object passed to setSite()
implement (or even be adaptable to) IPossibleSite?
I think the simplest way forward would be not to change the semantics as
part of this step.
Agreed.
--
Thomas
After having been sick for a week I'm back on track now...
Fabio Tranchitella wrote:
I want to bring the test coverage for zope.component.zcml and
zope.component.security to 100% before asking to merge it back to the
trunk.
I'd like to tackle the move of zope.site.hooks to zope.component
Thomas Lotze wrote:
I'm still going to move the zope.publisher.contenttype functionality to
zope.contenttype which will ease some packages' dependencies,
JFTR: I've done that now, including updates to packages which used to
import from zope.publisher.contenttype.
--
Thomas
Martijn Faassen wrote:
Martin Aspeli wrote:
Hanno Schlichting wrote:
On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen
faas...@startifact.com wrote:
[ztk.cfg] contains a line
allow-picked-versions = false
I agree with Thomas that we should remove this from ztk.cfg, as if we
publish
Martijn Faassen wrote:
Thomas Lotze wrote:
IMO it would be interesting to have the concept of the current site
available separately from the rest of zope.site with its 30
dependencies. (For example, zope.browserresource demonstrates how with
the present zope.site the need to know the current
Thomas Lotze wrote:
I thought about that one briefly, but I don't like it because it
introduces at least some knowledge about the security concept to
zope.component.
The more I think about it, the less evil this appears to me, though. After
all, the zope.component.zcml module has been
Tim Hoffman wrote:
GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security
at all
I did a quick grep and it appears that repoze.bfg never actually loads
zope.component.zcml
so I think if the only dependancies you introduce are via zcml then you
should be ok. And given I am
Thomas Lotze wrote:
I'm still going to move the zope.publisher.contenttype functionality to
zope.contenttype which will ease some packages' dependencies, and I'll try
to move some appropriate bits of code from zope.mimetype to
zope.contenttype.
Before doing so, however, I'd like to release
Fred Drake wrote:
On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting ha...@hannosch.eu
wrote:
If someone would document srichter's magic grant-all-powerful PyPi
script, I'd run it :)
That's a horrible thing to do to somebody!
Note that I'm not smiling, either. It's too easy to grant
I just noticed that zope.testrecorder, which is listed in ztk.cfg as an
included package, imports from Globals, OFS, AccessControl and
Products.PageTemplates. This looks to me as if zope.testrecorder shouldn't
actually be part of the ZTK. It's also not used by any package mentioned
in ztk.cfg.
--
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
In any case, I agree it should be dropped from the ZTK.
+1 on dropping it too.
Done.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No
Thomas Lotze wrote:
At present, zope.contenttype doesn't have any dependencies within the ZTK,
and zope.mimetype depends on zope.configuration, zope.component and
zope.interface. zope.publisher.contenttype doesn't import any zope code.
- Switching packages that depend on zope.mimetype would
Martin Aspeli wrote:
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we use a different name? 'content type' to me sounds
like CMS-y functionality. We
zope.site.hooks is a rather light-weight module that is concerned with
the concept of a current site, where the notion of a site is used in the
same sense as in zope.component, which actually prefers to only talk
about a component registry. In contrast, the rest of zope.site deals with
local site
Martijn Faassen wrote:
Whether ztk.cfg can be reused directly or whether we should extract
something in it with just the version indicators I'm not sure about. I've
noticed when modifying the buildout.cfg of the ZTK to add
z3c.recipe.depgraph support that I had to pin down *everything* that
Martijn Faassen wrote:
So I'd propose the following development process:
* developers can change the version numbers in the ZTK
* if the compattests all run, they can check in
I'll go ahead and update the KGS with my proposed new versions then; if
someone experiences a problem with this,
Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype and zope.publisher.contenttype.
- zope.contenttype does
Tres Seaver wrote:
Thomas Lotze wrote:
Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype
Martijn Faassen wrote:
Thomas Lotze wrote:
I just noticed that zope.site depends on zope.app.publication, both via
configure.zcml and the tests. The dependency isn't currently declared.
On the other hand, zope.app.publication doesn't yet depend on zope.site.
I'd like to get rid
Martijn Faassen wrote:
Thomas Lotze wrote:
I think I'll release the current zope.error later today so people get
the benefit of the lighter dependencies.
Given you access to this too. :)
Thank you, I've just made the release.
--
Thomas
Tres Seaver wrote:
- zope.error depends on zope.container solely in order for the error
reporting utility to be able to subclass Contained, which in turn
calls itself a silly mix-in class. Also, zope.error makes no use of
the fact that the utility is Contained. Should the Contained
Martijn Faassen wrote:
Thanks for doing this analysis! It'd be great if you could turn this into
a proposal for future actions...
Do you mean a proposal that would go in the Proposals section of the ztk
docs?
I'm surprised about the difference in dependencies between zope.file and
- The last release of zope.error doesn't have all dependencies declared
while work has been done on the trunk to fix that. Is there a specific
reason why no new release has been made since?
- zope.error depends on zope.container solely in order for the error
reporting utility to be able to
Thomas Lotze wrote:
I've considered all packages mentioned in the current ztk.cfg that come
from the zope.* namespace. [...]
Come to think about it, I'm not sure whether and how far I should
investigate beyond the ztk for removals like this; are there zope.*
packages in the repository
I just noticed that zope.site depends on zope.app.publication, both via
configure.zcml and the tests. The dependency isn't currently declared.
On the other hand, zope.app.publication doesn't yet depend on zope.site.
I'd like to get rid of the dependency of zope.site on zope.app.publisher
and I
Michael Howitz wrote:
Am 23.09.2009 um 08:06 schrieb Thomas Lotze:
I just noticed that zope.site depends on zope.app.publication, both via
configure.zcml and the tests. The dependency isn't currently declared.
On the other hand, zope.app.publication doesn't yet depend on zope.site.
I'd like
Martijn Faassen wrote:
* zope.contenttype: we should analyze what is using zope.contenttype.
Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file
and zope.app.onlinehelp are. There's also zope.mimetype which seems to be
concerned with the same subject and is used by
Martijn Faassen wrote:
Sounds like you did the research.
I've considered all packages mentioned in the current ztk.cfg that come
from the zope.* namespace. The BBB stuff from zope.location.pickling is
neither used by any of them, nor do compat-tests involving the pinned
versions of those
I asked about this before; let me do so again before assuming silence to
mean consent:
There's a PathPersistent class in zope.location.pickling which is
decorated with a recent BBB comment, and had been questioned by a XXX
comment for some time before that.
The class doesn't seem to be used
I asked this a month ago without getting any responses, so I'll give it
one more try:
We recently ran into an issue with debug/development mode when making
z3c.hashedresource work with Zope2: The package implements different
behaviour depending on whether the dev-mode feature is enabled in the
Andreas Jung wrote:
On 15.09.09 08:00, Thomas Lotze wrote:
- Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e.
should the two be linked to each other in the first place?
What is the ZCML dev-mode?
It's a so-called ZCML feature that can be used with ZCML conditionals
Andreas Jung wrote:
I can not remember having seen any support this feature. If you need it,
please add it to the Zope 2 trunk
I'll see about it ASAP.
(however too late for the Zope 2.12 release, sorry :-))
That's fine.
--
Thomas
___
Zope-Dev
Adam GROSZER wrote:
If you're thinking of testing the ZTK KGS packages, there shall be
buildbots for that soon running tests on the (supported OSs x supported
Python versions) matrix.
While this is nice, I think it's also a good idea to make it easy for
developers to run all relevant tests
What's the oldest Python version the ZTK is supposed to support? 2.4?
The ZTK docs don't seem to say anything about this.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or
Martijn Faassen wrote:
Good point. I think right now the ZTK is supposed to support 2.4 to 2.6
(thanks to Jim's work in particular to fix it). I've added this to the
Zope Toolkit documentation now, under development process.
Maybe there should also be a standard way of executing tests for all
Encolpe Degoute wrote:
Can I add it in the trunk or does anybody want a branch ?
Do it on a branch, even if it seems trivial. At least you'll want to run
the tests on different systems before modifying the trunk, which will be
easier when you can check the changes out from a branch.
--
Thomas
Wichert Akkerman wrote:
The latest zc.recipe.cmmi release started using the zc.buildout download
API but does not depend on zc.buildout 1.4 or later, which broke several
buildouts for me. I've fixed the dependency in r103703. Can someone make a
new release?
Done.
--
Thomas
While wondering about the ITraverser interface being defined by
zope.location, we noticed that the zope.location.pickling.PathPersistent
class (which is this package's only user of the interface) is decorated
with a recent BBB comment, and had been questioned by a XXX comment for
some time before
Encolpe Degoute wrote:
As zc.buildout is using something near string.template I patched
gocept.recipe.env to replace '$' by '$$' and collective.recipe.template to
replace '$$' by '$'.
For the record: gocept.recipe.env hasn't yet been patched; I'd rather
discuss the issue first before applying
Martijn Faassen wrote:
One question to ask is whether getParent and getParents are used all over
the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about removing them.
getParent is
There are two functions in zope.traversing.api, getParent and getParents,
that are rather closely related. The former is implemented right in that
module while the latter adapts its argument to
zope.location.interfaces.ILocationInfo and calls getParents() on that.
Why is getParent not a part of
We recently ran into an issue with debug/development mode when making
z3c.hashedresource work with Zope2: The package implements different
behaviour depending on whether the dev-mode feature is enabled in the ZCML
of a Zope3 application, and we sort of expected this feature to be
automatically
We've started a new package, five.hashedresource, that is supposed to
integrate z3c.hashedresource into Zope2. Just to make sure not to step on
someone's toes: is it OK to just create such a package in that namespace?
--
Thomas
___
Zope-Dev maillist
Benji York wrote:
I've just released the first beta of Manuel, my next-generation doctest
project.
Many thanks for the ideas and work you put in manuel!
I'm interested in any feedback and/or questions you may have be it
technical, documentation, or marketing (i.e., how do I describe what
Jim Fulton wrote:
Speaking for myself, I'd be happy to change my code to comform to a
python-standard request API assuming that it had enough in it to adapt it
to existing APIs.
Without having used it myself yet, and without making any claim about it
being a Python standard, this makes me
release.
Viele Grüße,
Thomas
--
Thomas Lotze · t...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
signature.asc
Description: PGP signature
Thomas Lotze t...@gocept.com schrieb:
Yes, and I think that we're talking about two steps here anyway. I'd
like to finish and release a version that uses BLists ASAP;
Well, I think the switch to BLists is finished, so I'd be ready to
merge it to the trunk after someone reviewed the changes
right now anyway in
production?
No idea...
Generation code is hard to test in the abstract.
Do we actually have any best practices for that?
Viele Grüße,
Thomas
--
Thomas Lotze · t...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel
Jim Fulton wrote:
I would change it to just use getattr rather than hasattr.
try:
getattr(ob, name)
except AttributeError:
return False
...
Given the controversy about our original proposal, I think I'll just
implement Jim's suggestion. I'll do so as soon as possible.
--
Thomas
(probably a bug).
I don't understand what you're saying in that last sentence; can you
elaborate?
Viele Grüße,
Thomas
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
a method (declared by the interface) is implemented by a property.
Ah, I see. Thank you.
Thomas
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting
'def m(self):'?
- to win an obfucated-code contest
- to get an additional closure for the method that is created each time
the method is accessed
Viele Grüße,
Thomas Lotze
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http
than to avoid the case of a happy verifyClass() call
with the application dying of a forgotten attribute implementation.
Could there be classes we subclass that claim to implement an interface
but don't fully do so until after instantiation? Just a guess...
Thomas
--
Thomas Lotze · [EMAIL PROTECTED
on the object's class if the hasattr() test
returns False.
Are there any objections against modifying verifyObject in this way?
Thomas
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889
its value.
Thomas
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
signature.asc
Description: PGP signature
Gary Poster wrote:
[zc.blist]
To release it responsibly now, someone needs to claim maintainership.
As I was the one asking in the first place, I'm willing to do this unless
there's a policy for zc.* packages to be maintained by ZC people or
something similar.
--
Thomas
Tres Seaver wrote:
Thomas Lotze wrote:
Oh well, it turns out that this doesn't really work well as the class in
question is used as a base class by all the items edit widgets. The
next-best approach we'd try would be a module-global flag that turns the
old behaviour back on and must be set
Thomas Lotze wrote:
Roger Ineichen wrote:
Since this is a miss behavior and I agree that this should get fixed. We
probably should think about a solution which supports the old behavior
by default.
Note, this whould probably also break other packages like
z3c.csvvocabulary.
We've
that the no
value value isn't shown for required fields that already have a valid
value set. What do others think about this?
Viele Grüße,
Thomas Lotze
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345
asked
for this behaviour, for example. If noone objects, we'd like to change
zope.app.form accordingly.
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone
that
application of yours that you've refered to earlier? Who has to migrate to
z3c.form, and how does this affect the development of zope.app.form?
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0
Just to note: I received a warning
'post-commit' hook failed with error output:
(with no output, though) after committing to svn.zope.org.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No
Thomas Lotze wrote:
0.8.1 is out now. It doesn't do any whitespace stripping anymore.
And 0.8.2. It doesn't do any failing on a content tpe of None anymore...
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman
Thomas Lotze wrote:
OK, then we agree. Good that I did zc.resourcelibrary 0.8, not 1.0
yesterday ;o)
0.8.1 is out now. It doesn't do any whitespace stripping anymore.
--
Thomas
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org
Fred Drake wrote:
On Dec 4, 2007 5:55 PM, Thomas Lotze [EMAIL PROTECTED] wrote:
It wasn't even about whitespace around the / but leading whitespace in
front of the major type.
Wow. It probably didn't occur to me that would be screwed up.
I've now looked up RfC 2045 which states
1 - 100 of 113 matches
Mail list logo
