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 directlyProvide
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 lic
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 i
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
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, th
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 sk
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.
fails for /@@detail.html but
Right. This will look up the 'detail.html' view for
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 Gr
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 ju
Charlie Clark wrote:
Am 29.10.2007 um 21:17 schrieb Wichert Akkerman:
It seems that the Launchpad database is not separated by product. I
was just checking the bugs fixed in the latest relase of Zope and
#2339 refers to something completely different related to Ubuntu. I
would have expected bug
On 25 Sep 2007, at 14:06 , Jim Fulton wrote:
There are several problems.
* We've had to nail some of the versions because buildout was
being a bit over-zealous when getting eggs on Windows. It would
take the newest egg, despite the fact that other eggs had binary
releases. I guess that's n
(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
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', &
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
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
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 extre
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 wit
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 (= reg
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 caug
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
th
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
Maurits van Rees wrote:
Maurits van Rees, on 2007-03-29:
I see the same problem in a Plone Product of mine (eXtremeManagement)
where bookings added after the DST get listed a day earlier in one
page template. When I add a booking somewhere in November (I can
choose the booking date) that one ge
Hanno Schlichting wrote:
I would say that all of Acquisition is dark implicit magic and something
I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2
I also expect the need to make the Zope 3 code Acquisition aware. One
prime example are browser views, which I need to mix in
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
imp
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 assum
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, b
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'
Martin Aspeli wrote:
The UniqueIDAnnotationTool should probably do a *query*Utility (which
will return None in case the utility can't be found) and simply not do
anything in such a case. The canonical way of expressing such
fail-safe routines is therefore:
component = query{Utility|Adapter
Martin Aspeli wrote:
Traceback (innermost last):
Module ZPublisher.Publish, line 119, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 42, in call_object
Module OFS.ObjectManager, line 524, in manage_delObjects
Module OFS.ObjectManager, line 379, i
yuppie wrote:
portal = getUtility(ISiteRoot)
I can't get this working. The lookup from within getExprContext fails. But:
- sm.registeredUtilities() contains the ISiteRoot registration
Is 'sm' actually the current site manager? Try to compare whether
z.c.getSiteManager() matches 'sm'
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
clea
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 think
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 re
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
Charlie Clark wrote:
Zope 3 provides all sorts of localization functionality, including
numbers, currency and calendaring.
Look in zope.i18n.locales ...
Yes, I can see what's there but I do not seem to be able to call it from
a page template. If I try the following example from
http://wiki.z
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 r
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
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 ver
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 tool
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 h
Wichert Akkerman wrote:
At the moment it is not possible to use skin layers in pure python
packages. This is caused by the DirectoryView implementation using
a minimal path name for the layer id. This path name is created
by CMFCore.utils.minimalpath, which uses the ProductsPaths list of
director
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
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 _
Martin Aspeli wrote:
Dieter Maurer wrote:
Martin Aspeli wrote at 2007-1-7 23:40 +:
...
Why not do it a more Zope3 ish way:
class ICMFTool(Interface):
"""Marker for any CMF tool"""
and then in the subclass of the local component registry:
local_utility =
if ICMFTool.providedBy(loc
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 tack
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 support in the Zope 2 core, so that mak
On 8 Jan 2007, at 17:30 , Rocky Burt wrote:
On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
Using PersistentComponents() as the component registry (a.k.a. site
manager) for local sites isn't enough. That's because it doesn't
understand about containment hiera
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
Hi there,
others and I have been pushing the usage of local components in Five. As
a result it looks like the CMF 2.1 will use the CA to look up its tools.
Woohoo! (Kudos to Jens and all the others!)
There's one problem with all this which I admit I have failed to
communicate better (certain
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 acquisit
On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
Okay, spoke to Philipp on IRC and he asked me to relay his opinions
on some of this:
- CMF tools ought not to depend on acquiring things from 'self' if
at all possible.
- TTW code will need aq contexts for security. However, it makes
sense
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 now.
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 documenta
Jens Vagelpohl wrote:
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?
I notice you're only running CM
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 -- Pr
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 depe
Jens Vagelpohl wrote:
Jens mentioned that there still is a fair amount of outstanding work for
2.1; I'm hoping to be able to still use an alpha release with the
current featureset.
I was under the impression there were a few "show-stoppers" that needed
CMF 2.1 (and in some cases Five) support
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
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
> (Products.DCWorkflow.tests.t
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=68391&r1=41338&r2=68391
>>
>>
>> Specifically, the line "from zope.testing.cleanup import cleanUp"
>> breaks Zope 2.8, I checked all st
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 collec
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):
>
>
Andreas Jung wrote:
> Both solution appear a bit "heavy" to me. I solved this issue for
> TextIndexNG3 by adding generic support for wrapped objects by
> introducing an IObjectWrapper interface which is checked by the
> indexer. Using five:implements it is easy to attach this interface -
> if n
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 IndexableO
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-ma
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 in
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
whit wrote:
> sorry for the cross post, but I know there are a number of other
> reference engines out there and I would like to get input as we look
> at moving the AT ref engine being a component.
>
> here is a rough list of steps:
>
> 1) move current storage of references to use IAnnotations f
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 shoul
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 shou
Martin Aspeli wrote:
>> How urgent is it that all of this works with Zope 2.8? I guess it's
>> urgent if you want to sell it to the Plone community, which will only
>> switch to Zope 2.9 or beyond by next year or so, I expect. How much
>> more often is this kind of thing therefore going to happe
Martijn Faassen wrote:
> Just to comment on this interchange: Tim Hicks isn't the only one who
> we'd need to explain a few things to in the new world order. We may end
> up with people just dumping packages in SOFTWARE_HOME's 'lib/python'
> directory if we're not careful.
You're right, we haven't
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
Tim Hicks wrote:
>>>Coming at this with a zope 2 head on, it seems to me that it might be
>>>nice if I could carry on using the Products directory so that when I add
>>>new 'products', I don't have to mix them in with the core zope code in
>>>lib/python/.
>>
>>What do you mean by "core zope code"?
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 i
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 re
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 t
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 obvio
Lennart Regebro wrote:
>>CMFonFive version dance confuses the heck out of me, we should try to
>>keep things simple.
>
>
> Yes, I agree. So I think all of CMFonFive, including these changes,
> should be in CMF 1.6. That ends the dance. It was a mistake to move
> half of CMFonFive into CMF. We sho
Rocky Burt wrote:
> There is some logic regarding getting products-less python packages to
> work as first class zope 2 products in a Five branch right now (once its
> finished, its planned to be integrated into trunk for the Five 1.4 release).
>
> Hopefully this means Five 1.4 and CMF 1.6 will ha
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 Rott
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)
>
Philipp von Weitershausen wrote:
>>Phillip, do you have a clue why Five's ZCML initialization order has
>>changed, such that the product ZCML is being done before the core zope3
>>stuff?
>
> I think I know what's wrong. We're missing some important registr
Tres Seaver wrote:
> Tres Seaver wrote:
>
>>>yuppie wrote:
>>>
>>>
>>>
>Florent Guillaume wrote:
>
>
>
>>In what environement do people playing with CMF 2.0 (trunk) work ?
>>Because when used with Zope 2 trunk, there are many failing unit tests.
>
>
>My CMF 2.0
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 foun
88 matches
Mail list logo