[Zope3-dev] Re: One namespace for ZCML

2006-02-17 Thread Alexander Limi
On Fri, 17 Feb 2006 04:59:30 -0800, Stephan Richter  
[EMAIL PROTECTED] wrote:



On Friday 17 February 2006 07:38, Jim Fulton wrote:

   I really think the ArchGenX project has a lot to offer here. Does
   anyone know if it is still alive?


Yes it is. Jens has started at the Snow Sprint to implement a Zope 3 code
generator. Once the new version dubbed AGX is complete they will move to
fully support Zope 3 code generation.


For reference: they renamed the project to Genesis to avoid confusion  
with the old AGX, since it is a ground-up rewrite with slightly different  
goals). So Genesis is the ArchGenXML rewrite.


(If you find this confusing, it was worse when you had two products  
ArchGenXML and AGX, and people tended to use the shorthand AGX for both  
products. ;)


--
_

 Alexander Limi · Chief Architect · Plone Solutions · Norway

 Consulting · Training · Development · http://www.plonesolutions.com
_

  Plone Co-Founder · http://plone.org · Connecting Content
  Plone Foundation · http://plone.org/foundation · Protecting Plone

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-15 Thread Philipp von Weitershausen
Roger Ineichen wrote:
 I'm interessted in a menu / menu item refactoring.
 
 This means, we could get rid of the implicit magicly 
 registred menus in other directives which ends in
 unaccessible menu items and will offer a better 
 accessible API. I will write a proposal later, but perhaps
 I have to prototype first since this part is very complex
 and used almost in every browser directive.

Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions
something like this in the end (it's not really part of the actual
proposal anymore, just some random thoughts):


Many directives of the browser namespace support the registration of
menu items in addition to registering the component in question. Though
this can be considered useful because it might save some typing, keeping
directives as simple as possible (on/off switches!) might be weighed
higher. People are certainly intimidated by the length of some of the
browser directives (such as browser:editform); by taking the menu
functionality out, we could reduce many directives by two lines making
them easier to understand by themselves (of course, we'll have to add
another menu directive, but it'll only be 3 or so lines).


If you got any further comments on this, I'd be happy to hear them. It
doesn't *have* to be a proposal, but it would sure be nice :).

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-15 Thread Stephan Richter
On Wednesday 15 February 2006 07:59, Philipp von Weitershausen wrote:
 I realize that and I think at least the concern was valid. As for the
 solution, I rather prefer the convenience (which reads for me as
 automation when it get rids of dead chicken direcives) to be in Python.

But I think this is exactely the problem. Convenience is often geared towards 
non-technical people, like designers and integrators. For them to touch or 
write Python code is horrifying. One of the goals of ZCML was to address this 
audience and day: Look add, edit or change this and that directive and you 
are good to go. It was also one of the reasons XML was chosen.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-15 Thread Philipp von Weitershausen
Stephan Richter wrote:
I realize that and I think at least the concern was valid. As for the
solution, I rather prefer the convenience (which reads for me as
automation when it get rids of dead chicken direcives) to be in Python.
 
 But I think this is exactely the problem. Convenience is often geared towards 
 non-technical people, like designers and integrators. For them to touch or 
 write Python code is horrifying.

I don't think designers will have to touch Python. I don't even think
they will often touch ZCML. The designers I hired never had to...

 One of the goals of ZCML was to address this audience and day: Look
 add, edit or change this and that directive and you are good to go.
 It was also one of the reasons XML was chosen.

I think ZCML is addressing people who build packages, people who make
applications out of these packages and people who deploy those
applications. I think in all three cases we can assume enough experience
with Zope and Python to expect them to enter, say, a dotted name. And,
of course, these people typically overlap.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Re: One namespace for ZCML

2006-02-15 Thread Roger Ineichen
Hi Philipp

[...]
 Subject: Re: [Zope3-dev] Re: One namespace for ZCML
 
 Roger Ineichen wrote:
  I'm interessted in a menu / menu item refactoring.
  
  This means, we could get rid of the implicit magicly 
  registred menus in other directives which ends in
  unaccessible menu items and will offer a better 
  accessible API. I will write a proposal later, but perhaps
  I have to prototype first since this part is very complex
  and used almost in every browser directive.
 
 Note that my other proposal, 
 ReducingTheAmountOfZCMLDirectives, mentions
 something like this in the end (it's not really part of the actual
 proposal anymore, just some random thoughts):
 
 
 Many directives of the browser namespace support the registration of
 menu items in addition to registering the component in 
 question. Though
 this can be considered useful because it might save some 
 typing, keeping
 directives as simple as possible (on/off switches!) might be weighed
 higher. People are certainly intimidated by the length of some of the
 browser directives (such as browser:editform); by taking the menu
 functionality out, we could reduce many directives by two lines making
 them easier to understand by themselves (of course, we'll have to add
 another menu directive, but it'll only be 3 or so lines).
 

Yes, I agree, 
that's also a good base for a menu simplyfication.

 If you got any further comments on this, I'd be happy to hear them. It
 doesn't *have* to be a proposal, but it would sure be nice :).

I think it's to complex it right now since I'm not sure at all if
my idea will work. Let me try to give a short overview.

- Merge the menu and menu item to one implementation

- the above will also allow to implement nested menus.
  Right now the implicit menu, registred in views, don't
  have a id itself. This means they are unuseful for nested
  menu registrations. 

- move menu registration out of the view directives,
  (like described in your proposal)

- Also refactor the IFactory concept. Use IFactory adapters
  on folders instead of IFactory utilities.

The last part IFactory adapters instead of IFactory utilities
depends on a application I wrote and was running in serious 
problems because of the slowdown which depends on IFactory utilies 
lookups. I'm not sure if somebody will agree on this, but I think
if I can profile the IFactory utility implementation and show
the slowdown, we have a better base for a proposal.

This would also solve some namespace problems we have with
the content type name registration.

Note; nested menus are implemented since more then a half year.
But they are not useable with the existing menu items which are
registered inculded in the view directives. Because in the view
directive registred menus are only menu items which are not 
nested.

Regards
Roger Ineichen

 Philipp
 ___
 Zope3-dev mailing list
 Zope3-dev@zope.org
 Unsub: 
 http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
 
 

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-15 Thread Tim Peters
[Sidnei da Silva]
...
 Now whether that's that's the correct interpretation is up to the
 original author (Tim Peters?) to clarify :)

[Fred Drake]
 I don't know if he's paying attention to this thread, but I'm fairly
 certain everyone at PythonLabs understood that to refer to namespaces.
  If Tim would like to counter that, he's certainly free to do so, of
 course.  :-)

