Christian Theune wrote:
But to be honest, I too often get the feeling that something in the
process is wrong and we are failing to acknowledge it or work on it.
I think we make it way to hard for people who want to use Zope 3 as
developers making applications with Zope 3.
Why? Because we keep c
Christian Theune wrote:
I partially agree on that. This obviously is one issue if you're living
on the trunk or a pre-release branch. It's not clear when to re-read, so
following the checkins is required here.
Yup. But as you said, that's because you're living on the edge.
That's probably my
Dieter Maurer wrote:
Tres Seaver wrote at 2006-9-2 13:03 -0400:
...
I'm OK with having "in-tree" code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that "janitorial deprecation" is way too common in the tree today:
people decide the
Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
It is my impression that it was Zope
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not prefer if these "straight-forward APIs&
Chris Withers wrote:
Philipp von Weitershausen wrote:
That is unfortunate example of obviously bad deprecation. Deprecation
is hard and it requires a great deal of thought. But it can be
manageable in many cases.
Still feels like there's too much fo it happening in the Zope 3 worl
Chris Withers wrote:
Philipp von Weitershausen wrote:
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a non-backwards-compatible change, 'cos it
requires me to rethink and recode, if not now then at some po
Marcus J. Ertl wrote:
tests. We *did* have changes that generated deprecation warnings. But
that's something else.
Not really, that for me is a non-backwards-compatible change, 'cos it
requires me to rethink and recode, if not now then at some point in the
future...
Me too!
That's a real pro
Stephan Richter wrote:
On Tuesday 05 September 2006 07:55, Jim Fulton wrote:
On Sep 2, 2006, at 5:33 AM, Philipp von Weitershausen wrote:
The order of arguments is the same. I think Jim wants the
convenience functions in zope.component (provide*) to go away in
favor of the explicit spelling
Lennart Regebro wrote:
On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Because they'll go away.
Why?
Because it's clutter. And because there should preferrably be only one
way to do things. If we left all the old ways around indefinitely, we'd
have code
Fred Drake wrote:
On 9/5/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
When I remember right, then I read an important sentence in the
Python style guide -- something along the lines: "This is a guide:
you should follow it but there are occasions when you may not do so with
good reasons."
I don
Chris Withers wrote:
Jim Fulton wrote:
I don't think it's a matter of being "bad". It's a matter of learning
from experience. We broke a lot of new ground in Zope 3 and often got
things wrong because we hadn't done them before.
Okay, we're 5 years down the line now, I think it's time to s
Chris Withers wrote:
Philipp von Weitershausen wrote:
Because it's clutter.
I call BS on that :-S
And because there should preferrably be only one way to do things.
Indeed, but why break existing code unnecessarilly?
Call it "BS" or "unnecessary". The re
Christian Theune wrote:
What's your experience with updating your Zope 3 projects, Chris?
I'll also jump in here: We had to try twice to upgrading a commercial
project based on Zope 3.2 when using the 3.3 beta1, because so much
stuff was actually broken in the release.
As you suggest yourself
Florent Xicluna wrote:
Log message for revision 70047:
Make deprecated packages zope.app.layers and zope.app.skins optional.
By the way, a zcml feature 'deprecatedlayers' is added.
Hi Florent,
has there been a proposal for this change? Changes that might affect
backward compability should
Stephan Richter wrote:
On Friday 08 September 2006 03:13, Michael Haubenwallner wrote:
i have a small problem using pydoc to look at the Zope3 source, namely
zope.proxy and modules where zope.proxy is included:
Why would you use pydoc? Any conventional documentation tools are useless in
Zope
Tres Seaver wrote:
Stephan Richter wrote:
On Friday 08 September 2006 04:12, yuppie wrote:
Are there good reasons why these changes were not backported?
I volunteer to backport some fixes I'm missing in Zope 3.2, but that's
no general solution for keeping the current stable branch maintained.
Jim Fulton wrote:
I agree in principle. In practice, I'm not sure we have enough
maintainers to get a release out, let alone maintain two previous
release branches. :( We need more volunteers.
If we want to maintain releases for a year, I suspect we need to release
once a year.
I did Zop
Tres Seaver wrote:
Rocky Burt wrote:
On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote:
Philipp von Weitershausen wrote:
Jim Fulton wrote:
I agree in principle. In practice, I'm not sure we have enough
maintainers to get a release out, let alone maintain two previous
release bra
Christian Theune wrote:
what's the status on the release? We should have an RC and maybe a
release in one or two weeks.
Yup. We will be making an RC this week.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman
Martijn Faassen wrote:
Thanks for doing this work, Christian. I'm in favor of going for Zope
3.4 on a timely basis.
I wouldn't mind that.
Concerning the delay of Zope 3.3, I think we should consider whether
we're not too perfectionistic.
On the one hand core developers seem to be happy to u
Martijn Faassen wrote:
That doesn't mean we should postpone a final release over and over
again, just because we don't have the resources. In fact, because we
don't have the resources, we should release a final anyway and catch
up with bugs in, well, bugfix releases :).
Yes, the whole idea is
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
That doesn't mean we should postpone a final release over and over
again, just because we don't have the resources. In fact, because we
don't have the resources, we should release a final anyway and
Martijn Faassen wrote:
Hi there,
I understand that the 3.3.0 release is coming out next week.
As the 3.3.1 release manager volunteer, I ask everybody to do the
following:
If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch
first,
No, please fix it in Zope 3.2 first. As fa
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Hi there,
I understand that the 3.3.0 release is coming out next week.
As the 3.3.1 release manager volunteer, I ask everybody to do the
following:
If you find a bug in Zope 3, please try fixing it in Zope 3.3
The Zope 3 development team is proud to announce Zope 3.3.0 rc1.
Zope 3 is the next major Zope release and has been written from scratch
based on the latest software design patterns and the experiences of Zope 2.
Cleanup of the Zope 3 packages has continued to ensure a flexible and
scalable plat
Over the last couple of days we've been discussing Zope's new release
cycle and the release management. I would like to sum up what seems to
be the gist of those discussions:
9 month release period?
---
Several consumers of Zope releases have talked about their experience
Martijn Faassen wrote:
I don't have time for a discussion right now as I'm off to Germany soon.
The one thought that strikes me is that these release management notes,
when finalized, should be in some clear, findable, well-known and
maintained location. Otherwise we'll forget again. I know, th
Stephan Richter wrote:
Hi everyone,
I just noticed that zope.conf.in has now the following entry:
server localhost:8100
storage 1
cache-size 20MB
This means that ZEO has to start up to run Zope after a default check
out/download. When I had no network connection in a hotel
Florent Xicluna wrote:
However i have a worry on the "Fix oldest branch, merge to newer branches".
I guess this is due to my young experience with SVN development.
Currently, I work with 3.3 branch for my company. I checked out the trunk too,
in order to collaborate to Zope development.
So I hav
Stephan Richter wrote:
On Wednesday 13 September 2006 11:02, Florent Xicluna wrote:
Currently, I work with 3.3 branch for my company. I checked out the trunk
too, in order to collaborate to Zope development.
So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare
a fix I do i
Florent Xicluna wrote:
I see that zope.app.introspector "Will be gone in 3.3." [sic].
:(
We should remove it from the trunk.
To help on this, I would like to commit a patch on `trunk` to remove dependency
of API doc on this deprecated package; see below.
If someone want to keep backward com
Gustavo Niemeyer wrote:
Hello everyone,
I was just implementing a ZCML statement for a view-related
component which should also take in consideration request
interfaces for adaptation.
After reading the "SimplifySkinning" proposal form Philipp, I'm
somewhat unsure about how to define the reques
Christian Theune wrote:
Gah.
Mea culpa.
Until recently I didn't know that the zope.conf.in could even be copied
over to zope.conf, because every checkout that I ever used always picked
up the zope.conf and nothing ever told me to copy it. (Although I was
slightly annoyed having to edit zope.con
Stephan Richter wrote:
On Saturday 16 September 2006 05:10, Philipp von Weitershausen wrote:
*If* someone else had that problem too, I'd propose to change away from
the fallback of using zope.conf.in (we force people to create the
principals too, don't we?)
Right. I wouldn't min
Stephan Richter wrote:
On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote:
Contributing to a community also means adapting to its processes and way
of working. The process has been working well for Zope 2 developers, so
I don't see why it can't work for Zope 3.
A
Florent Xicluna wrote:
Log message for revision 70213:
Deprecate directive .
Remove deprecated directive .
Hi Florent,
a few comments:
Modified: Zope3/trunk/src/zope/app/component/contentdirective.py
===
--- Zope3/trunk/src/
Chris Withers wrote:
Florent Xicluna wrote:
Gone in 3.4
http://mail.zope.org/pipermail/zope3-checkins/2006-September/028478.html
Any idea which version of Zope 2 that corresponds to?
2.11, to be released next year (May or so).
Chris - hey, isn't it time we merged the Zope 2 and Zope 3 cod
Chris Withers wrote:
Philipp von Weitershausen wrote:
I think that after eggifying Zope 3 in 3.4 and introducing some
features in Zope 2.11 that makes us not depend on Zope2isms like
Acquisition (while they'd still be available for those who want to use
them), we should invest into the Z
Simon Hang wrote:
How about below changes?
There aren't many of us who know the zope.server code that well,
unfortunately. This is one of the reasons we want to "get out of the
server business".
That said, it would *much* easier to understand what you're trying to do
if you provided *unifi
Hi Simon,
I have a few comments regarding style. First::
if thisflag == False:
...
is unnecessarily long. Just write::
if not thisflag:
...
Also, what is "thisflag"? It'd be better to give it a descriptive name.
--- httptask.py.origFri Jan 06 02:15:48 2006
+++ httptask.p
Tres Seaver wrote:
How should I do things such that they can do that?
I'm just wondering whether you really need the disabling feature.
I've wanted it.
Okay :).
My major beef with the way we are *using* ZCML now is
that we expect package authors to provide policy-laden configuration for
th
Tres Seaver wrote:
We do "eager" checking of dotted names (during the parse), which makes
it impossible to write a directive which synthesisizes the target of a
dotted name without side-effects (e.g., the 'five:bridge' directive).
If we delayed the check until after parsing was complete, then we
Looks better now. I suggest filing a collector issue and attaching the
patch. Somebody knowledgeable can then look at it.
Simon Hang wrote:
Philipp,
Sorry for being lazy, and thanks for the tips. Here is my update version.
--- httptask.py.origFri Jan 06 02:15:48 2006
+++ httptask.py Fri Se
Wolfgang Schnerring wrote:
Hi,
I just refactored zope.decorator into zope.proxy.decorator and
zope.security.decorator as discussed in
http://thread.gmane.org/gmane.comp.web.zope.zope3/18581.
Contrary to that discussion, Theuni and I thought that the
*DecoratorBase classes are actually useful be
Wolfgang Schnerring wrote:
* Philipp von Weitershausen <[EMAIL PROTECTED]> [2006-09-22 10:01]:
However, when I tried to refactor zope.location.location.LocationProxy
to use said base classes, it broke the functional tests for
zope.app.apidoc.introspector -- for reasons I totally
Jim Fulton wrote:
Uh, why are we parsing the entries file?
To get the current revision of the Zope 3 checkout...
mkzopeinstance.py fails with;
...
File
"C:\Python24\Lib\site-packages\zope3\src\zope\app\applicationcontrol\zope
version.py", line 68, in __setSVNVersion
doc = parse(entriesf
Jim Fulton wrote:
On Sep 22, 2006, at 1:31 PM, Stephan Richter wrote:
On Friday 22 September 2006 12:52, Martijn Faassen wrote:
I hope we can move to a pattern where projects gain a homepage somewhere
on zope.org, including doctests and some other information, and the
cheeseshop is used for e
Fred Drake wrote:
On 9/22/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Right. Or in old-skool distutils world, you can use a setup.cfg file:
http://docs.python.org/dist/setup-config.html
Oddly, the setup.cfg file is not used as a source for much of the
metadata passed to the
Wichert Akkerman wrote:
Previously Philipp von Weitershausen wrote:
Jim Fulton wrote:
Uh, why are we parsing the entries file?
To get the current revision of the Zope 3 checkout...
Why not use svn info --xml?
or even just "svn info"...
I think we (Christian Theune and I) chose
Stephan Richter wrote:
the following helper functions in zope.app.component do not work well with the
new registry concept of bases: getNextSiteManager, queryNextSiteManager,
getNextUtility, queryNextUtility.
Those methods expect a simple lookup tree, where the first base of a local
registry
Baiju M wrote:
On 9/26/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
On Tuesday 26 September 2006 03:11, Philipp von Weitershausen wrote:
> > The really big question is: Is that change worth porting to the
Zope 3.3
> > branch?
>
> If you're talkign about get/
Brian Sutherland wrote:
On Tue, Sep 26, 2006 at 11:08:54AM +0200, Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Tuesday 26 September 2006 04:14, Baiju M wrote:
Can we change `ClientForm` from a file based module
to a package. So that others can set it as svn:external
Stephan Richter wrote:
On Tuesday 26 September 2006 04:14, Baiju M wrote:
Can we change `ClientForm` from a file based module
to a package. So that others can set it as svn:external (Zope 2 ?)
Let me do it in trunk?
No, we are not maintaining ClientForm, so we do not have this fre
Chris Withers wrote:
Hi All,
Just been wondering about the need to retrofit:
notify(ObjectModifiedEvent(self))
...into lots of code. Can we do anything less intrusive?
I mean, if a non-Zope object has changed, why should it have to think
about emitting events?
Objects don't send events abo
On behalf of the Zope 3 development team I'm proud to announce the final
Zope 3.3.0 release. There were no changes since the 3.3.0 release candidate.
Zope 3 is the next major Zope release and has been written from scratch
based on the latest software design patterns and the experiences of Zope 2.
Christian Theune wrote:
Morning,
Baiju M wrote:
Hi,
What is the target Python version for Zope 3.4, is it Python 2.5?
Right now it's still Python 2.4, as Zope 3.4 is scheduled for next year,
we should consider using Python 2.5 though.
We should definitely try to *support* Python 2.5, but
Christian Theune wrote:
Hi,
Baiju M wrote:
On 9/28/06, Christian Theune <[EMAIL PROTECTED]> wrote:
Please provide fixes and tests on the trunk and the 3.3 branch.
What about 3.2, dropped ?
Of course you can provide them for 3.2 as well. I'm not sure whether
it's officially maintained anymo
Christian Theune wrote:
Hi,
I saw some updates in the wiki tonight and thought I'll catch up with
some stuff too.
As I opted to take care for the Zope 3.4 release and Zope 3.3 is out of
the door since yesterday, I've updated the roadmap.
(Someone correct me if my information is out-dated)
Cur
Christian Theune wrote:
Hi,
Philipp von Weitershausen wrote:
Christian Theune wrote:
Hi,
Baiju M wrote:
On 9/28/06, Christian Theune <[EMAIL PROTECTED]> wrote:
Please provide fixes and tests on the trunk and the 3.3 branch.
What about 3.2, dropped ?
Of course you can provide th
Philipp von Weitershausen wrote:
Christian Theune wrote:
Hi,
Philipp von Weitershausen wrote:
Christian Theune wrote:
Hi,
Baiju M wrote:
On 9/28/06, Christian Theune <[EMAIL PROTECTED]> wrote:
Please provide fixes and tests on the trunk and the 3.3 branch.
What about 3.2, dropped
Christian Theune wrote:
Hi,
Philipp von Weitershausen wrote:
I want to make most of the browser:* directives saner in implementation,
without actually changing their behaviour, though. Unless people want to
make their behaviour saner, too ;).
I wouldn't mind making myself behave
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Christian Theune wrote:
Morning,
Baiju M wrote:
Hi,
What is the target Python version for Zope 3.4, is it Python 2.5?
Right now it's still Python 2.4, as Zope 3.4 is scheduled for next year,
we should consider using Pytho
KLEIN Stéphane wrote:
2006/9/27, Philipp von Weitershausen <[EMAIL PROTECTED]>:
On behalf of the Zope 3 development team I'm proud to announce the final
Zope 3.3.0 release. There were no changes since the 3.3.0 release
candidate.
...
Thanks goes to everyone who contributed.
T
Motivated by a Zope 2.9.5 release this weekend, I'll be creating a 3.2.2
bugfix release this Saturday. I encourage everyone to get bugfixes into
the 3.2 branch till then, especially if you've fixed a bug in Zope 3.3
recently (e.g. one of the bugdays) and haven't backported it yet.
By the way,
Adam Groszer wrote:
Hello Philipp,
BTW, correct me if I'm wrong, bugfixes go into:
/repos/main/Zope3/branches/3.2
and
/repos/main/Zope3/branches/3.3
... and the trunk. Correct.
Releases get built from:
/repos/main/Zope3/tags/Zope-3.2.2
and
/repos/main/Zope3/tags/Zope-3.3.1
Yup.
___
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-28 11:22 +0200:
...
The last time this was discussed with Jim, the idea was to try to use
Zope 3's security proxy approach in Zope 2 for Python Script security
- Jim and I had some ideas I need to dredge up from the back of my
Christian Theune wrote:
Hi,
as I stumbled over this recently, I'd like to bring this up for discussion:
There is an interface called IWriteFile in the module
zope.filerepresentation.interfaces.
It defines one method "write(data)" with the doc string:
"Update the file data"
There are some pro
Benji York wrote:
Christian Theune wrote:
We probably have to. But to be honest? I totally understand every
programmer that will ask us "WTF?!?". Does anybody see a better way out
of that situation without deprecating anything again?
I don't. As far as I can tell, this is a deceptive API and
On behalf of the Zope 3 development team I have just released Zope
3.2.2, a bugfix release for the 3.2.x line.
Downloads
-
http://zope.org/Products/Zope3/3.2.2
Installation instructions for both Windows and Un*x/Linux are now
available in the top level README.txt file of the distributi
Adam Groszer wrote:
Hello Martijn,
Thursday, October 5, 2006, 6:34:11 PM, you wrote:
I actually reported this issue for Zope 3.2.1 earlier this week. It's
very unfortunate that Zope 3.2.2 went out of the door shortly afterward
without a fix for this. :( I see you found the issue too:
The 3.2
Adam Groszer wrote:
Hello Philipp,
Friday, October 6, 2006, 9:06:39 AM, you wrote:
I'm suspecting that Adam, who built the 3.2.x releases, was executing
the wrong command when building the tarball, because zope.conf.in on the
3.2.x branch doesn't contain the formatter line. It's zope.conf.in o
Adam Groszer wrote:
Hello Philipp,
Thanks Baiju.
It looks like the instructions aren't complete here. You should be
specifying -r 3.2.2 here so that it looks at the tag.
Lot better :-) now it works. Now I start the upload.
Don't forget to close the issue once the .exe is published ;)
_
Chris Withers wrote:
Hi (yet) again ;-)
class MyLayer:
@classmethod
def setUp(self):
self.app = Testing.ZopeTestCase.Zope2.app()
@classmethod
def tearDown(self):
Testing.ZopeTestCase.close()
Shrug! That will modify the class! "self" is the class here (it's
convention to call
Chris Withers wrote:
Philipp von Weitershausen wrote:
What do I put in place of the ? to get hold of the layer's app?
self.layer.app
but self.layer is a string, no?
Huh? No, it's the layer object (e.g. the class)
___
Zope3-dev ma
Chris Withers wrote:
Philipp von Weitershausen wrote:
Chris Withers wrote:
Philipp von Weitershausen wrote:
What do I put in place of the ? to get hold of the layer's app?
self.layer.app
but self.layer is a string, no?
Huh? No, it's the layer object (e.g. the class)
even
Jim Fulton wrote:
At:
http://dev.zope.org/Zope3/ZopeConfigurationProcessingAndSideEffects
I've written an informational proposal stating the goal for
eliminating side effects, other than import, during the first phase
of configuration processing and generally minimizing first phase
processing
Jim Fulton wrote:
I've created a small proposal to add egg support to zope.configuration:
http://zope3.zwiki.org/ZopeConfigurationEggSupport
You write:
We are making increasing use of Python eggs for Zope development. We
need to be able to load ZCML from eggs.
That obviously raises th
Jim Fulton wrote:
I've created a proposal to deal with eggifying zope.app:
http://zope3.zwiki.org/LoadingConfigurationFromTheZopeAppEgg
(That's a confusing title for a proposal that deals with eggifying
zope.app, because it seems to me that the configuration issue is just a
minor detail in
Jim Fulton wrote:
Baiju M wrote:
On 10/24/06, Baiju M <[EMAIL PROTECTED]> wrote:
Hi all,
I have created a proposal to _tack eggification_ of zope.*
packages,
which is already started.
http://zope3.zwiki.org/EggificationOfZopePackages
May be I should change the status as IsInformati
Christian Theune wrote:
originally we intended to do a Zope 3.3.1 release in November to get
virtually bug free.
I didn't see any momentum on this. How about a bug day?
Btw: I didn't want to sound rude here to anybody who was fixing bugs in
the last time. I just wanted to express that I didn't
Christian Theune wrote:
What about next week? I don't care so much about the specific day.
I'd be for Wednesday.
Philipp von Weitershausen wrote:
Christian Theune wrote:
originally we intended to do a Zope 3.3.1 release in November to get
virtually bug free.
I didn't see
yuppie wrote:
Looking at the output generated by formlib, I got the impression nobody
cares much about valid output.
formlib's standard template is horrible. zope.app.form's rendering is
much better. I have no idea why formlib uses its own horrid template any
way, it could simply have used wi
Jean-Marc Orliaguet wrote:
Martin Aspeli wrote:
Jean-Marc Orliaguet wrote:
And there is nothing wrong with using inheritance when there is a
'__IS A __' type of relation (e.g. an ordered folder IS A folder IS
AN item, ...), or if there is a HAS_A type of relation (a folder has
items, a chair
Jean-Marc Orliaguet wrote:
Lennart Regebro wrote:
On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote:
Why do you say "extra" ZCML registration? You need that ZCML
registration whether or not you have to write the marker interface...
Sure, but with the marker interface you need only one. You
Chris Withers wrote:
Christian Theune wrote:
The problem you have is to provide a specification for the 'str'
interface.
There are a couple of problems here...
1. str is both a "function" and a "class"
Nope. It's a class since Python 2.2.
2. I was to register the "function" str as an adapt
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Chris Withers wrote:
Christian Theune wrote:
The problem you have is to provide a specification for the 'str'
interface.
There are a couple of problems here...
1. str is both a "function" and a "class"
Nope.
Chris Withers wrote:
Philipp von Weitershausen wrote:
Chris Withers wrote:
Christian Theune wrote:
The problem you have is to provide a specification for the 'str'
interface.
There are a couple of problems here...
1. str is both a "function" and a "class"
N
Chris Withers wrote:
Philipp von Weitershausen wrote:
...hence the quotes. It's a "function" in that I want to use it as an
adapter that doesn't need to be instantiated by a factory before
being used.
All adapters need to be instantiated.
Why?
def myStrAdapter(somet
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100:
...
def myStrAdapter(something):
return str(something)
It instantiates a 'str' object. The 'str' object is the adapter for
'something'.
Huh? This would be a severe terminology
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100:
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100:
...
def myStrAdapter(something):
return str(something)
It instantiates a 'str' object. The 'str' objec
Jean-Marc Orliaguet wrote:
str(123) has the same syntax as IZopeDublinCore(myobj), but semantically
there is nothing in common between the two expressions.
I disagree.
>>> IZopeDublinCore(obj)
is a flexible version of
>>> ZDCAnnotatableAdapter(obj)
Flexible, because a different implemen
Chris Withers wrote:
Chris Withers wrote:
Jean-Marc Orliaguet wrote:
once you have that utility / adapter you should be able to call it like:
converter = getAdapterFor(123, type=IToStringConverter)
strResult = converter.convert(123)
Not quite, what I'm looking to do is more along the lin
Chris Withers wrote:
Philipp von Weitershausen wrote:
Not sure what "official" terminology glossary you're basing this on,
but we often refer to "IZopeDublinCore(myobj)" as the "IZopeDublinCore
adapter" of myobj". Whatever is called to instantiate that
Chris Withers wrote:
>>> provideAdapter(to_date,(str,int),DateTime)
This registers a multi adapter for (a_string, an_integer), like views
are multi-adapters for (context, request). You want to say:
>>> provideAdapter(to_date, (str,), DateTime)
>>> provideAdapter(to_date, (int,), DateTim
Chris Withers wrote:
What's the difference between zope:view, browser:view, browser:page and
browser:viewlet?
It's a mess. Here's the gist:
zope:adapter
Registers an adapter and optionally applies a permission to the
interface that you're adapting to, e.g.::
will cause the adapte
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
browser:view
Like zope:view, except:
* the request type (second adapted object) defaults to
IBrowserDefaultLayer
* the "permission" always applies to 'publishTraverse',
'browserDefault&#
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
browser:view
Like zope:view, except:
* the request type (second adapted object) defaults to
IBrowserDefaultLayer
* the "permission" always
Chris Withers wrote:
Can a named adapter find out the name it was registered with during the
adaptation process?
Nope.
--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: ht
Tom Gross wrote:
the presence of a intid-utility gives a strange behavior when adding
other objects to a zope3 container.
(test attached)
What's the error/failure? Please be more specific as to what the actual
problem is.
--
http://worldcookery.com -- Professional Zope documentation and
201 - 300 of 766 matches
Mail list logo
