On Tue, 14 Feb 2006 14:08:07 -, Stephan Richter
<[EMAIL PROTECTED]> wrote:
On Tuesday 14 February 2006 08:41, Philipp von Weitershausen 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 per
On Tue, 14 Feb 2006 13:48:42 -, Florent Guillaume <[EMAIL PROTECTED]> wrote:
For example CPS currently has a cps:upgradeStep directive:
Interesting... we've been talking about doing something similar in Plone.
Martin
--
(muted)
___
Zope3-de
Hi Philipp, hi Florent
[...]
> I'm all for reducing the number of namespaces in the standard
> directives,
> and reducing the number of directives too, but getting rid of
> namespaces, as
> others have pointed out, removes clean ways of extending ZCML for
> third-party frameworks.
[...]
> M
[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 be
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 I
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 a
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 comments. I would like to start implementing it soon,
especially sinc
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 ha
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 ma
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 comments. I would like to start im
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
>
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 possib
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 simpli
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 component=".alias.sydneyFactory" /> which is then the on/off switch we
> mentioned earlier. And an adapter should be registered the same way
> a
Tres Seaver wrote:
>>>- Many of the objected-to directives exist precisely because people
>>>did not want to type the much more verbose equivalents which were
>>>the original, "cleaner" spellings.
>>
>>Or perhaps people just thought that people wouldn't want to type in some
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 t
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 Conte
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 me
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, y
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
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
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
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), witho
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 in
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 use
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 p
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
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 grea
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 a
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
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 simple
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 neede
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 f
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
Zope3-dev
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
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 directo
Swiss Easter Sprint
"Sorry for cross posting, I just will make sure that
nobody feels like not invited and has a chance to
participate."
When
The sprint starts on Saturday, April 8, at 9:00am and will end
on Wednesday, April 12 in the afternoon. The official welcome
activity will be at noon
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
t
> 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
[Sidnei da Silva]
...
>> Now whether that's that's the correct interpretation is up to the
>> original author (Tim Peters?) to clarify :)
[Fred Drake]
> I don't know if he's paying attention to this thread, but I'm fairly
> certain everyone at PythonLabs understood that to refer to namespaces.
>
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
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Chris Withers wrote:
> > I'd flip that, because I think you and Steve A would agree on one thing:
> > The use of an object database _should_ be a choice, not a requirement,
> > but it should also be the default ;-)
>
> Actually, I disagree--I
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
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. imag
On 2/15/06, Fred Drake <[EMAIL PROTECTED]> wrote:
> 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 s
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 desperatel
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
Jeff Shell wrote:
Personally, I think that the ZODB is a terrific asset that has
achieved a greater level of usability in Zope 3. At least, it has for
us, now that we're no longer confused about whether the ZODB should
house our persistent objects, or if it should house our icons and
scripts and
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> Wade Leftwich wrote:
> > +1 from the standpoint of promoting corporate adoption, especially when
> > combined with first-class citizenship for RDBMS. (In the corporation I
> > work for, anyway.)
>
> Yes, RDBMS would become a first-class citize
Martijn Faassen said the following on 2006-02-15 18:27:
Aah, now I understand where the 'c' comes from. What about 'btal',
browser tal?
ctal. Client TAL; I see no reason to restrict this to browsers. This has
neat and exiting implications for non-browser clients that understand
java-script
Philipp von Weitershausen wrote:
directives. I realize "somewhat" is fuzzy. Let me just say that I think ZCML
has failed when Plone will have its own ZCML directives...
There's a mailing list post from ages ago about going off and humping
the leg of the next great thing. Plohn _will_ grow its
Martin Aspeli wrote:
I think that's certainly true for content-centric applications, which is
what people seem to build the most of in Zope. But if you were storing
80 million records of numbers and short strings that you needed to query
across multiple dimensions, you'd probably put them in po
Stephan Richter wrote:
That said, there might still be a small percentage of cases where custom
directives are a valid tool. I can accept their being on the same namespace
as others. In fact, I would like it to be that way, reducing the amount of
dead chickens (namespace declarations).
I do not
60 matches
Mail list logo