I was, of course, merely acting as a channel for Guido.  It wasn't my
job to understand or interpret, it was merely to put into words
Guido's essentially ineffable wisdom.  I'm not sure even God (let
alone Guido) knows what that stuff _means_, and there's been healthy
debate over interpretations ever since.

FWIW, I always thought the namespace one was talking about
namespaces, or _perhaps_ wooden shoes.  I'm certain it wasn't talking
about tulips, although certainty over interpretations has admittedly
been the cause of much human misery throughout history.  So if someone
_does_ think it's about tulips, best to smile and nod, then killfile
the moron :-)
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-14 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:

snip

 Just note that I'm explicitly not addressing automation as a use case for
 custom ZCML directives. I believe automation is best done in Python. If you're
 trying to invent a new ZCML directive that does something else to an
 adapter/view/utility before registering it (e.g. putting an interface on it,
 adding attributes, wrapping it in a factory etc.), then that should be done in
 Python. zope.formlib is a good example of how browser:page is enough for
 registering a form as it isn't ZCML's concern *what* kind of page we're
 registering. All that is in Python.

I'll aggree to an extent:  where this pactice breaks down is when the
argumentes to the automation need to be supplied as configuration.  At
that point, a wrapper argument which allows the user to specify those
values without writing / modifying PYthon can be a win.  In the case of
Shane's webroot proposal, for instance, the filesystem path to the
root would be best specified as an attribute to a custom directive, even
if the directive did nothing more than configure a single global utility.

snip

Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD8cKj+gerLs4ltQ4RAvo3AKCs0XzL07Yo6TYUGjtR9TwVHsWkSQCgvSul
z/pSuIU/iBLm3x3ad1IR2G4=
=fyuR
-END PGP SIGNATURE-

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-14 Thread Florent Guillaume

Philipp von Weitershausen wrote:

Yet again looking for comments, this time at:
http://dev.zope.org/Zope3/OneNamespaceForZCML.


Let me add my -1 to this.

I'm all for reducing the number of namespaces in the standard directives, 
and reducing the number of directives too, but getting rid of namespaces, as 
others have pointed out, removes clean ways of extending ZCML for 
third-party frameworks.


For example CPS currently has a cps:upgradeStep directive:

  cps:upgradeStep
  title=Upgrade catalog from Zope 2.7
  handler=.upgrade.upgrade_catalog_Z28
  checker=.upgrade.check_upgrade_catalog_Z28
  sortkey=-10
  /

  cps:upgradeStep
  title=Clean catalog of broken objects
  source=3.3.4 destination=3.3.5
  handler=.upgrade.upgrade_334_335_clean_catalog
  /

Now you could have a CpsUpgradeStep directive, but I hope everyone agrees 
that prefixing names is a poor man's way of doing namespaces.


You could also maybe provide the same info using two or three other standard 
directives, but that would be very inconvenient.



Maybe a simple zope 3 component doesn't need to provide extensions to ZCML 
using a namespace, but any *framwework* on top of it will quickly need them.



Finally


