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 -
https://mail.zope.org/mail
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
; ConfigurationError: ('Unknown directive',
> u'http://namespaces.zope.org/zope', u'subscriber') -
> - %< -
>
> I think Thomas Lotze added this file yesterday. I think it likely needs
> to hav
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
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
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 wrote:
>> I would say that javascript and client side programming frameworks are
>> out of scope for Zope the project. There are plenty
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 t
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 tim
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
m
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
zope.int
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:
> 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
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__ o
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 I
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
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
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.
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
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 sh
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 t
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 unders
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:
>
> On Dec 2, 2009, at 8:33 AM, Fred Drake wrote:
>
>> On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote:
>>> To be honest, I just don't see why this whole singleton business
>>> shouldn't be orthogonal to the concepts of the compo
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, y
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 st
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 importantl
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 seco
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 in
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 wa
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)
>>
>>
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,
Benji York wrote:
> On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze 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 proj
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.
&
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
https://mail.z
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 menti
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 st
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.con
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 t
Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Hanno Schlichting wrote:
>>> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen
>>> 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
>>
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
*
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.
--
Fred Drake wrote:
> On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting
> 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 people acc
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 doi
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 gi
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 m
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
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* tha
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 m
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 ty
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 tha
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 th
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
>
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
Having worked on and released new versions of a few ZTK packages recently,
I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
there doesn't seem to be an agreed process about this and in an attempt
not to step on anyone's toes, I'd like to ask first whether it is OK for
any de
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 m
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.s
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 Contain
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
- 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 s
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
> zope
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
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 thi
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 zope.fi
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 packag
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 anywh
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-D
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 "f
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 ZCM
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
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
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 HTML
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 t
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 applyi
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
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 enab
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 IL
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 wh
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 t
nipulate the order.
They do.
> 3) How many people are really using the blist 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
Thomas Lotze 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 c
s BLists ASAP; an
additional API can always be added in a subsequent 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
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.
--
a property.
>
> Why would I want to do that, rather than using '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]
plements(I)
>m = property(lambda self: lambda ...: ...)
>
>
> i.e. when 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
h
nce properties (descriptor on the class) may not define methods
> (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)
at it was right now. Do you?
Not really, other 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
e existence of an implementation of
the attribute in question and its successful execution in a given set
of circumstances.
Thomas
--
Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 122988
an AttributeError when trying to produce 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
sign
tor 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 ·
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
___
The documentation of OrderedDict from zc.dict 1.2.1 states that the
current implementation is inefficient for large collections because it
uses a PersistentList to store the order. It also says that a BList which
would be preferrable is not used as it is not yet released.
- What's the state of tho
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
&g
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 othe
plement the new behaviour in such a way 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
erstand what you're saying here. Are you talking about 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 h
elect a value. One of our customers 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 1229
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 c
1 - 100 of 117 matches
Mail list logo
