Philipp von Weitershausen wrote:
browser:view
Like zope:view, except:
* the request type (second adapted object) defaults to
IBrowserDefaultLayer
* the permission always applies to 'publishTraverse',
'browserDefault' and '__call__' attributes, in addition to the
Paul Carduner wrote:
I am having trouble debugging viewlets that redirect to Unauthorized
pages. Here is the synopsis. We have a dashboard page with a bunch
of viewlets displaying information about all different parts of the
system. When one viewlet tries to access forbidden attributes, the
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
browser:view
Like zope:view, except:
* the request type (second adapted object) defaults to
IBrowserDefaultLayer
* the permission always applies to 'publishTraverse
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
However, I'm wondering what browser:page does to make something
publishable, that browser:view doesn't do.
It creates a new class with an extra mix-in class that has a
browserDefault method which in turn points to the template, method
Christian Theune wrote:
Shane Hathaway wrote:
I'm working on enhancing zope.app.apidoc, but I ran into an exception
that's hard to decipher. I've attached the traceback. I don't know
which __init__() it's complaining about, and I don't know how to find
out. What can I do to find out which
Chris Withers wrote:
Jim Fulton wrote:
adapter
for=.myclasses.MyClass
provides=.interfaces.ISomething
factory=.adapters.MyAdapter
/
I think it is a fine idea. That's why it has been supported for
a long time. You can register adapters and views (which, of course
are
Christian Theune wrote:
Shane Hathaway wrote:
Unfortunately, the adapter hook is in C. It would be great if I could
switch it to Python. Is that possible?
I remember being able to step into it. pdb then put me into the next
Python-level within there ...
Probably you can delete some
Martin Aspeli wrote:
OT: Thunderbird makes a real mess of interpreter examples, thinking the
'' is an indent and making it a coloured line. Anyone got an idea how I
stop it from doing that?
If you find out, PLEASE tell me too. :-)
Shane
___
Christian Theune wrote:
Shane Hathaway wrote:
Martin Aspeli wrote:
OT: Thunderbird makes a real mess of interpreter examples, thinking the
'' is an indent and making it a coloured line. Anyone got an idea how I
stop it from doing that?
If you find out, PLEASE tell me too. :-)
I think
I'm working on enhancing zope.app.apidoc, but I ran into an exception
that's hard to decipher. I've attached the traceback. I don't know
which __init__() it's complaining about, and I don't know how to find
out. What can I do to find out which __init__() the adapter hook is
trying to call?
Jim Fulton wrote:
I also think there is a real opportunity in allowing reload to fail.
That is, it should be possible for reload to visibly fail so the user
knows that they have to restart. Then we only reload when we *know*
we can make changes safely and fail otherwise. For example, in the
Adam Groszer wrote:
What about pushing the problem then to the lower level, to Python
itself. I think all developers are fighting the same problem, so all
Python developers would benefit from the solution. As I know (that may
be wrong) not many even if any language supports that, so that would
Jim Fulton wrote:
I'd have no problem with generating actions in Python. It would allow
greater control and would probably make action generation much faster.
If we did this, We'd probably want to improve the action-generation
API. We'd also need to think about how action info should be
Jim Fulton wrote:
Martijn Faassen wrote:
...
I suspect we're in a state of violent agreement here. :)
Then why do people have to argue every single point ad nauseum?
Because we want to understand the current decisions and thinking. I
never intend to argue, but email is such a poor
Jim Fulton wrote:
Finally, I'll note that I've used the term high-level configuration to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system) should be used for this.
Ok. The
Jim Fulton wrote:
Shane Hathaway wrote:
Jim Fulton wrote:
Finally, I'll note that I've used the term high-level configuration to
refer to the things we have sysadmins edit when they install Zope
systems. We currently use ZConfig for this. I don't think ZCML
(or any other XML-based system
Dieter Maurer wrote:
Jim Fulton wrote at 2006-3-14 07:23 -0500:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of explicit is better than implicit.)
I do not agree with this (but I also do not agree with
explicit is better tham implicit --
Jim Fulton wrote:
Shane Hathaway wrote:
+1. When I learn a skill, it is at first completely explicit, and as
the skill becomes predictable and reliable, it gradually becomes
implicit. If I kept everything explicit, I would hinder myself from
building higher level skills.
So explicit
Martijn Faassen wrote:
A newer interpretation of ZCML is:
ZCML is a configuration language that configures a number of basic
directives for configuring the component architecture and security:
adapters, utilities, security requirements, and little else. Everything
else should be done in
Sidnei da Silva wrote:
On Mon, Mar 13, 2006 at 02:16:17PM -0700, Jeff Shell wrote:
| And I think it's
| very important for the Python code to say what it does, so when I come
| back to a module five months later I'm not staring at MyFactory going
| yeah, but what is it?
One thing that must not
Martijn Faassen wrote:
If I'm doing this quite a bit, this looks like something that would be
better expressed in a... new ZCML directive (..waiting for the crowd to
start flinging stones).
A possibly valid direction we haven't discussed yet is to embrace ZCML's
flexibility and make new high
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Shell wrote:
On 3/10/06, Shane Hathaway [EMAIL PROTECTED] wrote:
A possibly valid direction we haven't discussed yet is to embrace ZCML's
flexibility and make new high level directives often. For instance,
every time I feel like I'm
Rocky Burt wrote:
On Fri, 2006-10-03 at 17:17 -0700, Jeff Shell wrote:
But I beg you not to add to the ZCML pile because you had to copy and
paste 12 lines of Python code. snip...
I haven't personally formed an opinion on where this sort of thing
should go, but copying and pasting 12 lines
Chris McDonough wrote:
My $.02: I suspect it might be better to just use XML than configparser
as a ZConfig replacement. The config format is a stretch under CP due
to the lack of hierarchy. I'm beginning to think the don't make admins
use XML argument should die. Everybody knows how to
Stephan Richter wrote:
I usually do not send messages like that, but in light of the recent
discussions about vision, viewing this will give us all some perspective on
what people are looking for:
http://theploneblog.org/archive/2006/03/02/faster-better-cheaper
I think currently Zope 3 would
Stephan Richter wrote:
On Tuesday 07 March 2006 13:27, Shane Hathaway wrote:
Part of the problem is that Zope 3 makes too great a distinction between
developers and scripters. Successful scripters become developers, and
developers often act as scripters. I think the use cases need to see
Stephan Richter wrote:
On Tuesday 07 March 2006 13:43, Shane Hathaway wrote:
My vision for the WebDev project is that you can develop WebDev packages
using Zope 2 like features, but the result of the Web development can be
generated into a real Python package.
That might work, but the story
Paul Everitt wrote:
I still don't think scripters and developers are the same people. I
won't repeat Dan's arguments here, but I think his essay is a valuable
read for understanding an audience that isn't like most zope3-dev people.
Once again this comes down to differing visions. Is Zope
Jeff Shell wrote:
- Zope 3 CA: The Zope Component Architecture. Core services. Would
include zope.publisher and most other current top level zope.* things.
Usable as a library, as a publisher for other environments, perhaps as a
simple standalone server. Easy to deploy against WSGI,
Chris McDonough wrote:
[...] the process of identifying
dependencies and eliminating the silly ones is the valuable work here,
and it seems to be getting done by embracing egg packaging, which is
really wonderful.
Such a gushing endorsement! Now I feel guilty for not having tried eggs
Jeff Shell wrote:
Perhaps it's not the greatest name, but I've become enamored with *lib
names like 'formlib'.
'zopelib'
Hmmm. Not the prettiest thing. But it does say Zope Library. If that
becomes the *core* of the mythical Zope 5, awesome.
This sounds familiar. :-)
Jim Fulton wrote:
I think that such a tool would be useful. I see no benefit in trying to
provide a through-the-web view. (Actually, I see a little benefit and
lots of downside.) I recommend a simple command line tool instead that
writes to standard output.
What would be the downsides of a
Gary Poster wrote:
On Feb 18, 2006, at 3:08 AM, Shane Hathaway wrote:
In my last project, reusing the ZMI seemed like a good idea. Maybe
that was a bad choice. Do you start with an empty site.zcml? I
haven't dared yet. :-)
We started mostly from scratch, with various successes
Jeff Shell wrote:
I guess I still don't understand how you're using Zope 3, because it
sounds like you're using it very differently than I am. I've long
since abandoned the ZMI. I never see that list of addable objects (in
fact, in my newest applications, I completely bypass IAdding). I
Wade Leftwich wrote:
Shane Hathaway wrote:
[snip]
Yes, that's a valid point. I also stopped myself from listing folders,
since a folder is a general organizational tool. Let's just talk about
templates and scripts.
[snip]
I think I've got a decent use case for templates in the ZODB
Martin Aspeli wrote:
On Thu, 16 Feb 2006 06:35:00 -, Shane Hathaway
[EMAIL PROTECTED] wrote:
No, we're still confused. Templates and scripts are code. Should
they be in ZODB? Grrr, I hope not. I don't want to suffer that
pain, fssync or no fssync. I invented the CMF skins tool
Stephan Richter wrote:
On Friday 17 February 2006 18:45, Shane Hathaway wrote:
User interfaces speak louder than books. Start up Zope 3, log in as a
manager, and look at the list of things you can add. It includes DTML
Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest
Stephan Richter wrote:
On Friday 17 February 2006 19:03, Shane Hathaway wrote:
There is the WebDev effort that demonstrates some TTW development
features that are actually applicable to Zope 3. Since WebDev
concentrates on doing components, the results can later be easily
exported
Gary Poster wrote:
To each his own, I suppose, but I'm surprised you included File in the
rant-list. Lots of non-web-design uses want that. We've had our
problems with big blobs, but they should be addressed, and in the core,
and files should be probably included either in the core or as
Jeff Shell wrote:
I agree that better integration with external data should be a
priority for Zope. But what does that mean? In theory, if something's
a Python object it should work with Zope 3 with relative ease... If
that's not the case, perhaps we need to look at how much work is
required to
Jeff Shell wrote:
I thought this uniformity of a development model was the Zope 3
message. Am I wrong?
Yes, you're wrong. To create the home page, web developers are directed
to put a page template in ZODB. This is completely different from what
you do. What should they do instead? I
Here's another idea that occurred to me recently. I suspect this one
needs no vote, but perhaps it should be done sooner than other ideas
like the filesystem-based web root.
I want a way to inspect all of the indirections chosen in the course of
a web request or any other publishing
Stephan Richter wrote:
On Monday 13 February 2006 12:18, Shane Hathaway wrote:
Thoughts? Will it work? Should it be a priority?
I like the idea a lot and you could reuse quiet a bit of apidoc code to
produce some nice output.
But my main question is: How will you be able to do
Martin Aspeli wrote:
Now I'm
told that the ZODB is the de-facto way of storing content. Maybe soon
the default may be a filesystem. Mmm...
Whatever we do with the filesystem, it's not going to be as ambitious as
Ape. Ape makes the filesystem appear as an object database, but that
turns
Gary Poster wrote:
On Feb 11, 2006, at 11:48 PM, Philipp von Weitershausen wrote:
[...]
Indeed. Plus, I strongly feel that pushing Zope 3 more than Zope 2 or
viceversa isn't helping. We need to push Zope-the-technology and
Zope-the-community. Branding Zope 3 and making it look like something
Sidnei da Silva wrote:
To serve content from the filesystem we use a custom Publication
object that returns a different root 'application' object and from
there we use custom IBrowserPublisher and ITraversable adapters that
lookup files on the filesystem and construct simple stub objects to
Stephan Richter wrote:
On Thursday 09 February 2006 13:40, Shane Hathaway wrote:
Any thoughts or gut reactions?
Gut reaction: Very cool.
As long as we can easily also have the traditional way I would love to see a
prototype in a branch.
Cool! I'll start thinking deeper about
Martin Aspeli wrote:
On Thu, 09 Feb 2006 18:40:51 -, Shane Hathaway
[EMAIL PROTECTED] wrote:
An idea just occurred to me. I think others have probably had
similar ideas, but didn't express it in the right place or time.
Part 1: Let's put an Apache-like web root
Part 2: Let's add
An idea just occurred to me. I think others have probably had similar
ideas, but didn't express it in the right place or time.
Part 1: Let's put an Apache-like web root (similar to
/var/www/localhost/htdocs/) in Zope instance homes. It might be called
browser or www. Zope will serve pages
Roger Ineichen wrote:
That's a very interesting idea.
Do you mean something like this:
instance
|
-- var/poll.fs
|
-- wwwroot
|
-- index.html (file system)
|
-- pollApplication.zodb (zope)
| (file with info that point/maps to
Gary Poster wrote:
On Feb 9, 2006, at 9:25 PM, Shane Hathaway wrote:
Roger Ineichen wrote:
That's a very interesting idea.
It is a very neat idea. You asked for gut reactions, and I must admit
that I regard the ZODB as more attractive and more central to the Zope
story than some, so
Amos Latteier wrote:
* I agree with Roger this might make sense for small projects. However,
for the small projects that I work on I more often need dynamic but not
persistent stuff, rather than static file serving. So this proposal
would appeal more to me if one could mount non-persistent
Alexander Limi wrote:
On Tue, 07 Feb 2006 22:11:31 -0800, kit BLAKE [EMAIL PROTECTED] wrote:
(Are you going French style with your last name in all caps, Kit? :)
2006/2/8, Martin Aspeli [EMAIL PROTECTED]:
Zope^3 :)
That's brilliant. It works in ASCII, or in normal text in a paragraph
of
Paul Winkler wrote:
On Wed, Feb 08, 2006 at 11:08:57AM -0500, Stephan Richter wrote:
Decimal is a new type and we have not yet declared it to be a rock.
What is a rock?
A rock is an immutable object with no insecure methods. Trusted code
can pass a bare rock to untrusted code with no
Alexander Limi wrote:
The original discussion never suggested code names for releases, but a
brand name to help Zope 3 separate itself from Zope 2 - since it is a
*completely* different beast.
Random thought... hehe... Zope Cubed. It's only a typographical change
from Zope 3. The tagline
Stephan Richter wrote:
On Friday 03 February 2006 12:14, Shane Hathaway wrote:
Andreas Zeidler wrote:
On Fri, Feb 03 17:24, Encolpe Degoute [EMAIL PROTECTED]
wrote:
Zope 3 / Revolution ?
well, how about Zope3, Reloaded for all the matrix fans out there? :)
The idea of release code
Gary Poster wrote:
Me too. Maybe even a +(0x1). Zope 3: Revolution, Zope 3:
Renaissance, and Zope 3: Rebirth were my favorites of the bunch. :-)
Well, a new name for Zope 3 sounded like such a bad idea that it didn't
even occur to me that someone would suggest it. We'd have to live with
Christian Theune wrote:
Hi,
somehow there is a mixup between using __traceback_supplement__ and
__traceback_info__.
In Zope 2, I'm used to use __traceback_info__. In Zope 3 it seems like
the exception formatters use __traceback_supplement__. However, quite
some code in Zope 3.2 uses
Shaun Cutts wrote:
It would seem that the current default mechanism is poorly suited to
providing default values for non-immutables. For example:
Mutable is a better way to say non-immutable. :-)
class IBar( Interface ):
a = Object( schema = IFoo, default = Foo() )
But if a “Foo” is
Christian Lück wrote:
From a lerners point of view (for example me) the thematic organization
is a pro too: The z3 beginner will probably need the 'zope' and
'browser' namespaces at first. Browsing apidoc zcml namespaces lets your
knowledge grow fast, because you get structured information.
Martin Aspeli wrote:
I'd be in favour of switching zope.conf to an XML-based format as well,
personally.
That would be a separate proposal. It's not within the bounds of the
proposal under discussion.
Shane
___
Zope3-dev mailing list
Chris Withers wrote:
You didn't read what I said... I assert that anyone who binds the
http://namespaces.zope.org/zope to anything other than the default
namespace, or http://namespaces.zope.org/browser to anything other than
browser: will be causing confusion for themselves an anyone else who
Chris Withers wrote:
FWIW, I still hate ZCML for the following reasons:
Everyone seems to agree on the direction suggested here:
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less
I think that will resolve a lot of concerns.
There's only one thing
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. Converting XML
After I checked in code into the Zope 3 repository this week, I never
saw corresponding notifications posted to the zope3-checkins mailing
list. I don't think I saw notifications for my checkins during 2005,
either.
Note that notifications have a from header matching the email address
of
Gary Poster wrote:
Risks:
Requires more developer work to support browsers that don't support
redirects.
Are you aware of any browsers that don't support redirects? Even Lynx
and wget support redirection.
Shane
___
Zope3-dev mailing list
Jim Fulton wrote:
I could certainly find evidence that you tried, but the implementation was
actually buffering data in a string buffer until the request was finished.
This was the case at least as early as spring of 2004.
Even with more than 105 bytes output over a slow connection?
Jim Fulton wrote:
Shane Hathaway wrote:
A pull strategy will be efficient for a lot more people.
I don't know what you mean by this.
I mean that the new strategy of sending open files to the publisher,
which I call a pull strategy, will work better than pushing to temporary
files. Which
Philipp von Weitershausen wrote:
page 204, Example 12.24, line 17: Using the ``write()`` method of
HTTP-based responses does not provide a performance advantage in
Zope X3 3.0 and 3.1 and is not supported anymore in Zope 3.2 and
higher.
I would like to point out that response.write()
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
So I fully agree that the original write() should go (in fact I suppose
it's gone already), but to say there was no performance advantage is
imprecise. I spent a fair amount of time making write() fast, with some
success.
Interesting
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
So using write() once doesn't at all seem like an advantage over simply
returning the data...
The interesting part is behind the scenes. If the response is large
enough (it's an adjustable threshold), the response transparently gets
Tom von Schwerdtner wrote:
It might be worth considering that the term user has a mostly
negative connotation in English (at least in the USA).
In tech circles, user is completely neutral and safe. However, in
slang, sometimes drug user is shortened to user.
Shane
Steve Alexander wrote:
In Launchpad, request.principal is not used by the application
programmers. It is used only by the authentication, authorization and
publication machinery. The machinery looks up a Person (an application
domain object) for the current principal (the participant, if you
Philipp von Weitershausen wrote:
(Note that the point of finding translations for technical terms is not
only for the sake of a translated Zope 3 UI. It's more about how people
understand technical terms. I think most Zope 3 developers aren't native
English speakers and they do not necessarily
Gary Poster wrote:
On Aug 23, 2005, at 1:11 PM, Gary Poster wrote:
FWIW, my concluding sentence would have been better written as
Meanwhile, deciding that a community project require an O/R back end
over FileStorage or DirectoryStorage, as Florent argues, feels like a
significant case of
Fred Drake wrote:
I'll do that. In particular, I propose:
1. The macro extension feature be associated with a new METAL
attribute, extend-macro. This must be used only in conjunction with
define-macro.
2. The define-macro/use-macro combination will become disallowed once more.
3. The METAL
Shane Hathaway wrote:
However, the place where it's possible to properly install
exceptionformatter as the traceback generator is inside ZConfig.
AFAICT, ZConfig tries hard to not import anything from the zope
package. So I don't know how to get my code installed without poking
a hole
Shane Hathaway wrote:
I'd like to change Zope 3 to log exceptions using
zope.exceptions.exceptionformatter. Zope's exceptionformatter formats
tracebacks with information from __traceback_info__ and
__traceback_supplement__ variables, which is very useful for debugging
problems with page
For a Zope 3 project I'm working on, I'd like the root of the site to be
stateless. In other words, I don't want the root of my application to
be stored in ZODB; I want it to come from either the filesystem or
Python code. In fact, at the moment, I'd prefer not to open a ZODB
connection at all.
Stephan Richter wrote:
On Friday 15 July 2005 13:16, Shane Hathaway wrote:
For a Zope 3 project I'm working on, I'd like the root of the site to be
stateless. In other words, I don't want the root of my application to
be stored in ZODB; I want it to come from either the filesystem or
Python
Ivo van der Wijk wrote:
I currently don't feel experienced enough to fix anything about this
(but pointers are welcome). Does anyone have suggestions/proposals how
developer friendlyness might be improved?
I think the main difficulty is configuration. Actually, the word
configuration makes it
Ivo van der Wijk wrote:
Still, this doesn't solve the masking of errors/tracebacks by
PageTemplates/ZCML -- I'd really like to see a fix for this.
Rally behind PEP 344, because I think it will lead to a good solution to
this problem. If I understand PEP 344 correctly, in the PageTemplate
code
Dominik Huber wrote:
We should have an application/framework-level hook within the site.zcml
that is processed before *-configure.zcml are invoked.
Problem: A framework package 'b.x' registers a dedicated menu 'b_views'.
A package 'a.x' using 'b.x' should be able to register menu items
Jim Fulton wrote:
Shane Hathaway wrote:
I'm sure Fred is doing excellent work, but I'm having trouble seeing why
we need zpkgtools. Is it not sufficient to just python setup.py
install all of Zope 3?
I hope so. What zpkgtools does is to:
- Build our setup.py script (which we name
84 matches
Mail list logo
