an alternative adapter that just looks for talkback.
That makes opaque item support configurable and we can disable it by
default.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
', but the
last released version is 2.12.0b3.
With 2.12.0b3 and Python 2.6 we would see one failure.
I propose to wait for the next Zope release.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
(icon_expr)
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Tres Seaver wrote:
yuppie wrote:
Possible solutions:
---
1.) Make Zope = 2.12 required for CMF 2.2 and change all imports.
2.) Make Zope 2.13 required for CMF 2.2.
3.) Add zope.app.component and zope.app.container to CMF dependencies.
4.) Re-add zope.app.component
that change made things worse.
+1 for removing that dependency in setup.py *and* the test
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports
the components
handler improvements, GenericSetup trunk still works with older
five.localsitemanager versions and Zope 2.10/2.11.
In that case I see two testing errors in test_components.
Not sure how to resolve this.
Cheers,
Yuppie
___
Zope-CMF
:
https://bugs.launchpad.net/zope-cmf/+bug/388380
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Hi Wichert!
Wichert Akkerman wrote:
Previously yuppie wrote:
2.) The distinction between allowType() and isConstructionAllowed() was
clear in CMF 2.1: allowType() checked a cheap, not permission related
CMF specific restriction. isConstructionAllowed() checked generic
permission related
. But allowType() could become part of a
more general precondition that could be checked by checkObject and a new
checkPortalType (=CMF specific checkFactory) function.
Plone could use its own precondition that checks registered
ITypeConstructionFilter adapters.
Cheers,
Yuppie
Wichert Akkerman wrote:
Previously yuppie wrote:
A CMF specific precondition would look up type restrictions in the fti
of the container.
checkFactory and checkObject are quite similar to isConstructionAllowed.
I think we should reimplement this based on zope.container before we
start
at
that code? If we switch to that pattern, we could use different
preconditions for containers with different interfaces. Would that be
sufficient for your use case?
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
I have a use case where I need to put additional restrictions on object
creation, in particular I need to restrict the maximum depth of items
inside of a container of a specific type. The ideal place to put
short:
This is only the case if the context of the view is also a view. In all
other cases they still work.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net
zope.component version? Maybe a different version is
somewhere on your path?
HTH, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports
Hi Maurits!
Maurits van Rees wrote:
yuppie, on 2009-04-16:
I added several tests and cleaned up the behavior on the trunk:
http://svn.zope.org/*checkout*/Products.GenericSetup/trunk/Products/GenericSetup/tests/upgrade.txt
Please let me know if I did break useful behavior.
Ah, that looks
and moves in a different direction.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
indexing.
Why is there a need to access the raw object? The wrapper should provide
all the interfaces and attributes required for indexing.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
Wichert Akkerman wrote:
Previously yuppie wrote:
Martin Aspeli wrote:
Plone 3.3's IIndexableObjectWrapper implementation (in plone.indexer)
has a method _getWrappedObject(), to return the object that was wrapped
by the indexable object wrapper. It is (or rather, will be) used
it here.
I agree it belongs somewhere else. Maybe a registerWrapper method. But
can't we make the adapter lookup in catalog_object optional and wouldn't
that make test setups simpler?
Ok, I bit the bullet and did some work on the tests.
Great!
Cheers,
Yuppie
Hi!
Tres Seaver wrote:
yuppie wrote:
But
can't we make the adapter lookup in catalog_object optional and wouldn't
that make test setups simpler?
Agreed. I had expected that the catalog would do a queryAdapter, and
default to the existing wrapper class if not found.
Well. I had
. And
who catalogs content that doesn't implement IContentish?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature
objections?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Tres Seaver wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
setup.py says:
install_requires=[
'setuptools',
'zope.component 3.5dev',
],
But CHANGES.txt says:
* Rewrite PersistentComponents.registeredUtilities to not use
internal methods
Hi Martin!
Martin Aspeli wrote:
yuppie wrote:
Martin Aspeli wrote:
yuppie wrote:
AFAICS wrapping the object before looking up adapters is unnecessary.
The catalog should do the lookup directly and the existing features
provided by IndexableObjectWrapper should be reimplemented
? If the context of the object
is sufficient, we don't need a multi-adapter. If we just need the
catalog and its context, we still have a generic solution for Zope 2. If
we need the portal, we have a CMF-specific solution.
Cheers,
Yuppie
___
Zope
Hi Tres!
Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
Log message for revision 97800:
Clean out module-scope imports.
[...]
What was wrong with these imports?
I don't like module-scope imports in unit tests: I want tests to
*fail*, not be skipped, when something
.
For technical reasons this collaboration is asymmetric. Plone is built
on top of Zope and CMF, not the other way round. If you want to work
really close with these communities, you have to be part of them and use
their repository.
Cheers,
Yuppie
will write up a short proposal.
AFAICS wrapping the object before looking up adapters is unnecessary.
The catalog should do the lookup directly and the existing features
provided by IndexableObjectWrapper should be reimplemented as adapters.
Cheers,
Yuppie
Hi Martin!
Martin Aspeli wrote:
yuppie wrote:
For the CMF project it is essential to have full control over its own
layer of the stack and to participate in the development of the Zope
layer. Using packages from the Plone repository means either using them
as a black box or joining
Martin Aspeli wrote:
yuppie wrote:
AFAICS wrapping the object before looking up adapters is unnecessary.
The catalog should do the lookup directly and the existing features
provided by IndexableObjectWrapper should be reimplemented as adapters.
Bear in mind that there is a difference
Products.CMFCore.tests.base.dummy import DummySite
-from Products.CMFCore.tests.base.security import OmnipotentUser
-from Products.CMFCore.tests.base.security import UserWithRoles
from Products.CMFCore.tests.base.testcase import SecurityTest
What was wrong with these imports?
Cheers, Yuppie
to run GenericSetup on older versions I'd prefer your
first solution (BBB import from Globals) because it makes sure modules
are imported in the right order.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org
Wichert Akkerman wrote:
Previously yuppie wrote:
If you really need to run GenericSetup on older versions I'd prefer your
first solution (BBB import from Globals) because it makes sure modules
are imported in the right order.
I see no good reasons not to support existing Zope 2.10
Hi!
Hanno Schlichting wrote:
yuppie wrote:
That would mean that CMFDefault-the-example-application will depend on
z3c.form. If we are going to split off the forms we need to split off
all browser views and the profiles that use these views. Something like
'cmf.app' that includes all
Hi!
Charlie Clark wrote:
Am 02.03.2009 um 19:27 schrieb yuppie:
This is on my todo list, but I still have to write a proposal.
Hmm, I don't recall the issue here.
There wasn't much discussion about this.
Some time ago Dieter asked for grouping support:
http://mail.zope.org/pipermail
detail, but from what I can tell,
these things are al stable. Yuppie would know best, though.
There are 2 issues I'd like to see resolved before a beta is released:
1.) look up add view actions in a different way
---
The current implementation
Hi!
Tres Seaver wrote:
yuppie wrote:
1.) look up add view actions in a different way
---
The current implementation is not flexible enough. There is no way to
sort or group these actions.
This is on my todo list, but I still have to write
keep existing states untouched?
AFAICS the easiest way to fix this is changing
WorkflowTool.notifyCreated, making sure it only calls notifyCreated for
workflows without a state in the workflow history.
Any objections or better ideas?
Cheers,
Yuppie
Hi!
Tres Seaver wrote:
yuppie wrote:
Moving the notifyWorkflowCreated call from _finishConstruction to the
IObjectAddedEvent subscriber changed the behavior of .zexp imports: The
workflow state is now always reset to the initial state. AFAICT that's
no useful behavior for imports
direct dependencies on packages Zope2
also depends on should not be specified if Zope2 is specified as dependency.
I thought that was consensus, but if you don't agree I'm fine with
further discussions.
Cheers,
Yuppie
___
Zope-CMF maillist
it cause any trouble
if I would check in that change?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Charlie Clark wrote:
Am 18.01.2009 um 23:00 schrieb yuppie:
I agree that there shouldn't be implemented in a different way than
for Zope 3. And if we can solve the problems by fixing form encoding
I'm happy. Although I'd like to see UTF-8 always the first charset
returned
Dieter Maurer wrote:
yuppie wrote at 2009-1-19 11:32 +0100:
Charlie Clark wrote:
Am 18.01.2009 um 23:00 schrieb yuppie:
I agree that there shouldn't be implemented in a different way than
for Zope 3. And if we can solve the problems by fixing form encoding
I'm happy. Although I'd like
to forms and
use the portal's default_charset for this.
I'd very much appreciate your comments on this.
I can't see a need to implement this in a different way than Zope 3. So
I propose to fix the encoding of forms sent to the browser.
Cheers,
Yuppie
yuppie wrote:
Right now the versions are mostly ignored if a checker exist. I'd like
to evaluate the versions first and use the checker as an additional
restriction. Also, running a step with checker should not update the
current version of the profile.
These changes would allow to split
for=.interfaces.IMyType
Products.CMFDefault.interfaces.ICMFDefaultLayer
provides=zope.publisher.interfaces.browser.IBrowserPage
name=myview
factory=.myview.MyView
permission=zope2.View
/
Cheers,
Yuppie
___
Zope
was much closer to the directive Martin proposes. Since this registers
an adapter that provides IBrowserPage, 'cmf:addpage' might be an
alternative.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope
the additional code in the long
run, I can live with it.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
that this doesn't require a proposal and discussion
first, I could try to implement this in time for your release.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net
Hi Martin!
Martin Aspeli wrote:
yuppie wrote:
How about a new cmf:addview /
directive that mimics browser:page /, but registers the
(context,request,fti) adapter? I could probably put that together if
people think it's a good idea.
CMF add views are different because they are looked up
Martin Aspeli wrote:
yuppie wrote:
Martin Aspeli wrote:
[...]
Let's consider a type Alpha that has a custom add form registered as
such a (context, request, fti) adapter with name Alpha. fti.factory is
Alpha, and there's a corresponding IFactory utility (with name Alpha).
Now, let's say
instead of a new cmf:addview / directive.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
view adapter name and
the factory utility name have to be the same.
Would it make sense to decouple these, e.g. with a new add_view_name
property?
If people really have that problem we can decouple this later. For now I
can't see a need.
Cheers,
Yuppie
Hi!
Laurence Rowe wrote:
yuppie wrote:
David Glick wrote:
Does anyone have an objection to me adding 'context' as an alias for
'object' in the expression context that is built when executing CMF
action expressions (in getExprContext in CMFCore/Expression.py)? This
would remove one
' *and* 'context' or switching from
'object' to 'context' will cause even more confusion.
Please see this thread
http://mail.zope.org/pipermail/zope-cmf/2005-March/021990.html
with this result
http://mail.zope.org/pipermail/zope-cmf/2005-March/021999.html
Cheers, Yuppie
Dieter Maurer wrote:
yuppie wrote at 2008-11-18 12:00 +0100:
Dieter Maurer wrote:
If they would, local utilities were much nearer to tools and
the transition would be facilitated.
They would be nearer to tools, but also more distant from zope 3
utilities. I doubt that would really be a win
and not registered portal_setup tools?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
as Zope 3. A customized __repr__ method
could still show the complete path, at least as long as the active site
is set accordingly.
Any thoughts? I prefer solution 2.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http
Charlie Clark wrote:
Am 11.11.2008 um 16:52 schrieb yuppie:
AFAICT PortalFolder inherits from CMFCatalogAware to make sure it has
the same manage_afterAdd, manage_afterClone and manage_beforeDelete
methods as other content classes. But these methods are gone, so I
guess
the dependency
be moved to adapters and event subscribers.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Hi!
Martin Aspeli wrote:
yuppie wrote:
Martin Aspeli wrote:
Wichert Akkerman wrote:
Why not a ++add++ traverser? Aren't traversed supposed to be used for
that kind of thing? Or does a view gives us something here that a
traverser doesn't?
Namespace traversal adapters are similar
Hi Martin!
Martin Aspeli wrote:
yuppie wrote:
Proposed CMFDefault changes
---
1.) CMF add views adapt not only container and request, but also the
type info object. This way the views can't be accessed directly and have
self.fti available.
This is quite
the reason?
Anyway. I like the idea to use a traverser. It's more explicit and if
you want different URLs you can hide them behind aliases.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
in the type info, a default add
view URL is returned.
If there are no objections, I'll make the proposed changes on the trunk.
@ Jens: When exactly do you want to make the beta release?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF
Hi Jens!
Jens Vagelpohl wrote:
This has now landed, in several chunks because it turned out to be
more work and a larger change set than expected, on the CMF trunk.
Silly me thinking most of my work was done when Yuppie thoughtfully
added a icon URL expression property to the new-style
Hi Martin!
Martin Aspeli wrote:
yuppie-4 wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
I personally prefer to move all type info Actions to the actions tool. I
can't see a need to specify separate 'view', 'edit' or 'metadata'
Actions for each content type. That just makes
like dexterity or cmf should be visible in
URLs. Those are implementation details that should be transparent for users.
Any feedback is welcome.
Cheers,
Yuppie
[1] http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html
[2]
http://dev.plone.org/plone/browser/plone.app.imaging
but not the sort options.
Our preference would be to put the filter information in hidden
variables.
I don't think CMFDefault should rely on sessions. Using hidden variables
sounds fine to me.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF
Charlie Clark wrote:
Am 07.08.2008 um 12:26 schrieb yuppie:
Proposal 2: main_template
-
CMFDefault menus are implemented in main_template. I propose to add
a new section for 'folder/add' actions.
Hi yuppie,
finally had a bit of time to look at this. First
a new proposal.
It also would be nice if someone could 'merge' the DEPENDENCIES.txt
files into the setup.py files. [3]
Cheers,
Yuppie
[1] http://mail.zope.org/pipermail/zope-cmf/2008-August/027607.html
[2] http://mail.zope.org/pipermail/zope-cmf/2008-August/027612.html
[3] http
Jens Vagelpohl wrote:
On Sep 12, 2008, at 10:58 , yuppie wrote:
It also would be nice if someone could 'merge' the DEPENDENCIES.txt
files into the setup.py files. [3]
I alread did that two weeks ago.
Great. But if all the information is now in setup.py, why didn't you
remove
-
CMFDefault menus are implemented in main_template. I propose to add a
new section for 'folder/add' actions.
If there are no objections I'll make these changes on trunk.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http
Hi Martin!
Martin Aspeli wrote:
yuppie-4 wrote:
Some parts are still missing:
- add a traverser that allows to use pretty URLs and better portal type
handling for add views (not part of this proposal)
- don't show newstyle types in folder_factories
- show add actions in the CMFDefault
for CMFDefault in a central place like
PloneTranslations where lots of people can contribute?
+1 if someone volunteers to 'own' that project
Maybe https://translations.launchpad.net/zope-cmf would be a good place?
Cheers,
Yuppie
___
Zope-CMF maillist
.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
a
'portal_type' variable to the expression context because I don't know an
easy way to do that. The action machinery expects that all callable
attributes of all actions take the same expression context as argument.
Cheers,
Yuppie
___
Zope-CMF
, making them implement IAction as well.
listActions of the types tool would include type infos if they provide
IAction *and* have an url specified.
As always, feedback is welcome.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF
,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
. Pushing this down the stack
and making it the default pattern for Zope is much harder.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports
is only available at
portal.portal_properties.site_properties, so
context.getProperty('default_charset') will fail. But, I guess, this is
a Plone problem...
Yes. This is a Plone issue.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF
. And z3c.form is
*the* current Zope package for creating forms.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
to the query, a
TALES expression for the URL wouldn't be overkill.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature
Daniel Nouri wrote:
I just relicensed and moved plone.z3cform to the Zope repository:
http://svn.zope.org/plone.z3cform/trunk/
Great! Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
.
I guess I'd rather have a flexible explicit URL than an implicit URL
ruled by convention.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF
Hi Martin!
Martin Aspeli wrote:
I see that Yuppie has been experimenting with add forms. From what I can
tell, he's using a custom formlib base class and registering views as
e.g. addFile.html. It also look as if he's registering that view as an
action in portal_actions, in the 'folder
Martin Aspeli wrote:
yuppie wrote:
I'm not happy with the current file format. But representing
containers is a general problem and I want *one* generic solution that
works for all use cases.
I'm not sure most people think of portal_types as a container per se.
Rather, they think I need
, just structure. SkinnedFolder
does what you want. If you use CMF trunk, your code will not be
sufficient. handleContentishEvent is registered for IContentish objects,
not for default folders.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF
remain there).
All the information required for adding, moving or removing sub-objects
is currently stored in the container's file. Additional code and
complexity is necessary to extract that information from per-item files.
Cheers,
Yuppie
Hi!
Martin Aspeli wrote:
yuppie wrote:
Martin Aspeli wrote:
The GS handlers for portal_types and portal_workflow both require a
single file - types.xml and workflows.xml - that declares the
objects, and a directory full of files - types/*.xml and
workflows/*.xml - to initialise them
mask attributes:
http://codespeak.net/pipermail/z3-five/2006q1/001186.html
Skin methods are attributes of the portal root (see __getattr__ of
SkinnableObjectManager), but not of sub folders. Views are looked up
after attributes but before acquired attributes.
HTH, Yuppie
Hi Charlie!
Charlie Clark wrote:
Am 25.04.2008 um 09:23 schrieb yuppie:
I simplified the code in ContentAddFormBase.create and moved it to the
add view. 'finishCreate' no longer exists, your add view has to
implement the complete 'create' method. Formlib raises an
NotImplementedError
like
to keep this configurable TTW.
We can look up the addable types in the types tool as folder_factories
and Plone do. But in that case we need a way to get the URL of the add
view.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF
should be easy
The checked in add form borrows one pattern from z3c.form: It doesn't
depend on IAdding, the view is registered for the container.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope
Charlie Clark wrote:
Am 22.04.2008 um 17:24 schrieb yuppie:
Yes. Missing is the integration in the CMFDefault add menu. For now
the new 'add_file' action is used for showing the link to 'addFile.html'.
I hope to have some time for this (and a new table-free version of
main_template.pt
Hi!
Charlie Clark wrote:
Am 23.04.2008 um 11:12 schrieb yuppie:
Charlie Clark wrote:
Am 22.04.2008 um 17:24 schrieb yuppie:
Yes. Missing is the integration in the CMFDefault add menu. For now
the new 'add_file' action is used for showing the link to
'addFile.html'.
I hope to have some
Charlie Clark wrote:
Am 22.04.2008 um 14:27 schrieb yuppie:
Today I checked in a formlib based add view for File objects[3]. There
is a new Add File action available if you use the Experimental
CMFDefault Browser Views extension profile.
Any feedback is welcome. Not sure if this makes Bug
Tres Seaver wrote:
yuppie wrote:
Hanno Schlichting wrote:
yuppie wrote:
I guess CMF 2.2 will be released before Zope2 or Python requires
setuptools, so at least for now it is a GenericSetup/CMF dependency.
http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained
(or deleted
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Until recently, the Products themselves didn't use setuptools. Revision
85287 (http://svn.zope.org/?rev=85287view=rev) changed that. It is no
longer possible to run CMF without setuptools installed.
Was that intended when setuptools
Hi Hanno!
Hanno Schlichting wrote:
yuppie wrote:
I guess CMF 2.2 will be released before Zope2 or Python requires
setuptools, so at least for now it is a GenericSetup/CMF dependency.
http://svn.zope.org/CMF/trunk/ still exists and needs to be maintained
(or deleted). Who ever added
of the DEPENDENCIES.txt files and specify *all* dependencies
in the setup.py files?
Any feedback is welcome.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http
1 - 100 of 409 matches
Mail list logo
