Philipp von Weitershausen wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
I assume that this proposal is dead. I haven't read the whole thead,
but I think that was the gist. I notice that this proposal no longer
is listed on the proposals
Jeff Shell wrote:
Less directives? Maybe. *
Less does a lot of things for you but offers no easy path to do some
of the work yourself? directives? Yes please.
Less similar to but varying by a couple of small details directives?
(browser:view and browser:page)? Yes please.
One namespace for
Jeff Shell wrote:
Am I the only person who uses apidoc to look up what can be done with
ZCML? Because honestly, finding out what directives are available and
getting decent documentation about ZCML directives is the easiest
thing in Zope 3. Understanding what's going on or what the real
On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote:
Am I the only person who uses apidoc to look up what can be done with
ZCML?
I dunno if it's just me, but http://localhost:8080/++apidoc++
is 404 on a fresh 3.2 instance.
Aside from that, I noticed that the help popup in the ZMI
On Thu, Feb 16, 2006 at 12:31:46PM -0500, Paul Winkler wrote:
On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote:
Am I the only person who uses apidoc to look up what can be done with
ZCML?
I dunno if it's just me, but http://localhost:8080/++apidoc++
is 404 on a fresh 3.2
Jeff Shell wrote:
I still HATE magical ZCML. But I still think ZCML is a good thing and
should be modularized. Simplified - yes. Modular (namespaces) - yes.
That seems to be the core message of most of the feedback I got. I'll be
happy to hear more detailed suggestions on what should be
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
[snip]
Moreover, sometimes a package introduces new ways to configure
components. Five does so, for instance, and Silva will too eventually.
I would really like to hear what kind of directives you imagine for Silva here
(and what you
Martijn Faassen wrote:
I would really like to hear what kind of directives you imagine for
Silva here (and what you mean by new ways to configure components).
The following are candidates, though note I haven't thought this through
deeply for any of them:
* a way to register a Silva
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
[snip]
* a way to register an XSLT renderer.
* registering XML importers and exporters.
These two immediately triggered adapter in my mind :).
XSLT renderer may be a view, that's how we use them now. I think it's a
candidate for a
On 2/13/06, Stephan Richter [EMAIL PROTECTED] wrote:
On Monday 13 February 2006 07:57, Philipp von Weitershausen wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
-1
Here some comments:
- You do not argue how the decision-making process
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
This message was sent using IMP, the Internet Messaging Program.
___
Zope3-dev mailing list
On 2/13/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
What happens if you want to add your own statements? Should you still
do that in your own namespace? If not, how are we going to make sure
Lennart Regebro wrote:
On 2/13/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
What happens if you want to add your own statements? Should you still
do that in your own namespace?
No. But I
Stephan Richter wrote:
- You do not argue how the decision-making process is highly inconsistent.
Fair enough. I will update the proposal later. Supper first :).
- I do not understand what's so bad about coming up with your 3rd-party ZCML
directives. They are extremely easy to write and use.
Stephan Richter wrote:
As we have learned that we can reduce nearly all component tasks to
adapters and utilities, many tasks revolving around registration and
configuration of policy also only involve adapters and utilities. By using
those elementary directives we can stimulate the learning
Philipp von Weitershausen wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
-1.
Prefixing 'browser' directives in the tag names to me is a big warning
bell that you really do want to use different namespaces. Another
example of the namespace
Philipp von Weitershausen wrote:
Lennart Regebro wrote:
On 2/13/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.
What happens if you want to add your own statements? Should you still
do that
Philipp von Weitershausen wrote:
Stephan Richter wrote:
As we have learned that we can reduce nearly all component tasks to
adapters and utilities, many tasks revolving around registration and
configuration of policy also only involve adapters and utilities. By using
those elementary
Martijn Faassen wrote:
Prefixing 'browser' directives in the tag names to me is a big warning
bell that you really do want to use different namespaces. Another
example of the namespace mechanism working is that some people are using
it in their projects, adding namespaces specific to their
Martijn Faassen wrote:
No. But I don't think that it'll be much of a problem. I expect that not a
lot of 3rd party packages will need their own set of ZCML directives.
Currently I know of five and union.cms doing it. I'm certainly
considering doing so for Silva. Then there's the example of
Martijn Faassen wrote:
I don't see the problem with learning new ZCML directives when I'm
learning a new package. I can see why you'd like to reduce the
occurence, and I think sometimes configuring things in ZCML is actually
doing it in the wrong place, as information needs to be persistent
Martijn Faassen wrote:
I want to evolve ZCML as it is right now, this might mean removing
directives, changing directives, consolidating directives, adding
directives, removing some namespaces, consolidating some namespaces,
even adding some namespaces.
Fair enough. I'm already looking
22 matches
Mail list logo