--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-14 Thread Philipp von Weitershausen
Tres Seaver wrote:
Just note that I'm explicitly not addressing automation as a use case for
custom ZCML directives. I believe automation is best done in Python. If 
you're
trying to invent a new ZCML directive that does something else to an
adapter/view/utility before registering it (e.g. putting an interface on it,
adding attributes, wrapping it in a factory etc.), then that should be done 
in
Python. zope.formlib is a good example of how browser:page is enough for
registering a form as it isn't ZCML's concern *what* kind of page we're
registering. All that is in Python.
 
 I'll aggree to an extent:  where this pactice breaks down is when the
 argumentes to the automation need to be supplied as configuration.  At
 that point, a wrapper argument which allows the user to specify those
 values without writing / modifying PYthon can be a win.  In the case of
 Shane's webroot proposal, for instance, the filesystem path to the
 root would be best specified as an attribute to a custom directive, even
 if the directive did nothing more than configure a single global utility.

In another post I said that this use case is ok because it actually
configures this component. That's one of the intended usecases of ZCML.
Automation isn't, but then again what you're describing above isn't
automation either, so all we're doing right now is agreeing with teach
other :).

Philipp

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Monday 13 February 2006 08:36, Philipp von Weitershausen 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 process for
developers (there should only be one way of doing things). Yes, you might
have to use two or three directives instead of just one new one, but you'll
know what you're doing... And you'll remember it in 2 months. I think
that's more valuable than saving a couple of lines today.
 
 
 I think this is the wrong thread. :-) We are discussing the one namespace 
 here. If I would be against replacing one special directive with a couple 
 fundamental directives, I would have voted -1 on the other proposal, which I 
 did not.
 
 
That said, there might still be a small percentage of cases where custom
directives are a valid tool. I can accept their being on the same namespace
as others. In fact, I would like it to be that way, reducing the amount of
dead chickens (namespace declarations).
 
 
 I do not think namespace declarations are dead chickens. For me declaring a 
 namespace in ZCML is the same as importing a package or module in Python. You 
 would not want all functions and classes in Python live in one namespace, 
 would you?

+1 to Stephan's comment;  -1 to the proposal.

 - The opposition to namespace declarations is whiny, as they are the
   standard way to make XML extensible.  Unless we are going to quit
   using XML, outlawing namespaces would be equivalent to saying, you
   may not extend ZCML;  I don't think we are smart enough to make that
   ukase.  I think the Last Law of Python according to the Prophet
   Peters obtains here as well.

 - Note that the non-XML language also used by Zope (ZConfig) has its
   own extensibility mechanism:  in fact, Fred and I made it possible
   in November for Zope2 products to register their own schemas for
   those extensions, which was a blocker for moving some configuration
   out of software.

 - I don't want to encourage people to do configuration in Python:
   we have moved away from that *on purpose* in Zope, and I don't see
   a reason to go back.  Directives which make it possible to change
   policy decisions without touching software are a Good Thing.  I think
   that letting people who spend their days up to the elbows in the
   software make choices here skews the picture:  we *want* people to
   be able to change the behavior of the system in controlled ways
   without having to modify software;  I would prefer to hear feedback
   from non-core-developers before going further with the ZCML delenda
   est thread.

 - The application vs plugin discussion is probably germane to this
   issue, as well:  a user who is deploying a single application is
   acutally *more* likely to define and use convenience directives
   which reduce the amount of effort required to change policy than
   the generic appserver-with-plugins configuraiton.  Removing the
   ability to create such convenience declarations makes it harder
   for those developers.

 - Many of the objected-to directives exist precisely because people
   did not want to type the much more verbose equivalents which were
   the original, cleaner spellings.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD8KAe+gerLs4ltQ4RAtREAJwMf91w4eEGbvp0Llz0SKg7bkoTpwCgyDce
rEhfptDFqlhXZjSAZ5FZXxw=
=aIxe
-END PGP SIGNATURE-

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Gary Poster


On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:

On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote:

[...]

+1 to Stephan's comment, Tres' comment, and Tres' use of the word  
ukase (which I had to look up).


-1 to the proposal.

Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Philipp von Weitershausen
Tres Seaver wrote:
  - The opposition to namespace declarations is whiny, as they are the
standard way to make XML extensible.  Unless we are going to quit
using XML, outlawing namespaces would be equivalent to saying, you
may not extend ZCML;  I don't think we are smart enough to make that
ukase.  I think the Last Law of Python according to the Prophet
Peters obtains here as well.

I'm neither trying to follow the whiny people who detest XML and
therefore ZCML nor am I trying to make ZCML not extensible. That said, I
think that ZCML's usage of namespace is quite arbitrary. Why is browser
and mail-related stuff on its own namespace but security-related stuff
not? Why is it then recommended that third-party packages use their own
namespaces, even though they might only have browser-related directives
to register...?

I don't really see the point in ZCML's using namespaces. What good do
they provide? Seriously, is it just the prefix? Well, we don't need the
namespaces for that.

  - Note that the non-XML language also used by Zope (ZConfig) has its
own extensibility mechanism:  in fact, Fred and I made it possible
in November for Zope2 products to register their own schemas for
those extensions, which was a blocker for moving some configuration
out of software.

I'm not sure what to do with this info...

  - I don't want to encourage people to do configuration in Python:

