On 6/5/07, Gary Poster <[EMAIL PROTECTED]> wrote:
In the past we have wanted the dots to effectively guarantee page
component "namespaces".
I think we still want this.
Hyphens should work just fine.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry
On 7/4/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
I propose we stop bothering to include $Id$ strings. (Note that I'm
*not* suggesting we go out of our way to remove them.)
+1
These have never proved anything more than distractions. Avoiding
them in the future is the way to go. Removing them
On 7/5/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
Right. Many of us have that, but it's hard to get everyone to set
that up on every machine they use.
More importantly, because that's a global setting for the Subversion
client, instead of something retrieved from the server, setting it
affects a
On 7/8/07, Christian Theune <[EMAIL PROTECTED]> wrote:
> Please revert. The solution is to rip out setting the value from within the
field
> altogether.
Humm. Ripping out setting the value from within the field doesn't make
sense to me. The field is the only demonitator between zope.app.form an
On 7/10/07, Marius Gedminas <[EMAIL PROTECTED]> wrote:
in addition to emitting a deprecation warning, perhaps?
There's no need to deprecate action(), and I suspect no value in doing
so, either.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Mille
On 7/10/07, Christian Theune <[EMAIL PROTECTED]> wrote:
We never said anything else. We planned for some future to stop doing
that, I never saw a proposal get accepted that changes the release in
this way. Did I miss something?
Interesting. I don't recall seeing anyone mention a 3.5 release at
Brian Sutherland wrote:
The important part is:
"A copy of the ZPL should accompany this distribution."
Hmm. I've never thought of the svn checkouts as distributions.
On 7/11/07, Benji York <[EMAIL PROTECTED]> wrote:
Hmm, I'd hate for the license file to pollute the root directory of
eve
On 7/11/07, Brian Sutherland <[EMAIL PROTECTED]> wrote:
As long as it's in the tarball, I'm happy (though I suppose the eggs
need it too).
Yep, thanks to the license terms themselves. --sigh--
Any suggestions as to how to get the actual text when building the
tarball?
...
None of them is v
On 7/11/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Right, I made the same assumption: the eggs have been set free,
Right. No need to hold all the developers hostage to a release model
we've been working to get away from.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upo
On 7/18/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
I'm not going to try to convince anyone to give it up, but I probably
won't spend much energy in either promoting, maintaining and
documenting it.
Yay, Philipp!
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which re
On 7/19/07, Adam Groszer <[EMAIL PROTECTED]> wrote:
Just realized that the mechanize and Clientform of the _satellite_ is
pointing as external to the trunk...
That looks not so good, does it?
Not good at all. :-(
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is wri
On 7/19/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Adam's email was a bit misleading, I think. Yes, the externals point
to a trunk, but it's the Zope 3 trunk and they're also using fixed
revisions:
I got the Zope 3 trunk aspect, but didn't check the externals to see
that they used
On 7/19/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Well Adam seems to want to work on this. It's what I suggested he
should do.
Three cheers for Adam!
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
On 8/7/07, Darryl Cousins <[EMAIL PROTECTED]> wrote:
> Perhaps try breaking the string:
>
> var tpl = "<" + "div> js-template <" + "/div>"
>
> Or something like that. Probably zpt doesn't know about tags within
> javascript strings.
ZPT follows the letter of the law quite strictly in this,
On 7/21/07, Adam Groszer <[EMAIL PROTECTED]> wrote:
> Seems like it's ready. Apidoc had to be modified too.
> The egg seems to be built OK. Installs OK with dependecies.
> Tests on the trunk pass when the satellite's branches are linked in as
> externals.
> As I'm not yet a pro regarding eggs, plea
On 8/9/07, Stephan Richter <[EMAIL PROTECTED]> wrote:
> I agree, the site concept is about locality, which is a concept on top of
> zope.component.
Perhaps a reasonable description; I'd describe it more as a tool for
internal organization of an application.
> I think "site" is widely understood t
On 8/12/07, Christian Theune <[EMAIL PROTECTED]> wrote:
> Please. It's badly tested and I assume widely unused. I tried to fix a
> bug that was reported for it and it's just a mess.
+1
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
On 8/16/07, Benji York <[EMAIL PROTECTED]> wrote:
> If buildout prefers "release" eggs, then only bad release eggs will
> cause the above problem. Coupled with nailed versions, there should be
> no reason for emergency communication or egg deletion. Having said
> that, I don't abhor the idea of a
On 8/20/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
> I think we should add a function to validate a given schema on a given
> class. This should include constraints and invariants:
I do presume you mean object, rather than class, as your example implies.
> validateSchema(IMySchema, myobj
On 8/20/07, Benji York <[EMAIL PROTECTED]> wrote:
> I like "getValidationErrors". It's use would probably normally look
> something like this:
...
> Both look good to me.
Ok, agreed, for reasons people have already given.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which realit
On 8/22/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> this was discussed... Last time I remember we were discussing the idea
> of a package a la zope.site or zope.componentsite...
I certainly find zope.componentsite better, because the name actually
explains what it's about.
> (Also,
On 8/24/07, Andreas Jung <[EMAIL PROTECTED]> wrote:
> We should not be too pendantic when it comes to coding styles. I assume
> that most contributors to Zope 3 or Zope components know how to write code
> the Zope 3 way.
As the community grows, this is an increasingly poor assumption.
Different de
On 8/24/07, Stephan Richter <[EMAIL PROTECTED]> wrote:
> That's not harsh. That's the point of a coding style. :-) The long-term
> benefits are greater.
Agreed!
> But if you prefer consistency, then we really should be staying with the Zope
> 3 style guide,
This, of course, all depends on the an
On 8/24/07, Andreas Jung <[EMAIL PROTECTED]> wrote:
> My statement was focused on discussions like camel case vs. underscores.
> Such discussions are basically academic.
Agreed.
> In real life when you develop
> software for different companies or projects it is hard to switch your
> personal cod
On 8/24/07, Stephan Richter <[EMAIL PROTECTED]> wrote:
> He he, except that the ``zc`` namespace started using PEP 8. ;-) I am pretty
> sure the vast majority of code in the repos is classic Zope 3. ``zope``,
> ``z3c`` (for most parts), and ``lovely`` all follow Zope 3.
Even worse, the ``zc`` name
On 8/24/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> it's a matter of taste and that's hard to argue about.
No, that's easy to argue about, it's just not productive. That's the
problem. :-)
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --
There are three branches of zope.file:
branches/0.1
branches/0.2
trunk
There were reasons for so many, but I don't remember what all of them
are; there were at least two aspects to this split.
One aspect that differs is the use of ZODB blobs. I think another is
the location of the result
On 8/29/07, srichter <[EMAIL PROTECTED]> wrote:
>
> ++added:
> - Ensure that the setup.py has a decent set of meta-data, in particular:
>
> * The long_description contains all doctests.
I know Jim's advocated this, at least for all documentation-centric
doctests, but I don't know that we've reac
On 8/29/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> I don't like the overly long PyPI pages, but I do really like having
> easily browsable documentation online. PyPI is the only places where
> that is possible at the moment.
In the absence of something better, yes, it's better than nothing
On 8/30/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
> I suggest making a 2.5 (final) release and being done with it. My
> alpha releases were undoubtedly in ignorance of the existing tag.
Heh. Given that tag was yours, I shouldn't say anything. I certainly
didn't know about it. I don't think the
On 8/31/07, Stephan Richter <[EMAIL PROTECTED]> wrote:
> That's is what I am most worried about. I really need to look into this to see
> how much things changed. Maybe not as much as we tend to think.
I think the changes will be substantial, both for Python code and for
C extensions.
A biggie is
On 9/1/07, Christian Theune <[EMAIL PROTECTED]> wrote:
> I think the byte/text change is excellent.
I like the clean separation of the two. What I don't like is the
omission of an immutable bytes type.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Hen
On 9/4/07, Benji York <[EMAIL PROTECTED]> wrote:
> I suggest we put them in PyPI earlier and use "Development Status :: 2 -
> Pre-Alpha". Of course, we don't want to spam PyPI with /too/ many
> uncooked packages.
It would be good if distutils/setuptools/PyPI set this up based on the
label in the
On 9/6/07, Chris Withers <[EMAIL PROTECTED]> wrote:
> Yup, and this was the reason for my original question to Jim: why do
> something in zc.buildout rather than fixing the problems with setuptools?
It's not at all clear to me that this suggests there's actually a
problem with setuptools. The des
On 9/14/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
> Before I'll revert the layer-support will be there in a third party
> package, probably using ++api++.
Better to be specific than general when it's for a specific type of
request; why not ++xmlrpc++?
Unless ++api++ is for more than XML
On 9/14/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
> So you're suggesting using ++api++ to choose the request type for all
> IHTTPRequests. That's fine for me.
This is good; if we think about the current "skin" namespace as really
being about the *request* rather than the browser presenta
On 9/14/07, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> If you register views for a base request type, you
> probably will open a backdor in other projects. Because
I'm not advocating registering views for the base request types
generally, but only the way to specify in the URL what the request
ty
On 9/24/07, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> One of the issues I see is that we have two kinds of views - the ones
> used to construct the ZMI, and special views, such as AbsoluteURL.
> Simply making it possible to include the component registrations without
> the browser registrations
On 9/26/07, Gary Poster <[EMAIL PROTECTED]> wrote:
> I should make our own private copies of the eggs we use, to
> completely isolate us from these sorts of things, but I have not
> gotten around to it...nor am I thrilled at the prospect of that
> overhead.
This is also a technical issue: As long
On 9/26/07, Marius Gedminas <[EMAIL PROTECTED]> wrote:
> Reducing overhead is why I proposed an automated tool.
Exactly. I like this approach myself.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
__
On 9/26/07, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> What does one need to tell setup.py to make sure CHANGES.txt is
> available? I understand it isn't by default, then? Hm, it does appear to
> be there by default. I checked grok 0.10's tgz and it's there, and we
> didn't do anything special.
On 9/26/07, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> That said, I'd still like the process *without*
> the tool comprehensible by normal human beings.
Agreed; I was trying to usurp the goal of having a reasonable process.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which rea
On 9/27/07, Benji York <[EMAIL PROTECTED]> wrote:
> Second, why would you include all of the zope.* eggs if that particular
> package doesn't depend on them?
I suspect there are hidden differences in expectations here. ;-)
Roger, when you assemble an application, are you expecting to find all
of
On 9/27/07, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> No I excpect some of them, but others excpect others.
> So I'm pretty shure if we count all different setup then
> we can excpect all packages in the summary.
If you think that testing "the whole Zope 3 pile" with the changed egg
is something
On 10/3/07, Lennart Regebro <[EMAIL PROTECTED]> wrote:
> It currently only makes releases as tgz, but adding eggs should be so
> hard (it's done by calling setup.py anyway if I remember correctly).
tgz files are all that's needed (or wanted); there's no reason to use
a .egg file. For packages tha
Meant to send this to the list...
On 9/18/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote:
> The only thing is, no I'm not going to register every file in ZCML. I
> want to use the zc.resourcelibrary.
>
> The follwoing makes it possible, but it's not too nice to have that
> somewhere in the cod
On 10/5/07, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> zope.error is a 3.5 egg, but is needed by 3.4.x releases. I guess this
> also happened because large package refactorings happened and were
> released as 3.4.x releases. It's pretty bizarre to run into, though.
It's only bizarre if the satel
On 10/6/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> Yet zope.app.error was split up into zope.error and zope.app.error
> without releasing a zope.app.error 3.4.0 final first. The split up
> should have been done entirely in the 3.5.x series, *after* producing
> stable 3.4.0 releases.
On 4/21/05, Chris Withers <[EMAIL PROTECTED]> wrote:
> Yes, but there is no setup.py in the app version ;-)
No, but there is install.py, which is the same thing. It is renamed
to avoid confusion about whether the Makefile or setup.py is the
preferred interface for working with the package.
> So,
On 4/22/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> don't think zpkgtools wants to manage dependencies on the whole system,
> yet that's what users need.
Yes. It should be possible for zpkg to assemble the requirements
metadata from components so that it all gets reported to distutils (if
dis
On 4/25/05, Florent Guillaume <[EMAIL PROTECTED]> wrote:
> Hm I'd have said: A 1% increase, never worth the bother, will be drowned
> in other noise anyway.
A consistent 1% increase is something, though, especially if there's
no runtime downside. As Tim Peters regularly points out, lots of
little
On 4/26/05, Nathan R. Yergler <[EMAIL PROTECTED]> wrote:
> So it looks like zope.configuration.xmlconfig.file is responsible for
> reading the ZCML file and parsing the directives. I did find the
> directives in zope.app.component. I guess the outstanding question in
> my mind is what gets called
On 5/9/05, yuppie <[EMAIL PROTECTED]> wrote:
> But I still believe it was wrong to change the 'inet_address' datatype
> in ZConfig.
I spoke with Tim about this briefly today, and I can't remember the
reasons for some of the relevant changes. I suspect at this point
that putting less magic in the
On 5/19/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> As a result, Zope3 trunk can't use ZODB 3.4b1 (I tried -- doesn't
> work) before someone stitches the new ZConfig release into Zope3. I'm
> willing to if nobody else is. Ideal would be someone familar with the
> uses of the ZConfig socket-addres
On 5/20/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> If introducing new types counts as a "bug fix", maybe someone should.
> It fixed a bug in Zope 2.8 on Windows, but my understanding is that
> bug was unique to Zope 2.8, and because of a change made to SVN
> ZConfig last year that wasn't also made
On 5/25/05, Ivo van der Wijk <[EMAIL PROTECTED]> wrote:
> I'm trying something similar right now as well - "sharing" the title
> field between DC and content. Everything works fine, until I try to
> change the title through the Metadata tab:
This is interesting. We're not using the Metadata tab a
On 6/4/05, Sidnei da Silva <[EMAIL PROTECTED]> wrote:
> - Are there examples of using the locking framework?
I've done some work with this, but its not open source. I don't have
a lot of time, but will try to answer questions as much as possible.
The documentation in zope.app.locking is pretty r
On 6/22/05, Stéphane Brunet <[EMAIL PROTECTED]> wrote:
> I finished adding the "ASCIILine" field and the ASCIIAreaWidget to the
> source (see this thread for the details :
Yay!
> My question is : how should I submit a patch for review ? Does a "svn
> diff" will suffice ?
The best thing would be
On 6/23/05, Corey <[EMAIL PROTECTED]> wrote:
> Ok, I just finished setting up my svn+ssh contributor access. The
> https://cvs.zope.org/update.php page suggested that I join the zope-coders
> list - but that appears to be for Zope2, unless I'm mistaken. Is there a
> zope3-coders or somesuch?
There
On 6/30/05, os <[EMAIL PROTECTED]> wrote:
> I try use "zope.testing.formparser", but he not supply several elements
> with identical name:
> ...
>
>
>
> ...
> Questions: How i can check like forms in my functional tests?
> My offer: change self.current[name]=Input ==> self.current[name] =
> [Inp
On 7/5/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> It is not supported. We really need to clean this area up
> a lot. I hope to make some progress on this in Zope 3.2.
> There won't be any backward-compatibility code to support
> unusual usages like yours.
I think we should be able to register t
On 7/7/05, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> I hope that moving it into the zope package doesn't mean it will be only
> maintained for Zope 3.2 (as it requires python 2.4). While I obviously
> don't expect it to be released with Zope 3.1 I hope we can pull a
> release of it that can be i
On 7/8/05, Florent Guillaume <[EMAIL PROTECTED]> wrote:
> I'm having a hard time grasping the reasons why we have both
> ILocation and IContained.
The documentation is slim; I'd certainly appreciate hearing a
definitive clarification from Jim as well.
> class IContained(ILocation):
> """Obje
On 7/9/05, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> No, I don't think so. Or at least if you create a object
> from it's factory e.g. in a addform this isn't true
> till the object get added to the container.
Well, I think we're not supposed to be creating objects that inherit
from Contained; I
On 7/9/05, Roger Ineichen <[EMAIL PROTECTED]> wrote:
> Contained is the mixin class for the __parent__ and __name__
> attributes or not?
>
> And we used it as this. Otherwise you have to implement
> __parent__ and __name__ in your own classes again and again.
>
> See the commet in the class:
> S
On 7/13/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> Ok. But default 'ascii' encoding seems like a bug for me and I want to change
> it to 'utf-8' before the release.
Not using the right encoding for the input would indeed be a bug. Do
you have a reason to think it's handled incorrectly in XM
On 7/13/05, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> Andreas Reuleaux pointed me to the fact that this XML declaration should
> only be used for determining the ZPT input encoding, not the output
> encoding (which is set by negotiating the best available charset and is
> set in the re
On 7/7/05, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> I noticed another possible oddness with zc.page. When I subclass
> form.PageEditForm, I normally get an 'edit' action provided with it, as
> the baseclass defines this.
The base class provides two things:
- the implementation of the edit act
On 7/15/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> - The code for guessing file input encoding in HTML mode based on the
> declaration. I can do it, but should the code be somewhere inside
> PageTemplateFile or inside HTMLTALParser?;
I'd add it to PageTemplateFile.py for Zope 2, and pagetem
On 7/21/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> Log message for revision 37358:
> Now input encoding of a PageTemplateFile in 'html' mode is determined
> by declaration and then the declaration will stripped.
>
> Open question:
> Shouldn't / stripping be in PageTemplate.__cal
On 7/21/05, Garrett Smith <[EMAIL PROTECTED]> wrote:
> I guess my question was whether you see the widget handling the setting of the
> time zone, or the application. My vote would be that the widget deal with
> this,
> using adaptation to black box the process of finding the implicit tzinfo
> (a
On 7/21/05, Garrett Smith <[EMAIL PROTECTED]> wrote:
> I just want to avoid applying special handing for time zones outside the
> widget/schema framework.
Right. One use case if for date/time values that have a tzinfo that's
always UTC, and for which the input is always done in UTC. That seems
l
On 7/23/05, Andreas Reuleaux <[EMAIL PROTECTED]> wrote:
> ul is not allowed within a p tag, not even in HTML 4.01 Transitional
Bingo!
> This is just my advice by looking at this problem from an html perspective
> - there still might be a problems with the zope page template code.
The HTML parser
On 7/26/05, sureshvv <[EMAIL PROTECTED]> wrote:
> Me thinks the error message is pretty broken! Or is that now considered a PT
> feature? ;)
I'll grant that it's less than ideal, but not broken by HTML
standards. The in the original source is closed by an implied
where the starts, so while it'
On 8/2/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> zopetest isn't installed into the instance, so isn't
> rewritten the way instance-specific scripts are.
Yes, it is. This is the script that runs the Zope tests from the
installation without regard to an instance.
-Fred
--
Fred L. Drake, Jr.
On 8/1/05, Stephan Richter <[EMAIL PROTECTED]> wrote:
> I was just putting together the release and noticed a problem. zopetest.py
> does not honor the Python setting I specified during ./configure. It always
> selects /usr/bin/python.
I'm just guessing you mean "zopetest"; I don't know what "zope
On 7/22/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> I think about the following generic algorithm:
>
> 1. Preparation stage. Content type and encoding are determining based on the
> / declarations. In case of the 'text/html' type and a not
> unicoded
> content we decode the content. In case
On 8/7/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> Have you ever written functional tests and been surprised that they
> get security proxies around i18n Messages and MessageIDs in the
> tests, but not in the server? I have. :-)
>
> I'm not sure how often people encounter this, but I think I've
On 8/8/05, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> For compatability reasons, zope.app.security._protections and the
> protect() function inside (though empty) should probably still exist for
> at least another release because people might be using it in their own
> tests (even thoug
On 8/8/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> Right. As I perhaps only hinted in the proposal, it is impossible to
> import _protections from zope.app.security, because of this in the
> __init__:
>
> import _protections
> _protections.protect()
> del _protections
Depends on how you spell t
On 8/8/05, Fred Drake <[EMAIL PROTECTED]> wrote:
> On 8/8/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> > Right. As I perhaps only hinted in the proposal, it is impossible to
> > import _protections from zope.app.security, because of this in the
> > __in
On 8/8/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> lol. eek. yuck. :-)
Yep. Not sure what the best way to avoid this would be, either.
-Fred
--
Fred L. Drake, Jr.
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://
On 8/8/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> I'm assuming you mean in Zope 3, rather than avoiding this
> possibility in Python, which seems like futile road.
Indeed, and in particular, I was referring to the import behavior
itself. Your solution avoids the import quirkiness altogether, so
On 8/8/05, Florent Guillaume <[EMAIL PROTECTED]> wrote:
> Make a fake zope.app.security._protections module in sys.__modules__ ?
I guess that would work. :-(
> (The solution to a yuck *can* be a super-yuck!)
When the prescription is as bad as the disease, we've got problems
better addressed by
On 8/10/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> Ok. Now I think that all this can be done somewhere inside zope.tal. I need to
> write a proposal...
Sounds good.
> Maybe we can use "universal newlines" mode instead?
I think that's the right thing to do.
-Fred
--
Fred L. Drake, Jr.
I've finally made the first release of the "zpkg" packaging tool that
we're using for Zope 3 and ZODB these days.
The release is available from the zpkg pages on Zope.org:
http://www.zope.org/Members/fdrake/zpkgtools/
There is also a new mailing list to go along with it, so people
interested
Gary brought up an issue with the macro extension work that Shane did in the
page templates code for Zope 3.1; the relevant code does not exist in Zope
2.x or 3.0.x. Gary's bug report is issue 440 in the Zope 3 collector:
http://www.zope.org/Collectors/Zope3-dev/440
There appears to be a d
On 8/18/05, Nathan R. Yergler <[EMAIL PROTECTED]> wrote:
> We're using some of the Zope libraries for non-Zope apps, and need to
> include zope.proxy. We're not at the point where we care about
> performance (well, much), so it would make life easier if we had a
> Pure Python version of zope.proxy
On 8/18/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> My use case for macro extension is as follows: a third party provides a
> complex macro I'd like to reuse as a macro, but I want to replace only
> certain slots in my macro. I need my macro to offer all of the slots
> that the base macro offe
On 8/18/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Ok. It takes a while to twist my brain back into a mode that
> understands this stuff. Your solution adds capabilities without taking
> any away. +1.
Cool! Thanks for helping think about this.
> Now that I see this better, I'll retract m
Zope 3.1 will include a new feature in METAL, the Macro Expansion Tag
Attribute Language used in page templates.
The implementation is largely complete, but some issues with it were
uncovered in the past week that have caused some re-evaluation of the
details. At this point, we discovered that su
The METAL 1.1 specification has been updated (though it's still marked
as a draft, pending review), and the implementation has been completed
on the Zope 3 trunk and backported to the Zope 3.1 branch.
This would be a good time to review the specification and ask any
questions that come up. I hope
Yesterday I made a change to the Zope 3 trunk that changes how the
ZCML slugs from the package-includes/ directory are handled.
If you're not accustomed to using "make" to build the software (at
least on non-Windows platforms), you might want to run "make" at least
once.
Here's what changed: The
On 8/26/05, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> I just saw this being changed in the wiki (by Fred Drake):
>
>the new zope.formlib. - -- Reimplement file objects (for
>Zope 2 or Zope 3 to take advantage of the new 'zope.formlib'
I just tweaked the
On 8/29/05, Julien Anguenot <[EMAIL PROTECTED]> wrote:
> http://svn.zope.org/Zope3/trunk/Makefile?rev=37919&r1=37889&r2=37919
>
> The reason is not explained within the logs ??
That particular change was because I'd managed to add the version
number back accidentally; it had previously been remov
On 8/30/05, Gary Poster <[EMAIL PROTECTED]> wrote:
> Adam, I'm sorry, I don't know much about the CustomWidgetFactory. We
> are using the zope.formlib package exclusively now (http://
> svn.zope.org/zope.formlib/), which does not use custom widget
> factories or . Dominik's email sounds promising
On 8/31/05, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> HTML4 mode exists because
...
> - it enforces some HTML document type (as mentioned before); no idea why
> it does that
I'm just guessing you're referring to its understanding of the allowed
nesting structures. This is done so tha
On 9/1/05, Stephan Richter <[EMAIL PROTECTED]> wrote:
> > Do any specifications need changing?
>
> I don't think so. If the directory the code is in has any TXT files you might
> want to read through them making sure that the characters are not mentioned
> anywhere.
These are supposed to look lik
On 9/1/05, Stephan Richter <[EMAIL PROTECTED]> wrote:
> Oh, and by the way, do not add ZCML files manually. Add a SETUP.cfg that adds
> the ZCML file.
More information on how to do this is in the Zope 3 wiki:
http://dev.zope.org/Zope3/BuildAndPackagingInfo
-Fred
--
Fred L. Drake, Jr.
On 9/2/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote:
> There is a problem to build extensions for the Zope3 trunk (and I guess
> for ZODB trunk as well) - all extension module names is lowercased now.
> For example:
This is a symptom of getting the wrong ZConfig version. This setup
requires 2.3.
101 - 200 of 269 matches
Mail list logo
