[aside... hmmm, crossposting, maybe time to merge zope-dev and
zope3-dev? most stuff seems to be relevent to both nowadays]
Jim Fulton wrote:
In Zope 3, we went with a more explicit installation mechanism,
in which people had to explicitly cause a package's ZCML files to be
loaded for it to
Stephan Richter wrote:
This is interesting. I agree with Philipp though that a simple install tool
would be better than one magic location.
Indeed, but don't eggs already provide tools for this?
I think the ZCML slugs are very cool
I think they suck, sorry... it's one of the first things
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
On Wednesday 15 February 2006 07:20, Philipp von Weitershausen wrote:
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
Okay, I hope this would be ignored, but -1. I can still ignore many
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
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
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Among other things, yes. The idea isn't mine though, it was Jim's and is
already in-place as of Zope 3.2/2.9.
Oh, I missed that, I thought it was planned for 3.3. :-)
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
[snip]
Moreover, sometimes a package introduces new ways to configure
components. Five does so, for instance, and Silva will too eventually.
I would really like to hear what kind of directives you imagine for Silva here
(and what you
Philipp von Weitershausen 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,
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
Balazs Ree wrote:
On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote:
Jean-Marc Orliaguet wrote:
I've being working on integrating Balazs Ree's CTAL interpreter recently
(added tests, fixes, etc.). CTAL is the equivalent of TAL but for
javascript.
I just googled around for this, and
Tonico Strasser wrote:
Philipp von Weitershausen wrote:
[snip]
See, now I even explained this to a template programmer, though I
don't think he'd care.
Maybe I mean something different. I just want a folder in which I can
drop all the files I want to customize (I love to customize),
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
[snip]
* a way to register an XSLT renderer.
* registering XML importers and exporters.
These two immediately triggered adapter in my mind :).
XSLT renderer may be a view, that's how we use them now. I think it's a
candidate for a
Chris Withers wrote:
maybe time to merge zope-dev and zope3-dev?
-1
They're still different enough that most traffic on one is not
interesting to the majority of subscribers to the other.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't really
anything. Of course XSLT can be used this way too, but TAL is kinda neat
too. Still, I couldn't think of much practical use for this. Perhaps
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote:
A separate svn project would be nice. I'm sure z3lab is open; it's also
welcome under the z3 base on codespeak.
I will then check it in to one of those; seriously, I can't decide which
location would be more proper as a home. The z3base
Benji York wrote:
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't
really anything. Of course XSLT can be used this way too, but TAL is
kinda neat too. Still, I couldn't think of much practical
Balazs Ree wrote:
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote:
A separate svn project would be nice. I'm sure z3lab is open; it's also
welcome under the z3 base on codespeak.
I will then check it in to one of those; seriously, I can't decide which
location would be more
On Wed, Feb 15, 2006 at 03:39:02PM +0100, Philipp von Weitershausen wrote:
Maybe I mean something different. I just want a folder in which I can
drop all the files I want to customize (I love to customize), without
registering something.
That's not how it works in Zope 3, at least not
Balazs Ree wrote:
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote:
Are you interested in recovering some of there Zope TAL based regex stuff
from Sapling? I'd be happy to merge it in. ctal doesn't appear to have
this yet.
I must have a look, of course any enhancement would be
Jean-Marc Orliaguet wrote:
Balazs Ree wrote:
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote:
Are you interested in recovering some of there Zope TAL based
regex stuff from Sapling? I'd be happy to merge it in. ctal
doesn't appear to have this yet.
I must have a look, of course
Paul Winkler wrote:
I have to explicitly register every one of my skin's 35 resources?
If the 35 resources (files) are in the same directory you can use the
resource directory ZCML directive. Or am I missing something?
--
Benji York
Senior Software Engineer
Zope Corporation
On Wed, Feb 15, 2006 at 12:44:36PM -0500, Benji York wrote:
Paul Winkler wrote:
I have to explicitly register every one of my skin's 35 resources?
If the 35 resources (files) are in the same directory you can use the
resource directory ZCML directive. Or am I missing something?
Only that
Martijn Faassen wrote:
if it doesn't slow things down or add features that are not really
needed, I think it's fine, but maybe an explanation would be good as
to what it does?
It basically does the same thing as ctal does, except less (no
tal:repeat for instance, though I did have a
Hello,
I was thinking a lot about the proposed Zope3 web root, and the
mentioned RDBMS first class citizenship.
I'd like to backup an usecase and propose a somewhat different approach ..
First of all, having the ZODB optional and mountable IMHO is a great
thing, because it is not always
Dario Lopez-Kästen wrote:
Sidnei da Silva said the following on 2006-02-14 12:15:
On Tue, Feb 14, 2006 at 08:17:04AM +0100, Dario Lopez-Kästen wrote:
| Shaun Cutts said the following on 2006-02-14 07:37:
| I have seriously considered trying out Django and similar tools to
see | if they would
On 2/15/06, Max M [EMAIL PROTECTED] wrote:
Remember its the Z Object Publishing Enviroment?
Hear, hear!
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zope3-dev mailing list
On Feb 15, 2006, at 4:21 PM, Lennart Regebro wrote:
On 2/15/06, Max M [EMAIL PROTECTED] wrote:
Remember its the Z Object Publishing Enviroment?
Hear, hear!
+1
(Which, to be clear, does not mean we shouldn't encourage people
making it easier to use SQL in Zope. But our strength and
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
On 2/15/06, Paul Winkler [EMAIL PROTECTED] wrote:
Only that I have the same question Martijn does:
Can I then override one of those resources and keep the other 34?
Perhaps the resourceDirectory directive should just be sugar for a set
of resource directives, one for each file in the directory?
Max M wrote:
The problem is that all the people used to LAMP will come to Zope
and
think Well I will need to think differently here. Thats a bother. I
will use sql for everything like usual. And so we will get a lot of
duplicated efforts and half-baked Zope developers, who will
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] 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
On Feb 15, 2006, at 6:03 AM, Philipp von Weitershausen wrote:
Hi there,
a while back I wrote a proposal on simplifying the skinning system
(http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful
feedback which in turn made me update the proposal. Since then I
haven't
heard much
On 2/15/06, Jeff Shell [EMAIL PROTECTED] 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
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
Max M wrote:
The problem is that all the people used to LAMP will come to Zope and
think Well I will need to think differently here. Thats a bother. I
will use sql for everything like usual. And so we will get a lot of
duplicated efforts and half-baked Zope developers, who will desperately
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
43 matches
Mail list logo