Rest assured neither do I.

we have moved away from that *on purpose* in Zope, and I don't see
a reason to go back.  Directives which make it possible to change
policy decisions without touching software are a Good Thing.  I think
that letting people who spend their days up to the elbows in the
software make choices here skews the picture:  we *want* people to
be able to change the behavior of the system in controlled ways
without having to modify software;  I would prefer to hear feedback
from non-core-developers before going further with the ZCML delenda
est thread.

I have heard such feedback, otherwise I wouldn't have taken the time to
write the proposal. I've also heard positive feedback on this particular
matter (reducing ZCML namespaces to one). Again, I wouldn't have brought
it up otherwise.

  - The application vs plugin discussion is probably germane to this
issue, as well:  a user who is deploying a single application is
acutally *more* likely to define and use convenience directives
which reduce the amount of effort required to change policy than
the generic appserver-with-plugins configuraiton.  Removing the
ability to create such convenience declarations makes it harder
for those developers.

This belongs in the other thread, really. But here it goes anyway:

I'm not convinced that people who deploy apps will actually go as deep
as editing package ZCML, or even overrides for that matter. I would
rather imagine they turn ZCML features on or off (which would then turn
on or off ZCML directives via zcml:condition)

  - Many of the objected-to directives exist precisely because people
did not want to type the much more verbose equivalents which were
the original, cleaner spellings.

Or perhaps people just thought that people wouldn't want to type in some
extra stuff. Because I think they do if it helps them remember and
understand better.

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Stephan Richter
On Monday 13 February 2006 10:05, Tres Seaver wrote:
  - I don't want to encourage people to do configuration in Python:
    we have moved away from that *on purpose* in Zope, and I don't see
    a reason to go back.  Directives which make it possible to change
    policy decisions without touching software are a Good Thing.  I think
    that letting people who spend their days up to the elbows in the
    software make choices here skews the picture:  we *want* people to
    be able to change the behavior of the system in controlled ways
    without having to modify software;  I would prefer to hear feedback
    from non-core-developers before going further with the ZCML delenda
    est thread.

  - The application vs plugin discussion is probably germane to this
    issue, as well:  a user who is deploying a single application is
    acutally *more* likely to define and use convenience directives
    which reduce the amount of effort required to change policy than
    the generic appserver-with-plugins configuraiton.  Removing the
    ability to create such convenience declarations makes it harder
    for those developers.

  - Many of the objected-to directives exist precisely because people
    did not want to type the much more verbose equivalents which were
    the original, cleaner spellings.


Mmmh, I had totally forgotten about this design goal/use case. Thanks a lot 
for pointing this out. I will not change my vote on the other proposal, but I 
think we have to keep this in mind when talking about ZCML simplification.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:
 Tres Seaver wrote:
 
 - The opposition to namespace declarations is whiny, as they are the
   standard way to make XML extensible.  Unless we are going to quit
   using XML, outlawing namespaces would be equivalent to saying, you
   may not extend ZCML;  I don't think we are smart enough to make that
   ukase.  I think the Last Law of Python according to the Prophet
   Peters obtains here as well.
 
 
 I'm neither trying to follow the whiny people who detest XML and
 therefore ZCML nor am I trying to make ZCML not extensible. That said, I
 think that ZCML's usage of namespace is quite arbitrary. Why is browser
 and mail-related stuff on its own namespace but security-related stuff
 not?

I'm not arguing (here) against refactoring the namespaces in which
core directives are declared.  I'm arguing against the idea that
namespaces are bad in general.

 Why is it then recommended that third-party packages use their own
 namespaces, even though they might only have browser-related directives
 to register...?

Third-party packages which don't define new directives don't need their
own namespaces.  If, for instance, Plone adds a plone:view directive
which is nothing more than a no-op wrapper around 'browser:view', that
would be a Bad Thing (TM).  If, however, they add a 'plone:frobnatz'
directive which does something magical and outside the scope of the Zope
core, and document how to use it when setting up Plone, that would be a
Good Thing, especially if it kept people from changing site policy by
customizing software.

 I don't really see the point in ZCML's using namespaces. What good do
 they provide? Seriously, is it just the prefix? Well, we don't need the
 namespaces for that.

ZCML *must* support extensibility, and therefore must continue to allow
packages to register their own namespaces (unless we abandon XML
altogether).  Otherwise, we give up the ability to check that a given
directive can actually be interpreted at all, which would be a Bad Thing.

 - Note that the non-XML language also used by Zope (ZConfig) has its
   own extensibility mechanism:  in fact, Fred and I made it possible
   in November for Zope2 products to register their own schemas for
   those extensions, which was a blocker for moving some configuration
   out of software.
 
 
 I'm not sure what to do with this info...

