Martijn Faassen wrote:
Yes, but Zope 2 included *less* than Zope 3 in the most recent
release, and I'd like *all* packages that are in a Zope 3 release to
be available in a Zope 2 release. I.e. Five doesn't want packages
that aren't in a Zope 3 release, but not less either.
I'm surprised
Jim Fulton wrote:
Perhaps we should start actively deprecating many ZCML directives?
This will require some volunteer effort to do it well.
I hereby volunteer. :)
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
Martijn Faassen wrote:
After thinking about it for a little bit, -1.
Same here.
I too am all for experimenting with new ways of expressing component
configuration. That can include the amount of what we configure in ZCML,
the semantics and the syntax. There should be no tabus. Before we go
Jim Fulton wrote:
See:
http://dev.zope.org/Zope3/ZConfigAndOtherFormatsForZCML
Comments and volunteers welcome.
I like this proposal. It is likely to reduce the total amount of code.
However, I want to be sure that consolidating engines is the real
focus of the proposal.
Fred Drake wrote:
I find it irksome to have to type them at the top of ever file. Is there
no way that they could be pre-bound in the XML parser? That way you'd
only need to inlcude them if you wanted to rebind them...
Even if we could avoid it at a technical level, it means that what
we're
Chris Withers wrote:
(and if we can get it down to one, we don't have to specify it at the
top of the file... yay!)
Not really. Specifying no namespace at all is not the same as specifying the
namespace of prefix-less elements. Even with one namespace the declaration of
that namespace is still
Shane Hathaway wrote:
Any thoughts or gut reactions?
For the record, my gut reaction: Very interesting idea!
I think there are two parts to the rationale here:
1) Making it easy to quickly prototype an app on the filesystem using
methods that people are familiar with. You mention that above.
Chris McDonough wrote:
I'm told that the ZODB is the de-facto way of storing content. Maybe
soon the default may be a filesystem. Mmm...
My feelings are that there should be a classic Zope 3 release which
is exactly what exists now (it should make the assumption that ZODB is
present
Jim Fulton wrote:
Some recent discussions on the distutils-sig mailing list have
helped me to understand some issues related to the ways we
extend the Zope application server. Traditionally, in Zope 2,
you extended Zope by dropping product packages into a special
Products package. This was
Martijn Faassen wrote:
Just to drop a note that I think a discussion about a potential brand
name for Zope 3 is far less important than actually fixing our website
and presenting Zope 3 (and Zope 2 for that matter) in a better way.
Perhaps we can better redirect our energies to that than to
Martijn Faassen wrote:
With a package in the 'zope' namespace, what am I supposed to do when I
install it? Symlink it into lib/python of my Zope 3 software home?
For the record: no.
You can simply have multiple directories for a namespace package when
you use 'pkgutil'. See
Hi all,
looking for your comments at
http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives :)
This is a formal follow-up on my blog post on ZCML a while back
(http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less).
I expect there will be more proposals
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
Lennart Regebro wrote:
I don't think it's about saving lines, but about saving headaches. ;-)
Having to remember how all of the mentioned directives work *does* give me a
headache. I actually remember quite well how the utility and interface
directives work and they are the replacement for most
Stephan Richter wrote:
On Monday 13 February 2006 06:08, Philipp von Weitershausen wrote:
looking for your comments at
http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives :)
I am +1 for the proposed directives, in general.
Cool.
I am waiting for a proposal on the Potential follow
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
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
Martijn Faassen wrote:
I would like to highlight Lennart's point. We need to be very careful
here. We would only have an illusion of improvement if we'd end up with
less directives but more long dotted names into Python packages. I'd
argue that this might make ZCML *harder* to understand, not
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Lennart Regebro wrote:
Uhm. -1, actually. I think getting things out of ZCML is a good idea,
but I think this shoots slightly beside the goal. This proposal aims
mostly at getting rid of statements that can be done with other
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
Hi everyone,
Jim said that he wants zope.app to become smaller. I would welcome that.
Is it time for this to be thought about?
For various reasons, mostly personal ones, I would consider Zope
3.3/2.10 a good point for this to be done. If others agree, we should
get started, especially since we
Stephan Richter wrote:
Jim said that he wants zope.app to become smaller. I would welcome that.
Is it time for this to be thought about?
For various reasons, mostly personal ones, I would consider Zope
3.3/2.10 a good point for this to be done. If others agree, we should
get started, especially
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
Dear all,
thanks to everyone who commented my two proposals on simplifying ZCML.
Here are some updates:
Reducing the amount of ZCML directives
--
I've updated this proposal slightly. It now mentions the important
characteristics of ZCML directives and lists
Chris Withers wrote:
[aside... hmmm, crossposting, maybe time to merge zope-dev and
zope3-dev? most stuff seems to be relevent to both nowadays]
+10
You know, I once had a proposal. Uh, never mind :)
In Zope 3, we went with a more explicit installation mechanism,
in which people had to
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
Dear Tonico,
thanks for your input.
In CMF things are very easy to understand, because a layer is simply a
folder. I can explain that in five minutes to a template programmer.
Why does the template programmer need to know about layers?
Maybe this sounds a bit NAIVE, but would it be possible
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
Lennart Regebro wrote:
I think I agree. This to me makes sense. If it were nameless (are
there nameless utilities) you could then get off with just utility
component=.alias.sydneyFactory / which is then the on/off switch we
mentioned earlier. And an adapter should be registered the same way
Tonico Strasser wrote:
In CMF things are very easy to understand, because a layer is simply a
folder. I can explain that in five minutes to a template programmer.
Why does the template programmer need to know about layers?
Because in CMF, if you want to customize or create a skin, you need
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
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
Jeff Shell wrote:
I find Zope 3's approach much simpler and much easier to explain than
the CMF's approach. In Zope 3 (especially with my proposed changes in
place), a layer is simply a label (read: marker interface) on the
request. When we now look up pages and resources (e.g. images), we
Hey Gary,
thanks for your feedback.
I like many parts of it. I didn't like the fact that the zcml ended
up being longer.
Me neither :(.
I didn't love that people had to start asking
questions about interface types in order to register a skin.
Interface types are a cost--another layer of
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
Gary Poster wrote:
On Feb 16, 2006, at 12:09 AM, Philipp von Weitershausen wrote:
[...interface... change counter-counter-proposal...]
I think that's a very nice improvement over the previous spellings. I
had to review the zope.app.component.interface.provideInterface code,
but yes
Fred Drake wrote:
I would prefer not. We've used resourceDirectory to support things
like webcams. The image(s) uploaded by the cams might not always be
there, but the containing path is. It's nice not having Zope start
Good point.
If it was sugar for a set of resource directives, this
Benji York wrote:
One downside to the expanded interface directive is that it hides the
fact that a utility is also being created. I actually prefer the
browser:skin version because it totally hides the underlying atomic
operations, but the interface-also-registers-a-utility version
Hi all,
for ages now the magic of browser:page co. has annoyed me to a great extent.
I know their handler code well (we had to duplicate a lot of it for Five) and
think we can do better.
I've brainstormed about potential ways of making the creation of browser pages
more Pythonic (whatever that
Andrew Milton wrote:
+---[ Stephan Richter ]--
| Hello everyone,
|
| With the development of Zope 3, the Zope developers committed to a new
| development process and higher software quality guidelines. With the
adoption
| of Zope 3 technologies in the wider Zope
Andrew Milton wrote:
+---[ Philipp von Weitershausen ]--
| Andrew Milton wrote:
| +---[ Stephan Richter ]--
| | Hello everyone,
| |
| | With the development of Zope 3, the Zope developers committed to a new
| | development process
Andrew Milton wrote:
+---[ Philipp von Weitershausen ]--
|
| Handing over ownership to the ZF and therefore having signed a
| Contributor Agreement are the terms of the svn.zope.org repository, just
| like that code is to be made ZPL.
The license part is irrelevant
Andrew Milton wrote:
+---[ Philipp von Weitershausen ]--
|
| | * putting a project/package under the wings of the ZF ensures long-term
| | IP protection
|
| How? I think my death + 70 years is further away than the death of ZF, or
in
| fact the death of Zope
Hi there,
a large portion of http://dev.zope.org//SimplifySkinning has been
implemented in the philikon-simplify-skinning branch. Please check it
out and give me feedback. The 'Browser Skin Names' vocabulary has not
been implemented yet. This is a no-brainer and will follow tomorrow or so.
Andrew Sawyers wrote:
a large portion of http://dev.zope.org//SimplifySkinning has been
implemented in the philikon-simplify-skinning branch. Please check it
out and give me feedback. The 'Browser Skin Names' vocabulary has not
been implemented yet. This is a no-brainer and will follow tomorrow or
Dominik Huber wrote:
Now that this proposal has been dealt with, I will turn my focus of
attention to
http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. Since my
initial announcement of the proposal I made some minor ammendments
regarding the 'content' directive. Please check them
Gary Poster wrote:
Dominik Huber wrote:
Now that this proposal has been dealt with, I will turn my focus of
attention to
http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives.
[...]
I like those simplifications, but I have two little objections...
[...]
The class/implements
Jim Fulton wrote:
2) In an alternate vision, Zope 2 evolves to Zope 5.
+1 as already discussed at PyCON.
- Zope 5 will be the application server generally known as Zope. It
will be backward compatible (to the same degree that Zope 2
releases are currently backward compatible
Martijn Faassen wrote:
I will also note that just because Zope 2 won't die, it doesn't mean we
shouldn't clean it up. Eventually, Zope should mostly be reusing things
from Zed.
+sys.maxint
I think this will be the way we get a real forward migration path for an
awful lot of us who are
Stephan Richter wrote:
1) Our current vision (AFAIK) is that Zope 3 will eventually
replace Zope 2
2) In an alternate vision, Zope 2 evolves to Zope 5.
As you probably know already, I am -1 on the second proposal, since it will
disallow us to finally get rid of the old Zope 2 code.
Martijn Faassen wrote:
I see Zope 5 being a combination of Zope 2 and Zope 3, keeping
the best of both.
I think we already have Zope 5, and it's called Zope 2.9.
I'd rather say it's called Zope 2.15 or something :).
Philipp
___
Zope3-dev mailing
Martijn Faassen wrote:
I think focusing on one app server and a dedicated set of libraries
would be a good alternative to two concurring app servers.
...if the single app server is based on acquisition,
__bobo_traverse__ and friends, objectValues and friends, ZCatalog,
and so on, I'd
Stefane Fermigier wrote:
I think that the idea of giving Zed its own, distinct identity is great.
I think it is stupid.
We (Zope Corp + the Zope Community) have spent 8 years building the Zope
brand, and you want to restart from scratch ?
Good point. There's the question: Does this zed
Stefane Fermigier wrote:
Strange how (most of) the Plone people seem to be so quick in willing to
sacrifice the Zope brand :(
It's not about sacrificing the Zope-the-app-server brand. It's actually
about growing it in the sense that it becomes much clearer WHAT THE HELL
Zope actually is. Or can
Benji York wrote:
Good point. There's the question: Does this zed thing need a different
name at all? If we want other people to pick it up, then it seems like a
good idea to distinguish it from Zope-the-app-server. Paul seems to
suggest that in his response.
How about zopelib?
If we want
Stephan Richter wrote:
On Tuesday 07 March 2006 12:28, Andreas Jung wrote:
Writing a parser for some kind of INI format or ZConfig-style parser is an
engineering task for an average programmer..I think we should discuss the
framework and not a particular format (I agree with Dieter: it's
Jim Fulton wrote:
Log message for revision 65931:
Redeprecated a number of things that didn't generate warnings
before. Sigh. Also fixed all the depecation warnings generated by
running the zope.component tests.
...
Added: Zope3/branches/jim-adapter/src/zope/component/back35.py
Florian Lindner wrote:
I think ovarall, Phillip should support those named layers.
That feedback is a little late. The proposal had been around for months!
By the way, from what I read in the old layer code (which seemed to be
yours), I got the impression that named layers and skins were slated
Lennart Regebro wrote:
On 3/10/06, Martijn Faassen [EMAIL PROTECTED] wrote:
For instance, one that looks like this:
zope:annotation for=IBar factory=Foo /
That doesn't look like configuration.
No, it's an on/off switch. Me likesss it.
Philipp
Marius Gedminas wrote:
I'd prefer
from zope.annotation.adapter import AnnotationAdapter
getFoo = AnnotationAdapter(for_=IBar,
interface=IFoo,
factory=Foo,
key=FOO_KEY)
# I suppose
Jim Fulton wrote:
I didn't see evidence of deprecation warnings. These methods didn't
generate warnings. The code:
from bbb import *
or
from bbb import x, y, ...,
is, sadly, quite common and generates no warnings.
The import doesn't, but the use of each method did because they
Stephan Richter wrote:
On Tuesday 14 March 2006 17:26, Philipp von Weitershausen wrote:
The import doesn't, but the use of each method did because they looked
like this:
def getView(object, name, request, providing=Interface, context=None):
if __warn__:
warnings.warn
Martijn Faassen wrote:
I stand by my conclusions on this approach sounding simple in theory,
but still being a bit harder than it should be in practice. :)
I think this is pretty simple:
def makeAnnotationAdapter(for_, factory, key):
@zope.component.adapter(for_)
Hi all,
my work on http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives
has been nearly completed on the philikon-reduce-zcml branch and is
ready for review.
What I didn't cover:
* rdb:provideConnection wasn't removed. On a second thought, this
directive also contains deployment
Stephan Richter wrote:
I am -1 on moving implements out of the class directive. I am impartial on
the factory subdirective, since I never use it. I think factories are failed
experiment, btw, but that's another story.
If implements is moved out than what's the point of having a class
Philipp von Weitershausen wrote:
If no one objects to the branch as it is, I will merge it on the weekend.
Done now.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Dominik Huber wrote:
I really appreciate your effort in all other cases, but in this case I
think its not a simplification.
At least in case of class/implements it is. I'm merging two directives,
class/implements and five:implements into one.
The case of class/factory is arguable, I admit.
Martijn Faassen wrote:
Using proposals for communicating development-level changes is not
ideal. This is why Python has a separate what changed in Python 2.x
document series, which is actually readily comprehensible, as opposed to
many of the PEPs.
And kudos to Andrew Kuchling for writing
Martijn Faassen wrote:
Using proposals for communicating development-level changes is not
ideal. This is why Python has a separate what changed in Python 2.x
document series, which is actually readily comprehensible, as opposed to
many of the PEPs.
And kudos to Andrew Kuchling for writing
Stephan Richter wrote:
I am -1 on moving implements out of the class directive. I am impartial
on the factory subdirective, since I never use it. I think factories are
failed experiment, btw, but that's another story.
If implements is moved out than what's the point of having a class
directive in
Tres Seaver wrote:
I really appreciate your effort in all other cases, but in this case I
think its not a simplification.
At least in case of class/implements it is. I'm merging two directives,
class/implements and five:implements into one.
The case of class/factory is arguable, I admit.
Roger Ineichen wrote:
class LanguagesVocabulary(SimpleVocabulary):
... languages from a translation domain.
implements(ILanguagesVocabulary)
def __init__(self, context, domain='zope'):
terms = []
# collect languages from translation domain
Roger Ineichen wrote:
Philipp von Weitershausen schrieb:
Roger Ineichen wrote:
class LanguagesVocabulary(SimpleVocabulary):
... languages from a translation domain.
implements(ILanguagesVocabulary)
def __init__(self, context, domain='zope'):
terms
Jean-Marc Orliaguet wrote:
Is there any reason for not being able to unregister global utilities?
Usually there are registered at startup in ZCML, but they can also be
registered programatically with provideUtility().
let's say that the startup process is done and my application wants to
Jean-Marc Orliaguet wrote:
Is there any reason for not being able to unregister global utilities?
Usually there are registered at startup in ZCML, but they can also be
registered programatically with provideUtility().
let's say that the startup process is done and my application wants to
Roger Ineichen wrote:
Philipp von Weitershausen schrieb:
Roger Ineichen wrote:
You implemented a concept which requires to write additional
python code for registration!
Wrong. I require addition python code for *creation*. *Registration* is
still done in ZCML. Please understand
Florian Lindner wrote:
Hello,
I want show a deprecation warning only if a argument of a function is set to
False.
def foo(arg1, arg2, arg3 = False):
if not arg3:
arg3 = deprecation.deprecated(arg3, arg3=False is deprecated.)
But that does not show anything. How do it
Hi Stephan,
thanks for your input.
Good work. Here a general comment. Sometimes we broke up a package into
zope.X
and zope.app.X to have a very basic package for other projects and a more
Zope specific one. In this case you might want to merge the two, but this
would create new
Now it's official: http://dev.zope.org/Zope3/MakeZopeAppSmaller
If anyone's interested in helping me with the implementation, you know
where to find me :).
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
Jim Fulton wrote:
Obviously, I'm in favor of this. I fear though that this will cause me
a lot of pain. I'm in the middle of a bit of a geddon on the jim-adapter
branch. The valuable work you propose is probably going to make my merge
a lot harder. I hope to be ready to merge by branch in
Michael Kerrin wrote:
Modified: Zope3/trunk/test.py
===
--- Zope3/trunk/test.py 2006-04-04 08:46:11 UTC (rev 66372)
+++ Zope3/trunk/test.py 2006-04-04 10:02:50 UTC (rev 66373)
@@ -57,6 +57,9 @@
# Get rid of
Hi all,
after some implementation, some feedback, some discussions and some more
thinking, I've updated the Make zope.app smaller proposal (a.k.a.
PackageGeddon Directors Cut).
See http://dev.zope.org/Zope3/MakeZopeAppSmaller. There's a list of
changes since the initial version of the proposal.
Pjotr Prins wrote:
I have a few questions regarding the ZOPE mailer implementation:
1. Why did you go for a file system implementation - as ZODB objects
are being made into a mail queue anyway?
The mail queue doesn't create persistent objects.
The Maildir step could have been skipped, I
Tarek Ziadé wrote:
Modified: Zope3/trunk/src/zope/app/file/browser/tests/test_imagedata.py
===
--- Zope3/trunk/src/zope/app/file/browser/tests/test_imagedata.py
2006-04-09 21:31:11 UTC (rev 66754)
+++
Fred Drake wrote:
I have a need for 64-bit BTrees (at least for IOBTree and OIBTree),
and I'm not the first. I've created a feature development branch for
this, and checked in my initial implementation.
I've modified the existing code to use PY_LONG_LONG instead of int for
the key and/or
Chris Withers wrote:
Philipp von Weitershausen wrote:
in memory. Dieter estimates 20% to 35% slowdown for the C algorithms
(whatever that means), Tim seems to think it won't have such a big
effect. I guess we'll only know after some benchmarks.
Can we please not make any definite decisions
http://dev.zope.org/Zope3/TheBrowserPageCompromise
I've long been thinking about how to make browser:page / simpler and
less magical. Some radical ideas weren't received well and I couldn't
convince even myself 100% that they were the way to go. Other
brainstormings were dead ends.
I therefore
Rocky Burt wrote:
On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote:
http://dev.zope.org/Zope3/TheBrowserPageCompromise
I've long been thinking about how to make browser:page / simpler and
less magical. Some radical ideas weren't received well and I couldn't
convince even
Tres Seaver wrote:
Philipp von Weitershausen wrote:
http://dev.zope.org/Zope3/TheBrowserPageCompromise
I've long been thinking about how to make browser:page / simpler and
less magical. Some radical ideas weren't received well and I couldn't
convince even myself 100% that they were the way
Rocky Burt wrote:
On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote:
A browser page is something that's published. It provides
IBrowserPublisher and returns some data to the pbulisher that's in turn
returned to the agent.
A browser view is something more general
[EMAIL PROTECTED] wrote:
I'll be fine with creating new directives instead of changing
the old ones, if that's what the majority prefers. But then
I'd very much like to see a Death Certificate for the old
directives made out for some time in the future (doesn't have
to be 2 releases,
Philipp von Weitershausen wrote:
[EMAIL PROTECTED] wrote:
I'll be fine with creating new directives instead of changing
the old ones, if that's what the majority prefers. But then
I'd very much like to see a Death Certificate for the old
directives made out for some time in the future
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Introducing new deprecation warnings in third-dot releases is
probably inappropriate:
When we have we done this?
2.9.1 just did it (see below).
- Deprecating an API without cleaning up *all* core uses is a *lie
[EMAIL PROTECTED] wrote:
That confuses me even more. I *am* proposing changes to the
browser:page directive...
Hmm, never mind. I think I understand what you mean. You'd
like to see new directives, instead of changing the old ones. Right?
Yes, I think it's very important to bring a little
Kamal Gill wrote:
Stability is especially important for those of us learning Zope 3, as
well as those who offer Zope 3 training. I realize Z3 is a fast-moving
target, but making existing books and documentation obsolete doesn't
help the adoption of such a fantastic collection of software,
101 - 200 of 605 matches
Mail list logo
