Hi Tres!
Tres Seaver wrote:
yuppie wrote:
But that code doesn't improve the non-purging mode. The changes Wichert
proposed make sense with or without the 'upgrade steps' feature.
If we had the upgrade machinery in place, we could scrap non-purging
mode altogether -- its purp
for editing the XML representation (as used in
GenericSetup), but that depends on resolving issue 2.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.
Hi Tres!
Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
If we had the upgrade machinery in place, we could scrap non-purging
mode altogether -- its purpose is to allow for "controlled" application
of changes to existing configuration wi
Godefroid Chapelle wrote:
Jens Vagelpohl wrote:
On 10 Apr 2007, at 10:30, yuppie wrote:
c) improving five.lsm (Rocky)
AFAICS this is an other attempt to resolve the same issue:
http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html
We have to decide which way to go. I prefer c) if it
Hi!
Kapil Thangavelu wrote:
On Tue, 10 Apr 2007 09:09:27 -0400, Jens Vagelpohl
<[EMAIL PROTECTED]> wrote:
On 10 Apr 2007, at 10:30, yuppie wrote:
Currently non-five.lsm site managers don't work in CMF, see this thread:
http://mail.zope.org/pipermail/zope-cmf/2007-March/
Hi!
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. We just don't pass that 'site context' explicitly to
AdapterRegistry (_adapters, _subscribers, _provided) are looked up
directly. Did anybody try to use customized lists and dictionaries for
five.lsm that do the wrapping? Or can anybody tell me why that would be
a bad idea? I guess performance might be a problem.
Cheers,
Yuppie
ssful, I'm fine with reverting all the tools-as-utilities
changes.
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
he last weekend started the next day, so
in my view it was "this weekend". By "next weekend" I did mean the
weekend *after* "this weekend". Sorry.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail
his week I have some time to work on the implementation.
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
traversal and trigger the setup in
__before_publishing_traverse__ don't need it.
Please let me know if you think this checkin causes too much trouble and
should be reverted.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
Dieter Maurer wrote:
yuppie wrote at 2007-6-18 11:29 +0200:
...
Please let me know if you think this checkin causes too much trouble and
should be reverted.
We are using portals and their skins widely in scripts executed
outside of Zope. Especially, they do not use the ZPublisher
to traverse
ase is just not deprecated because GenericSetup still
uses it in some places. But the goal was to get rid of it, not to add
new files that depend on it.
- Why is exporting metadata.xml not supported?
- How are profile dependencies specified, where are they used?
the test pass:
http://svn.zope.org/five.localsitemanager/trunk/src/five/localsitemanager/registry.py?rev=76442&view=auto
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zo
Hi Rob!
Rob Miller wrote:
yuppie wrote:
- Why is it necessary to use version numbers from VERSION.txt? AFAICS
it does not make much sense to keep profile version numbers in sync
with product version numbers. New profiles should have an explicit
version in metadata.xml, old profiles can
se a script and Products.CMFDefault.utils.decode. In CMF
2.1 *all* strings passed to a template have to be unicode. Maybe
'portal_title' defined in getMainGlobals works for you, at least it
shows how to use 'decode'.
HTH, Yuppie
___
Zope-CMF m
The only reason a namespace is used is to make sure identifiers are
unique. If you use your own namespace, you don't have to care about
utility names used by other products.
HTH,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
htt
in the long run, modify all tools to make them work as utilities
AFAICS, KSS will no longer need the monkey patch if it sets the
LookupClass to FiveVerifyingAdapterLookup.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http:
Wichert Akkerman wrote:
Previously yuppie wrote:
- figure out if we can make acl_users an utility
User folders, or their plugins, seem to have a tendency to rely on
self.REQUEST so that is probably not going to work.
:(
MembershipTool depends on acl_users
MemberDataTool, RegistrationTool
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
- figure out if we can make acl_users an utility
User folders, or their plugins, seem to have a tendency to rely on
self.REQUEST so that is probably not going to work.
:(
MembershipTool
the old
five.lsm, but not with the five.lsm trunk and r76995 of CMF.
Are you using a KSS version without monkey patch?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http
already in use.
Looks like http://www.zope.org/Collectors/CMF/486
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
9 and later) unless you want to help testing
those changes!
If everything goes well, those changes will become permanent and
migration code will be added.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/ma
Charlie Clark wrote:
Am 23.06.2007 um 14:53 schrieb yuppie:
There are 10 tools in CMF that are not ready for being used as
utilities, they have to be used the old way until they are fixed:
content_type_registry
cookie_authentication
portal_actions
portal_calendar
portal_catalog
portal_skins
Hi!
Hanno Schlichting wrote:
yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
MembershipTool depends on acl_users
MemberDataTool, RegistrationTool, DiscussionTool and
CachingPolicyManager depend on MembershipTool
From what I can see in the Plone tests it won't be pos
7;ll change the dependency for CMF 2.1
and trunk to Zope 2.10.4 and clean up the postonly changes.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.o
Property should become part of the IPropertiesTool interface and
implementation. It should not rely on acquisition.
HTH,
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
Charlie Clark wrote:
Am 29.06.2007 um 10:37 schrieb yuppie:
Looks like your utility isn't acquisition wrapped - getProperty is
usually acquired from the site root.
1.) Your site seems to broken, there is currently no migration code
that updates the lookup class if you have an old
sic GS feature.
I'd like to see http://www.zope.org/Collectors/CMF/473 resolved *before*
the next beta release.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://c
forward port the
latest changes to CMF trunk.
I have some ideas for a roadmap, but that'll be the subject of different
mail within the next days. That roadmap could include some changes (like
renamings, deprecation warnings) for CMF 2.1.
Cheer
Wichert Akkerman wrote:
Previously yuppie wrote:
1.) The thread mentioned above is about other issues than the components
handler issue. AFAICS the BBQ sprint work still needs some polishing.
What kind of polishing do you see still being needed?
I didn't have a closer look at GS for a
usion and disaster.
I replaced this TypeError by BBB code and a deprecation warning, so for
now this is resolved.
In general we might need a pattern like that if other optional arguments
come before REQUEST and we want to make REQUEST required. I don't think
changing
er, everybody has to work with tools and
utilities side by side for a long time. Might be confusing.
Opinions? Questions? Other scenarios?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo
arguments where REQUEST is used.
A bird in the hand is worth two in the bush.
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 repo
Hi!
Godefroid Chapelle wrote:
Tres Seaver wrote:
yuppie wrote:
Godefroid Chapelle wrote:
Scenario 1+2 :
The methods that depend on REQUEST are moved to browser views as
below instead of quickly fixed as in the scenario above. They can
then be deprecated on the tool.
Once a tool has
hods that need to
be fixed or replaced before they can become part of an utility API.
All tools listed here seem to work as utilities:
http://svn.zope.org/CMF/trunk/CMFDefault/profiles/default/componentregistry.xml?rev=77358&view=auto
HTH, Yuppie
Wichert Akkerman wrote:
Previously yuppie wrote:
2.) The ability to create valid snapshots is a very basic GS feature.
I'd like to see http://www.zope.org/Collectors/CMF/473 resolved *before*
the next beta release.
I fixed a couple of GenericSetup bugs recently which may have fixed thi
Hi Tres!
Tres Seaver wrote:
yuppie wrote:
Or do you prefer to keep things as they are over a less clean switch to
utilities?
Yes. I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies
as they are, then delay.
I'm not just talking about CMF 2.1. I'm f
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
2.) The ability to create valid snapshots is a very basic GS feature.
I'd like to see http://www.zope.org/Collectors/CMF/473 resolved *before*
the next beta release.
I fixed a coup
Hi!
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
yuppie wrote:
Or do you prefer to keep things as they are over a less clean switch to
utilities?
Yes. I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies
as they are, then
ixed today by Wichert.
+1 for a new 2.1 beta
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
adding new code that checks if a step is available
without actually running it.
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
Hi!
Martin Aspeli wrote:
yuppie-3 wrote:
The proposed solution doesn't work:
The ImportStepRegistry is not only used for imports - it is also used
for creating new 'import_steps.xml' files for exports.
Exported profiles are always base profiles, they have to specify *all*
oolByName'; in the future, prefer
'zapi.getUtility(IActionsTool)'." Seems not all docs reflect the latest
tools-as-utilities changes.
I think the most important issues can be resolved before the weekend
*if* some people are willing to help.
Cheers,
Yuppie
jects in the site. As long as there
are no conflicting export handlers that export the object's
configuration twice, I can't see any export problems.
If there are conflicts, it should be sufficient to resolve them on
instance level by fixing
Wichert Akkerman wrote:
Previously yuppie wrote:
- The exports created by the new components handler are still flawed,
ISiteRoot and placeless components are not exported correctly.
I'm quite sure I fixed that: I was able to export the components and
import them again. Has that been b
more complex than they already are.
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
session a few weeks ago to remove such
a step manually from the registry. That worked, but having a method
that you can call in an uninstall method that does this for you, would
be better.
One more reason for a non-persistent global registry.
Yuppie
_
Hi!
Jens Vagelpohl wrote:
On 2 Aug 2007, at 13:55, Wichert Akkerman wrote:
Previously yuppie wrote:
1.) Exporting the ISiteRoot utility, 'object' should be empty. But I get
this instead:
2.) By placeless components I mean something like this:
The import works fin
Hi!
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5 Aug 2007, at 20:15, yuppie wrote:
I'm supposed to do a CMF 2.1.0 release today, but the state of these
issues is unclear. Wichert, did you look at it? There are no checkins
into either CMF or GS as far as
yuppie wrote:
AFAICS the premature GenericSetup 1.3 release has the biggest issues:
- There are also some usability issues (strange ordering; strange
interface names including '_tools' and '_content';
Ordering and dotted names are fixed now. This makes it much easie
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
- The exports created by the new components handler are still flawed,
ISiteRoot and placeless components are not exported correctly.
I'm quite sure I fixed that: I was able to expor
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
I get something else: if I import this:
the export looks like this:
That seems to be a similar but different bug.
this is caused by the zope.component.registerUtility not storing the
factory method but the
Wichert Akkerman wrote:
Previously yuppie wrote:
The check for aq_base should be fine, but your example shows a second
issue: type() is used to get the factory. That only works if the class
is the factory.
So there seems to be indeed a need to store somewhere the factory name :(
I think we
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
The check for aq_base should be fine, but your example shows a second
issue: type() is used to get the factory. That only works if the class
is the factory.
So there seems to be indeed a
Wichert Akkerman wrote:
* on GS trunk I want to implement zcml-based import and export step
registration (I have a partial implementation but need to finish
that)
That means replacing the persistent local registries by a global
registry, right?
Cheers, Yuppie
Hi!
Tres Seaver wrote:
yuppie wrote:
Wichert Akkerman wrote:
* on GS trunk I want to implement zcml-based import and export step
registration (I have a partial implementation but need to finish
that)
That means replacing the persistent local registries by a global
registry, right?
I&#
site managers to sub-folders. That
works fine, just the GenericSetup support is missing:
http://www.zope.org/Collectors/CMF/500
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinf
/ and
Products.GenericSetup/tags/1.3.2/Products/GenericSetup into
CMF/branches/2.1/
Products.CMFCore seems not to be used - changes still go into CMF/*/CMFCore
Can we please have *one* location for each product?
Cheers,
Yuppie
___
Zope-CMF
e import step version approach.
Am I missing something?
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
in /CMF/tags/2.1.0/CMFCore
"2.1.0"in /Products.CMFCore/tags/2.1.0
"2.1.0" Zope Foundation policy?
2.) /GenericSetup/trunk and /GenericSetup/branches/1.3 should be
deleted, /CMF/trunk/CMFCore and /CMF/branches/2.1/CMFCore replaced by
externa
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?
Cheers, Yuppie
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Running the trunk unit tests triggers warnings like this one:
"UserWarning: Version for profile Products.GenericSetup:default taken
from version.txt. This is deprecated behaviour: please specify the
version in metadata.xml."
le version is
deprecated. But you now get always a deprecation warning if no
metadata.xml exists in the profile. Is that intended? Is specifying a
version now required?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zop
Wichert Akkerman wrote:
Previously yuppie wrote:
Wichert Akkerman wrote:
Previously yuppie wrote:
Running the trunk unit tests triggers warnings like this one:
"UserWarning: Version for profile Products.GenericSetup:default taken
>from version.txt. This is deprecated behaviour
Hi!
Tres Seaver wrote:
yuppie wrote:
Previously yuppie wrote:
Running the trunk unit tests triggers warnings like this one:
"UserWarning: Version for profile Products.GenericSetup:default taken
from version.txt. This is deprecated behaviour: please specify the
version in metadat
a flag file for the 'various' step.
I already started implementing this. If there are no objections, I'll
soon check in my changes.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailma
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
GenericSetup trunk has global step registries. I propose to use the new
ZCML directive for registering all GenericSetup and CMF import and
export steps globally. And to remove the import_steps.xml and
export_steps.xml files from the
yuppie wrote:
GenericSetup trunk has global step registries. I propose to use the new
ZCML directive for registering all GenericSetup and CMF import and
export steps globally. And to remove the import_steps.xml and
export_steps.xml files from the profiles shipped with CMF.
This also requires
call notifyModified() as reindexObject() does.
If there are no objections, I'll backport the changes to the 2.1 branch.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
otifyWorkflowCreated() call
for IObjectAddedEvent. indexObject() is already called.
Any comments? Questions? Objections?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
efore this evening, I'll backport the
changes mentioned here:
http://mail.zope.org/pipermail/zope-cmf/2007-December/026999.html
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zop
d adapters over multi-adapters. And deprecate
getHistoryOf, setStatusOf and getStatusOf.
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 b
Laurence Rowe wrote:
yuppie wrote:
and adapterizing workflow status and history:
http://plone.org/products/roadmap/221
+1
I just would prefer named adapters over multi-adapters. And deprecate
getHistoryOf, setStatusOf and getStatusOf.
The problem with using named adapters is that it
Hi Laurence!
Laurence Rowe wrote:
yuppie wrote:
Now I see why you didn't propose named adapters. But I'm still not
happy with adapting (IContentish, basestring). Did you consider to add
getId() to IWorkflowDefinition and to adapt (IContentish,
IWorkflowDefinition)?
Then I don
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Here are my assertions:
a) The right place for calling notifyWorkflowCreated() and indexObject()
is the event handler for IObjectAddedEvent. _setObject() sends this
event by default.
b) Oldstyle factory methods are not responsible for
cify one of them, but not both,
which seems to be easy to do with invariants.
Am I on the right track? :-)
I guess you are.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://
nd adapter
lookups. I think the recommended pattern should be using the adapters
directly, not the tool methods.
Cheers
Yuppie
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.o
eers, 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
I'd prefer a IConfigurableIndex interface that also has a set method.
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
) : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux
From: CMF Unit Tests
Date: Wed Feb 27 21:37:14 EST 2008
URL: http://mail.zope.org/pipermail/cmf-tests/2008-February/008108.html
I caused this failure. I thought yuppie fixed it yesterday.
I fixed it in GS trunk, but forgot to backport the fix to the 1.3
Andreas Jung wrote:
--On 28. Februar 2008 09:38:31 +0100 yuppie
wrote:
I'd prefer a IConfigurableIndex interface that also has a set method.
I added the IIndexConfiguration to the Zope trunk. I don't think that a
set method is a good idea. Removing and re-adding is possibly the
for one class? There should not
be a need for that. One meta type can be used for several portal types.
I attached a custom factory for plain CMF documents that sets the
initial text format to 'html'. Maybe that code helps you.
Cheers,
Yuppie
-
Charlie Clark wrote:
Am 03.03.2008 um 23:45 schrieb yuppie:
Do you mean you use different meta types for one class? There should
not be a need for that. One meta type can be used for several portal
types.
That's good to hear - how do I register different portal types? I've
Looks like five.localsitemanager is missing in your setup. Yuppie
Jens Vagelpohl wrote:
I'm running the tests on the current GS trunk and see a dozen errors
like the traceback below. Right now my setup is Zope from the 2.10
branch after 2.10.4, maybe a few weeks old. I'm not using b
the
setuptools dependency.
As soon as we have a decision, the relevant files should be updated. Can
we get rid of the DEPENDENCIES.txt files and specify *all* dependencies
in the setup.py files?
Any feedback is welcome.
Cheers,
Yuppie
__
Hi!
Wichert Akkerman wrote:
Previously yuppie wrote:
Until recently, the Products themselves didn't use setuptools. Revision
85287 (http://svn.zope.org/?rev=85287&view=rev) changed that. It is no
longer possible to run CMF without setuptools installed.
Was that intended when setup
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 the
e CMF specific.
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 #161664[4] obsolete.
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. No
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
rting the forms 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/m
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
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'.
face?
No. The view registrations don't provide enough information and I'd 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,
Y
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
No
Hi!
Laurence Rowe wrote:
yuppie wrote:
The lookup is pretty much what I do at the moment. I can't think of
an easy way of doing this apart from convention which is pretty much
what you suggest with "addFile". I suppose the next thing would be to
add support for the
ure views don't 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 attri
se workflows.xml also has
bind information that should 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 tha
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
401 - 500 of 608 matches
Mail list logo