Just note that being able to extend the configuration language from
non-core code is an important use case.

 - I don't want to encourage people to do configuration in Python:
 
 
 Rest assured neither do I.
 
 
   we have moved away from that *on purpose* in Zope, and I don't see
   a reason to go back.  Directives which make it possible to change
   policy decisions without touching software are a Good Thing.  I think
   that letting people who spend their days up to the elbows in the
   software make choices here skews the picture:  we *want* people to
   be able to change the behavior of the system in controlled ways
   without having to modify software;  I would prefer to hear feedback
   from non-core-developers before going further with the ZCML delenda
   est thread.
 
 
 I have heard such feedback, otherwise I wouldn't have taken the time to
 write the proposal. I've also heard positive feedback on this particular
 matter (reducing ZCML namespaces to one). Again, I wouldn't have brought
 it up otherwise.

A lot of the feedback seemed to be along the lines of:

  - ZCML sux -- I won't use Zope3 until it is gone!  They weren't
gonna use it anyway.

  - Why do I have to declare the namespaces? (XML haters, for the most
part;  note that I am not an XML fanboy myself).

  - Why does the core use more than one namespace?  This question
seems legitimate to me:  I think we wanted to allow non-mangled
names for otherwise conflicting directives, e.g. 'browser:view'
and 'xmlrpc:view'.

 - The application vs plugin discussion is probably germane to this
   issue, as well:  a user who is deploying a single application is
   acutally *more* likely to define and use convenience directives
   which reduce the amount of effort required to change policy than
   the generic appserver-with-plugins configuraiton.  Removing the
   ability to create such convenience declarations makes it harder
   for those developers.
 
 This belongs in the other thread, really. But here it goes anyway:
 
 I'm not convinced that people who deploy apps will actually go as deep
 as editing package ZCML, or even overrides for that matter. I would
 rather imagine they turn ZCML features on or off (which would then turn
 on or off ZCML directives via zcml:condition)

Nope.  You are ignoring the cases which are currently done TTW in Zope2:
mailhost configuration, for instance, or caching policies, etc.  If
an application wants to add a diretive which makes it possible to
configure such policies in ZCML, why should we prevent that?

 - Many of the 

