Paul Winkler wrote:
Rob Miller [EMAIL PROTECTED] writes:
then CMF does it's normal wrapping of these user objects using the
standard
MemberData implementation.
Hmm, right, so then this might still be on-topic here ;-)
Maybe the right thing is for CMF to do a directlyProvides() call in
Daniel Nouri wrote:
Martin Aspeli writes:
Yuppie writes:
but in general that's the way to go. Since z3c.form became the
standard in the Zope 3 world I'd like to see Zope 2 and CMF moving
in the same direction. Unfortunately using plone.z3cform is no
option for CMF because it has a different
Maurits van Rees wrote:
Raphael Ritz, on 2008-05-29:
Not sure whether that's following best practice but here is
how paster/zopeskel generate this at the moment (this is taken
from a custom add-on I'm currently working on):
[EMAIL PROTECTED]:~/dev/paster/incf.applications/trunk$ ls
docs incf
On 29 May 2008, at 11:27 , Wichert Akkerman wrote:
Previously Philipp von Weitershausen wrote:
But personally I like having it inside the main
folder, so in your example above it would be
incf.applications/incf/applications/HISTORY.txt
There's some benefit to that because it'll be part
Charlie Clark wrote:
What I think is still confusing me is:
1) I have created my dedicated skin
2) I have registered a view for that skin
I assumed that by registering the view for the skin, the view would
automatically use the right layer when called.
Views don't use layers. You apply a
Charlie Clark wrote:
Am 28.05.2008 um 13:02 schrieb Philipp von Weitershausen:
Views don't use layers. You apply a skin layer to the request, and
depending on whether the view was registered for this skin layer or
any of the layers that are contained in that skin layer, the view
Charlie Clark wrote:
I've defined and configured a layer and it works when called by ++skin++
traversal but I have problems if I configured views to work with it
explicitly: I get not found errors.
ie.
browser:page
for=Products.Charlie.event.interfaces.IEventDetail
Charlie Clark wrote:
Am 28.11.2007 um 14:03 schrieb Charlie Clark:
class Grid(dict, PortalContent)
...
TypeError: Error when calling the metaclass bases multiple bases have
instance lay-out conflict
Looks like using the old favourite UserDict solve the incompatability
problem.
class
yuppie wrote:
Wichert Akkerman wrote:
A related question is: how do we want to eggify CMF? It seems to make
sense to create one egg for the whole of CMF and a second egg for
GenericSetup.
Why not one egg for each CMF product? Can you please elaborate?
*Why* one egg for each product? We'll
Charlie Clark wrote:
Am 25.09.2007 um 02:05 schrieb Tres Seaver:
I'd like to break the remaining CMF packages out (moving from '/CMF' to
'Products.CMFCore', 'Products.CMFDefault', etc.) and push the 2.1.0 eggs
out, as well as equivalent changes for PluggableAuthService and
PluginRegistry.
Any
On 25 Sep 2007, at 13:20 , Jim Fulton wrote:
On Sep 25, 2007, at 3:40 AM, Philipp von Weitershausen wrote:
Charlie Clark wrote:
Am 25.09.2007 um 02:05 schrieb Tres Seaver:
I'd like to break the remaining CMF packages out (moving from '/
CMF' to
'Products.CMFCore', 'Products.CMFDefault', etc
(Also CCing zope3-dev where the first known working set discussion
started a while ago)
Tres Seaver wrote:
This is the known good problem. I'm pretty convinced that adding some
kind of PyPI subset, where gardeners for a given package set keep
the list of packages / versions known to work well
Jens Vagelpohl wrote:
Andreas Jung is in the process of getting the regular Zope 2 issue
collector moved onto Launchpad. He said the Launchpad guys could move
other collectors like the CMF collector at the same time. The question
is, do we want this?
My vote is -0.5, mostly because I never
David Chelimsky wrote:
I'm using zope 2.7.8 and looking for a means generating a PDF
document. I've googled and looked around a bit but everything seems
rather dated (stuff from 2002).
That means this stuff is only marginally older than your Zope version ;).
What are you all doing to deal
Charlie Clark wrote:
Do you know of a Zope Product that already wraps report lab, or do you
recommend just accessing directly with a script?
I can't think of anything that would do this for you: transforming HTML
to PDF doesn't usually work very well. Reportlab is fairly easy to use
and
Charlie Clark wrote:
I making my first stab at browser views for my iCal support having
finally come up with some templates that seem to produce files that work
with most calendar programs.
I have a couple of questions:
1) should I implement them as BrowserViews calling templates or should I
yuppie wrote:
Philipp von Weitershausen wrote:
yuppie wrote:
Kapil's also right when he says that utilities by principle are
context-less components.
By principle all Zope 3 code might depend on setSite to work as
expected.
setSite() is something that influences the place (= registry
yuppie wrote:
I'm judging by the solution itself *and* by the fact that we made a
decision long ago and released a beta based on that decision. We should
reverse that decision only if we are sure it was a mistake.
I think it was a mistake. It's ok, we all make mistakes. It's good that
we
Sidnei da Silva wrote:
On 3/29/07, Tres Seaver [EMAIL PROTECTED] wrote:
The cheeseshop shows a pytz-2007d version:
http://cheeseshop.python.org/pypi/pytz
I was refering to the version included in Zope.
That's because we're using a stupid vendor import instead of simply
requiring it as
Tres Seaver wrote:
I'm not sure what impact that would have for the already-converted code
which used to use the API. I can see value both in leaving it
converted, as showing the Zope3-ish way, as well as in reverting some or
all of it. For instance, perhaps we should consider reverting just
Martin Aspeli wrote:
We believe that these recent changes have introduced implicit magic
into a standard Zope3 api to fit Zope2 acquisition. There should be
an explicit separate api if we want acquisition wrapped context-aware
utilities. As an example of a symptom caused by the implicit
On 27 Mar 2007, at 20:57 , Dieter Maurer wrote:
As so often, we have completely different views on how things
should be:
When I have an IObjectBeforeDeleteEvent subscriber which
should update the unique ID tool, then it can assume that
there is indeed a unique ID tool. And if the
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
*sigh* Chapter XYZ in my book explains the process :). Whenever you
traverse over a site, its site manager becomes the active component
registry. So if you haven't traversed over that site yet, the utilities
in that site won't be found
Dieter Maurer wrote:
Martin Aspeli wrote at 2007-3-25 12:46 +0100:
...
I agree, except I think there could potentially be lots of places where
this could be happening. In the general case, it's probably safe for
that code to assume the utility is there, and treat it as an error if
it's not,
Sidnei da Silva wrote:
That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py,
after it looks up __before_publishing_traverse__ but before calling it
I believe. Firing it from inside CMF doesn't make sense.
Yes, the ZPublisher should be firing it. But it doesn't. While it's
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped
On 26 Feb 2007, at 23:48 , Tres Seaver wrote:
I nowhere said anything about deprecation. All meant was to
discourage
relying on acquisition when developing new tools. I think that
deserves
a comment (I suggested nothing more). No deprecation warning or
anything
necessary;.
OK. I do
Jens Vagelpohl wrote:
On 9 Feb 2007, at 11:03, yuppie wrote:
Taking this into account, how should the five.localsitemanager thing
be packaged?
Maybe we can use the same pattern as TextIndexNG3: The Python package
is shipped in a 'src' subdirectory of the product. The product's
__init__ adds
Jens Vagelpohl wrote:
On 7 Feb 2007, at 01:58, Philipp von Weitershausen wrote:
Eggs contain Python packages. How you deploy the Python packages is
your choice. If you like copying or symlinking, fine. And, heck, you
can still symlink your products to Products. Nobody's getting rid
Charlie Clark wrote:
Am 06.02.2007 um 22:14 schrieb Rocky:
Ultimately the closer we get to structuring our code deployment like
regular python code the easier it will be to take advantage of things
like distutils, eggs, the cheeseshop, etc. I look forward to doing:
easy_install ZopeCMF
I
Jens Vagelpohl wrote:
On 7 Feb 2007, at 00:36, Martin Aspeli wrote:
Eggs make your life easier, especially if you want to use tools like
workingenv.py or zc.buildout.
Well, for simple work with the CMF like setting up a quick instance for
hacking and development *I do not want to use any
Martin Aspeli wrote:
I don't think eggs/setuptools are perfect. But I don't think they're
useless either, and on the whole, so far, they've brought more benefits
than problems. By playing with eggs, we're playing better with the rest
of the Python community (and things like entry points are
Rocky wrote:
On Feb 5, 5:40 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote:
On 5 Feb 2007, at 19:43, Rocky Burt wrote:
On Feb 2, 4:41 pm, Jens Vagelpohl [EMAIL PROTECTED] wrote:
OK, sounds good, I misunderstood your email. I suppose the last bit
left to do now is the custom site manager. Rocky?
Jens Vagelpohl wrote:
I have now finished (well, finished awaiting feedback and help on one
item) the work on the jens_tools_as_utilities branch.
There's one set of test failures out of
CMFActionIcons/tests/test_exportimport that I can't quite interpret. I
believe it has to do with the way
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 8 Jan 2007, at 01:19, Hanno Schlichting wrote:
Right now I would let all existing CMF tools implement that interface,
so we would be on the safe side. In a later release we can revisit
this
and see if
Philipp von Weitershausen wrote:
Jens Vagelpohl wrote:
CMF won't come eggified for this release, that work has stalled.
whit wrote:
plone's egg story looks non-existent until next release.
Right, I figued as much. Also, it's only for Zope 2.11 that we can
actually tackle sensible egg
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
Actually, I agree with Dieter here. If something has an __of__(), just
wrap it. You can't possibly do anything wrong, actually, as it already
happens and it provides the best backward compatibility with what we
have right now.
Is __of__
Hanno Schlichting wrote:
Martin Aspeli wrote:
Hanno Schlichting wrote:
PhiliKON some time ago suggested that Five should wrap the utilities
eventually but nobody followed up on that idea.
Philipp also has some ideas (not too far off completion, I believe) that
may remove some of the
Stefan H. Holek wrote:
CMF 1.6 is supposed to work with Zope 2.8.
Aha. Yuck. :)
However, either there is no queryDefaultViewName or it lives
someplace else...
from zope.app.publisher.browser import queryDefaultViewName
ImportError: cannot import name queryDefaultViewName
All fixed
Hi there,
while forward-porting the fix for http://www.zope.org/Collectors/CMF/459
from 1.6 to 2.0, I was running the tests for CMFCore 2.0 and was getting
tons of failures with a straight checkout (see attached file). Is there
anythign I'm missing?
Philipp
--
http://worldcookery.com --
Jens Vagelpohl wrote:
P.S.: This problem does not occur on the trunk. I'll blame Yvo for the
clean run on the trunk ;)
Yes, I was quite (positively) baffled by how nicely the tests run on
CMF, using layers and all that. Kudos to Yvo!
--
http://worldcookery.com -- Professional Zope
yuppie wrote:
Since CMF 2.0 I did a lot of test refactoring, changing the ways CMF
tests are set up. Goal was to use more generic and up to date testing
patterns, making it easier to write new tests.
Here is an overview what changed:
ZopeTestCase.app()
--
All tests that
Raphael Ritz wrote:
Tres Seaver schrieb:
[..]
Yep -- this is how the typical site uses those dates. However, some
folks want actual workflow transitions to happen ASAP after each date
passes. In that case, you need to write a periodic task which searches
for objects which are in the
Florent Guillaume wrote:
Some CMF 1.6 and 2.0 (and I guess trunk) tests are failing in Zope 2.10
due to missing adapters somewhere. Example, when it tries to evaluate
the path 'info/id' (where info is a dict):
Error in test test_generateWorkflowXML_multiple
yuppie wrote:
Jens Vagelpohl wrote:
This checkin seems to have broken Zope 2.8-compatibility:
http://svn.zope.org/GenericSetup/trunk/tests/common.py?rev=68391r1=41338r2=68391
Specifically, the line from zope.testing.cleanup import cleanUp
breaks Zope 2.8, I checked all stable tags (2.8.5,
Yvo Schubbe wrote:
Log message for revision 68396:
- fixed the unit tests that failed on Zope 2.10
(There is still one error, but that seems to be caused by a Zope bug.)
Please file collector entries so that we know and eventually fix them.
+class Expression(Persistent):
yuppie wrote:
Philipp von Weitershausen wrote:
Log message for revision 68396:
- fixed the unit tests that failed on Zope 2.10
(There is still one error, but that seems to be caused by a Zope
bug.)
Please file collector entries so that we know and eventually fix them.
Tres did
yuppie wrote:
Andreas Jung wrote:
we have a CMF-based application where I am trying to migrate from
TextIndexNG 2 - 3.
For a content-type class A I have configured an adapter to implement
IIndexableContent. However when the object is reindexed CMF wraps
the object as IndexableObjectWrapper
Tres Seaver wrote:
I'm not sure what Chris meant, but the change to the visual output of
the testrunner when running with dots seems gratuitous to me, as well
-- I don't see any benefit to the indented, narrower output,
Me neither, for what it's worth.
Zope 2.9 broke the 'confiugre-make'
yuppie wrote:
Based on the discussion on the Five list I propose this solution:
1.) To become independent of the lookup order views are named different
than the corresponding skin methods.
2.) Skins *and* views are always enabled.
3.) A new extension profile hooks up the views instead
Martin Aspeli wrote:
From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over
2.8. Below you are suggesting that Plone 2.5 should do the same with
Zope 2.8 (favouring it over 2.9). I don't understand why that should be.
If one version has to be favoured at all, it should be
Andrew Veitch wrote:
Let's put it this way: By the time Plone 2.5 is releases (if
according to roadmap), Zope 2.8 is one month away from being
*discontinued*. Conservative or not, I wouldn't bet on a release
line that won't receive bugfixes the minute I start using it...
Just so I'm clear,
Alexander Limi wrote:
From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over
2.8. Below you are suggesting that Plone 2.5 should do the same with
Zope 2.8 (favouring it over 2.9). I don't understand why that should be.
If one version has to be favoured at all, it should be
Martijn Faassen wrote:
In an earlier thread I argued that this modified version of Five 1.2
should perhaps get a new name to indicate the additional feature. Do you
all think that this would be feasible, or should we just go on with
1.2.1? If we give it a new name, the question is obviously
Tim Hicks wrote:
The reason for doing so is simple: Products is bound to go away. It
gives a lot of people a lot of pain. With a lot of Zope 3 technology
entering many Zope 2 projects, it would be good to get a clean slate
early on: put new stuff on Product-less packages.
You can turn that
Sidnei da Silva wrote:
On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote:
| Then again, Zope 2.9 is stable (people don't really trust a .0
| release) and we could release Five 1.4 any time after Rocky is done. So
| there's really no reason for people NOT to upgrade, I
Martijn Faassen wrote:
Is Plone 2.5 still targeting Zope 2.8?
Yes.
Yes to which question?
Yes to Is Plone 2.5 still targeting Zope 2.8.
Perhaps these use cases aren't
driven by Plone/CMF core and some other packages would like to use
this in Zope 2.8? Can they be identified?
The
Sidnei da Silva wrote:
On Mon, Jan 16, 2006 at 01:12:46PM +0100, Philipp von Weitershausen wrote:
| Sidnei da Silva wrote:
| On Mon, Jan 16, 2006 at 12:26:09PM +0100, Philipp von Weitershausen wrote:
| | Then again, Zope 2.9 is stable (people don't really trust a .0
| | release) and we
Lennart Regebro wrote:
CMF 1.5 and 1.6 five_template (the one that provides a bridge between
zope3 and CMF templates) doesn't have a head-slot. I'm just wondering
if that slot is somewhat standard in Zope3 and CMF and not only CPS,
becuse it it is I'll add it.
So? Is it?
Zope 3's Rotterdam
Tres Seaver wrote:
The error I am seeing is early, during product initialization, before
any tests are actually running:
File
/home/tseaver/projects/Zope-CVS/Zope-SVN-trunk/lib/python/zope/configuration/config.py,
line 1390, in toargs
args[str(name)] = field.fromUnicode(s)
File
Tres Seaver wrote:
Brent Hendricks wrote:
Tres,
I'm having trouble with the change you made today taking 'default' out
of the list of layers for the cmf browser:skin in
CMFDefault/skin/configure.zcml. It seems to cause the views we'e
defined in CMFPlone to no longer be found via the
63 matches
Mail list logo