[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Philipp von Weitershausen
Tres Seaver wrote:
- The opposition to namespace declarations is whiny, as they are the
  standard way to make XML extensible.  Unless we are going to quit
  using XML, outlawing namespaces would be equivalent to saying, you
  may not extend ZCML;  I don't think we are smart enough to make that
  ukase.  I think the Last Law of Python according to the Prophet
  Peters obtains here as well.


I'm neither trying to follow the whiny people who detest XML and
therefore ZCML nor am I trying to make ZCML not extensible. That said, I
think that ZCML's usage of namespace is quite arbitrary. Why is browser
and mail-related stuff on its own namespace but security-related stuff
not?
 
 I'm not arguing (here) against refactoring the namespaces in which
 core directives are declared.  I'm arguing against the idea that
 namespaces are bad in general.

I'm not arguing that either. I'm just saying that one namespace is
sufficient.

Why is it then recommended that third-party packages use their own
namespaces, even though they might only have browser-related directives
to register...?
 
 
 Third-party packages which don't define new directives don't need their
 own namespaces.  If, for instance, Plone adds a plone:view directive
 which is nothing more than a no-op wrapper around 'browser:view', that
 would be a Bad Thing (TM).  If, however, they add a 'plone:frobnatz'
 directive which does something magical and outside the scope of the Zope
 core, and document how to use it when setting up Plone, that would be a
 Good Thing, especially if it kept people from changing site policy by
 customizing software.

Sure, I don't mind the policy-changing frobnatz. After all, that's what
ZCML is for, defining and adjusting policy.

I don't really see the point in ZCML's using namespaces. What good do
they provide? Seriously, is it just the prefix? Well, we don't need the
namespaces for that.
 
 
 ZCML *must* support extensibility, and therefore must continue to allow
 packages to register their own namespaces (unless we abandon XML
 altogether).

I don't see how that conclusion works.

It seems like you think namespaces are needed for extensibility. They
are not. We can add directives to existing namespaces just fine.

XML Namespaces are useful for extending existing XML dialects with stuff
from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and
the like. The way ZCML uses namespaces isn't even half-way compatible
with that. For example, I couldn't add inline-documentation to ZCML
unless I configured no-op directives for my particular documentation
elements, just so that the ZCML machinery wouldn't complain it
encountered unknown directives. Why would it think that they are
directives?

I can add inline-documentation to XSL or, heck, OpenDocument just fine.
ZCML wants to be XML but it's weird about it.

 Otherwise, we give up the ability to check that a given
 directive can actually be interpreted at all, which would be a Bad Thing.

Huh?

- Note that the non-XML language also used by Zope (ZConfig) has its
  own extensibility mechanism:  in fact, Fred and I made it possible
  in November for Zope2 products to register their own schemas for
  those extensions, which was a blocker for moving some configuration
  out of software.


I'm not sure what to do with this info...
 
 
 Just note that being able to extend the configuration language from
 non-core code is an important use case.

I agree it is.

  we have moved away from that *on purpose* in Zope, and I don't see
  a reason to go back.  Directives which make it possible to change
  policy decisions without touching software are a Good Thing.  I think
  that letting people who spend their days up to the elbows in the
  software make choices here skews the picture:  we *want* people to
  be able to change the behavior of the system in controlled ways
  without having to modify software;  I would prefer to hear feedback
  from non-core-developers before going further with the ZCML delenda
  est thread.


I have heard such feedback, otherwise I wouldn't have taken the time to
write the proposal. I've also heard positive feedback on this particular
matter (reducing ZCML namespaces to one). Again, I wouldn't have brought
it up otherwise.
 
 
 A lot of the feedback seemed to be along the lines of:
 
   - ZCML sux -- I won't use Zope3 until it is gone!  They weren't
 gonna use it anyway.

...

   - Why do I have to declare the namespaces? (XML haters, for the most
 part;  note that I am not an XML fanboy myself).

I am *for* declaring XML namespaces. I'm against declaring too many
pointless namespaces.

   - Why does the core use more than one namespace?  This question
 seems legitimate to me:  I think we wanted to allow non-mangled
 names for otherwise conflicting directives, e.g. 'browser:view'
 and 'xmlrpc:view'.

Yes. Using namespaces for this is arbitrary, though. We could just as
well have chosen different names, e.g. browserView and xmlRpcView.

Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Martijn Faassen

Hey,

Good comments, Tres, thanks.

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Martin Aspeli
Martijn Faassen faassen at infrae.com writes:

 What happens if you want to add your own statements? Should you still
 do that in your own namespace?
  
  
  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.

Well, hopefully not, but that doesn't mean it doesn't sometimes make sense. 
Zope should worry about defining what type of configuration ZCML is useful for 
and documenting that. Third party authors should then decide whether their 
configuration fits that same general profile, and if so should be allowed to 
add their own ZCML directives. 

And these sure as hell ought to use namespaces, because they are not part of 
the core Zope namespace. Specifically, they can never be part of any core Zope 
ZCML DTD (and there really should be one!), and they should really have their 
own DTD to validate against. For this to work, they *must* have a separate 
namespace. Flatting the namespace in order to save a few characters of typing 
is akin to braking XML conventions and standards, and not for very good reason.

 Currently I know of five and union.cms doing it. I'm certainly 
 considering doing so for Silva. Then there's the example of many 
 packages in the Zope 3 core which are actually quite independent from 
 the core itself, such as the email package, and may in the future become 
 Zope extensions.
 
 I'd say adding a namespace is a common method for abstracting 
 application specific component configuration tasks. I also don't see 
 what's bad about it and why we'd like to discourage it.

Namespaces are the de-facto way of doing application domains in XML. I really 
don't understand why people fret so much about them. All you have you do is to 
put in your root node:

xmlns:myPrefix=http://mysite.com/dtd/myschema;

That URL doesn't need to be real, it just needs to be a unique identifier. And 
you can choose whatever prefix you want, so if you don't like to type browser, 
how about just b?

I think encouraging third-party developers who *do* need ZCML (and there will 
be times when that makes sense) to not use their own namespace is to ignore 
one of the main conventions of XML and thus become a poor XML citizen.

I agree that ZCML could use some slimming down, and if that lands us with 
something that semantically all belongs in a single zope namespace (and 
recall, if I want, I could use zope as the main unnamed namespace or 
explicit use a prefix for it) so be it. 

But if I write an application that needs some configuration or wiring that 
logically belongs in ZCML, I shouldn't have to invent my own config file 
format and I shouldn't be inventing my own names in a namespace I don't own. 

It's kind of the same as saying that all variables in Python should be global 
because you don't like to write 'from module import foo'. Well ... tough. :)

Martin

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Martin Aspeli
Philipp von Weitershausen philipp at weitershausen.de writes:

 The problem is uncontrolled ZCML directive proliferation. It's bad enough
 that you have to familiarize yourself with a new API when dealing with a 3rd
 party Zope package. But having to learn a new set of ZCML directives?!? I
 think many people would be skeptical. Me included.

Or a new python API... your package will have to come with documentatio about
how it is to be used. If Zope encourages a consistent way of demarcating what is
ZCML-configured, what is python-configured and what is not configuration at all,
this problem will go away.

 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 process for developers (there should
 only be one way of doing things). Yes, you might have to use two or three
 directives instead of just one new one, but you'll know what you're doing...
 And you'll remember it in 2 months. I think that's more valuable than saving a
 couple of lines today.

There is always a balance between the aesthetic beauty of reducing everything to
a few axiomatic principles, and the way people think. I think you'll find that
many people get confused by the view/multi-adapter duality. Yes, it's very neat
when you finally get it, but it took me a long time to get my head around it
(partially, I admit, because I was reading poor documentation... when I read
your book, it made a lot more sense). Be sure to draw a clear line between what
things are the same because the implementation lends itself to use the same
primitive components, and what things are actually semantically equivalent.

 That said, there might still be a small percentage of cases where custom
 directives are a valid tool. I can accept their being on the same namespace as
 others. In fact, I would like it to be that way, reducing the amount of dead
 chickens (namespace declarations).

I think this is based on a misunderstanding of how XML works (or should work)
combined with a somewhat irrational fear of writing a few extra letters. You
don't have to declare namespaces you don't use in any particular file, nor do
you have to stick to long-winded prefixes if you don't want to. The URIs of
namespaces are unique identifiers and can be quite short (e.g.
http://zope.org/dtd/core). Ideally, they should resolve to DTDs that can be used
for XML validation and by tools to create code-completion etc.

Now, if Zope decides that it has a sufficiently small set of concepts to warrant
keeping them in a single namespace, that's probably a good thing - less to
learn, less to remember. If it turns out there are very clear components with
different areas of use, having different namespaces may well work. I'm not a fan
of the core vs. browser namespace separation at the moment, for example, but I
could see how something radically removed from the core Zope use case would find
use for a separate namespace.

But third party products that have not (yet) been rolled into core Zope must
have their own namespace, to avoid clashes, to permit validation, and simply to
meake it clear what is being provided by the third party product.

Martin

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Martin Aspeli
Philipp von Weitershausen philipp at weitershausen.de writes:
 
  I'm not arguing (here) against refactoring the namespaces in which
  core directives are declared.  I'm arguing against the idea that
  namespaces are bad in general.
 
 I'm not arguing that either. I'm just saying that one namespace is
 sufficient.

It may be sufficient for Zope itself (I don't know if it is, I haven't reviewed
all current ZCML directives and use cases), but it won't be sufficient for
third-party extension or anything else that wants to use ZCML for its own
purposes, which seemed to be the argument higher up the thread. If I
misunderstood you on that point, please accept my apologies. 
 
 I am *for* declaring XML namespaces. I'm against declaring too many
 pointless namespaces.

Then I misunderstood you earlier. I'm sorry for that.

 
- Why does the core use more than one namespace?  This question
  seems legitimate to me:  I think we wanted to allow non-mangled
  names for otherwise conflicting directives, e.g. 'browser:view'
  and 'xmlrpc:view'.
 
 Yes. Using namespaces for this is arbitrary, though. We could just as
 well have chosen different names, e.g. browserView and xmlRpcView.

Erm... you can if you want, just use a different xmlns:browserView. It's up to
the person writing the XML file, although conventions are useful.

  Nope.  You are ignoring the cases which are currently done TTW in Zope2:
  mailhost configuration, for instance, or caching policies, etc.  If
  an application wants to add a diretive which makes it possible to
  configure such policies in ZCML, why should we prevent that?
 
 Very true, I forgot to mention that use case. But I also never put them
 on my hit list, for exactly the reason you mention: They are about
 policies and configuring code components.
 
 So, yes, deployers will edit ZCML directives, but on a limited scale.
 Would they configure a DAV namespace adapter? I would think not.

+1

Martin




___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Martin Aspeli
Gary Poster gary at zope.com writes:

 
 
 On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Stephan Richter wrote:
  On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote:
 [...]
 
 +1 to Stephan's comment, Tres' comment, and Tres' use of the word  
 ukase (which I had to look up).

It wasn't a spelling mistake? ...

ukase \yoo-KAYS; -KAYZ; YOO-kays; -kayz\, noun:
1. In imperial Russia, a published proclamation or order having the force of 
law.
2. Any order or decree issued by an authority; an edict.

 -1 to the proposal.

+1 to Gary's +1's and -1's.

However, I think a review of namespace *usage* in Zope 3 at present is a good
idea, as opposed to outlawing them entirely.

Martin

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philipp von Weitershausen wrote:

 Tres Seaver wrote:

snip

I'm not arguing (here) against refactoring the namespaces in which
core directives are declared.  I'm arguing against the idea that
namespaces are bad in general.
 
 
 I'm not arguing that either. I'm just saying that one namespace is
 sufficient.

Not if you need to mangle names to avoid clashes.

snip

I don't really see the point in ZCML's using namespaces. What good do
they provide? Seriously, is it just the prefix? Well, we don't need the
namespaces for that.


ZCML *must* support extensibility, and therefore must continue to allow
packages to register their own namespaces (unless we abandon XML
altogether).
 
 
 I don't see how that conclusion works.
 
 It seems like you think namespaces are needed for extensibility. They
 are not. We can add directives to existing namespaces just fine.

I don't want to encourage third-party applications to inject their names
into stock namespaces, because then I can't safely mix unrelated
third-party packages without chasing down conflicts.

 XML Namespaces are useful for extending existing XML dialects with stuff
 from others. E.g. embedding SVG into HTML, adding TAL/METAL to HTML, and
 the like. The way ZCML uses namespaces isn't even half-way compatible
 with that. For example, I couldn't add inline-documentation to ZCML
 unless I configured no-op directives for my particular documentation
 elements, just so that the ZCML machinery wouldn't complain it
 encountered unknown directives. Why would it think that they are
 directives?

 I can add inline-documentation to XSL or, heck, OpenDocument just fine.
 ZCML wants to be XML but it's weird about it.

I don't want DocBook in my ZCML, personally.  De gustibus again.  At
the moment, ZCML does assume that all elements in a ZCML file belong to
it.  If you wanted to add DocBook to your ZCML, then you could add a
meta.zcml file which registered faux handlers for the docbook elements;
 you might also add a directive to ZCML which instructed it to ignore
all nodes from a given namespace.

Otherwise, we give up the ability to check that a given
directive can actually be interpreted at all, which would be a Bad Thing.
 
 Huh?

Right now, ZCML does a syntax check on the files it processes, and barfs
on elements it doesn't understand.  I don't want to lose that check if
the only benefit is the ability to inline foreign elements.  Again, I
wouldn't mind some syntax which told ZCML to ignore names from
particular foreign namespaces.

snip


A lot of the feedback seemed to be along the lines of:

  - ZCML sux -- I won't use Zope3 until it is gone!  They weren't
gonna use it anyway.
 
 
 ...
 
 
  - Why do I have to declare the namespaces? (XML haters, for the most
part;  note that I am not an XML fanboy myself).
 
 
 I am *for* declaring XML namespaces. I'm against declaring too many
 pointless namespaces.

Now we are getting close to 'de gustibus' territory.  Your proposal
seems to make a claim that we don't / won't need more than one
namespace, while the ones we have are there because people were trying
to avoid name clashes.  There may be some which could be refactored
away, but I don't think that is the same point the proposl si trying to
make.

  - Why does the core use more than one namespace?  This question
seems legitimate to me:  I think we wanted to allow non-mangled
names for otherwise conflicting directives, e.g. 'browser:view'
and 'xmlrpc:view'.
 
 Yes. Using namespaces for this is arbitrary, though. We could just as
 well have chosen different names, e.g. browserView and xmlRpcView.

I don't think that was arbitrary all:  we use namespaces *as they are
designed* here, to allow people to use natural names for things
without worrying whethere they clash with names which are equally
natural in another domain.

This is why Python has namespaces, too:

  import this
 ...
 Namespaces are one honking great idea -- let's do more of those!

- The application vs plugin discussion is probably germane to this
 issue, as well:  a user who is deploying a single application is
 acutally *more* likely to define and use convenience directives
 which reduce the amount of effort required to change policy than
 the generic appserver-with-plugins configuraiton.  Removing the
 ability to create such convenience declarations makes it harder
 for those developers.

This belongs in the other thread, really. But here it goes anyway:

I'm not convinced that people who deploy apps will actually go as deep
as editing package ZCML, or even overrides for that matter. I would
rather imagine they turn ZCML features on or off (which would then turn
on or off ZCML directives via zcml:condition)

Nope.  You are ignoring the cases which are currently done TTW in Zope2:
mailhost configuration, for instance, or caching policies, etc.  If
an application wants to add a diretive which makes it possible to
configure such policies 

Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Sidnei da Silva
On Mon, Feb 13, 2006 at 03:31:49PM -0500, Tres Seaver wrote:
| This is why Python has namespaces, too:
| 
|   import this
|  ...
|  Namespaces are one honking great idea -- let's do more of those!

Someone argued in the python-brasil list that let's do more of those
actually refers to 'one honking great idea', thus meaning let's do
more of those great ideas (like namespaces).

Now whether that's that's the correct interpretation is up to the
original author (Tim Peters?) to clarify :)

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Fred Drake
On 2/13/06, Sidnei da Silva [EMAIL PROTECTED] wrote:
 Someone argued in the python-brasil list that let's do more of those
 actually refers to 'one honking great idea', thus meaning let's do
 more of those great ideas (like namespaces).

This is the first time I've heard that interpretation.

 Now whether that's that's the correct interpretation is up to the
 original author (Tim Peters?) to clarify :)

I don't know if he's paying attention to this thread, but I'm fairly
certain everyone at PythonLabs understood that to refer to namespaces.
 If Tim would like to counter that, he's certainly free to do so, of
course.  :-)


  -Fred

--
Fred L. Drake, Jr.fdrake at gmail.com
There is no wealth but life. --John Ruskin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: One namespace for ZCML

2006-02-13 Thread Joseph Method
Quick in-and-out from a lurker: yesterday as I was learning how to use
Five with Plone, I thought to myself, wouldn't it be cool if there
were two directives, cmf:installable and cmf:registerContentClass?
This is from someone who's totally naive about zcml. Was this evil on
my part? Because the debate seems to be about behaviors that are
implicitly encouraged.

 Third-party packages which don't define new directives don't need their
 own namespaces.  If, for instance, Plone adds a plone:view directive
 which is nothing more than a no-op wrapper around 'browser:view', that
 would be a Bad Thing (TM).  If, however, they add a 'plone:frobnatz'
 directive which does something magical and outside the scope of the Zope
 core, and document how to use it when setting up Plone, that would be a
 Good Thing, especially if it kept people from changing site policy by
 customizing software.

--
-J. Method
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com