On 3/10/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> For instance, one that looks like this:
>
>
That doesn't look like configuration.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
___
Zo
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. ...
>
> I haven't personally formed an opinion on where this sort of thing
> should go, but copying and pasting 12 li
-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
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. ...
I haven't personally formed an opinion on where this sort of thing
should go, but copying and pasting 12 lines of python code is totall
On Fri, Mar 10, 2006 at 04:19:44PM +0100, Martijn Faassen wrote:
> Hi there,
>
> I notice a pattern in code that uses annotations that looks like this:
>
> class Foo(Persistent, Contained):
> implements(interfaces.IFoo)
>
> def getFoo(context):
> annotations = IAnnotations(context)
>
On 3/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> 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
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
Hi there,
I've just been playing a bit with zc.table. This is very exciting code
that could make a lot of custom code go away. Way cool!
(and zc.resourcelibrary is also nice!). If I knew the individual
developers I could give them my personal thanks. :)
I ran into some issues and I figured I
Martijn Faassen wrote:
The first issue is I think just something that tripped me up and
might be fixed if we put big warning signs in the documentation.
I'll look at making this more noticeable and explaining the reasons.
A second issue seems to me a bug in the javascript. When I use
Standalo
On Friday 10 March 2006 10:19, Martijn Faassen wrote:
> What do people think?
+1 We use this pattern for every annotation in SchoolTool and it gets old
really quick. One argument that could be made is that the code in the
function could be in the constructor. This is bad, because the __init__
m
Hi there,
I notice a pattern in code that uses annotations that looks like this:
class Foo(Persistent, Contained):
implements(interfaces.IFoo)
def getFoo(context):
annotations = IAnnotations(context)
try:
return annotations[FOO_KEY]
except KeyError:
foo = Foo()
On Mar 9, 2006, at 7:20 PM, Philipp von Weitershausen wrote:
http://codespeak.net/svn/user/philikon/rwproperty/
This is nice. I'm going to use it right now. I wish it were
available directly in Zope 3 (or that we were fully eggified).
Gary
___
On 3/9/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
> The disadvantage here, of course, is that the {g,s}etBar methods hang around
> in the class for no reason. Benji's example avoided this.
That's only a disadvantage if you don't want to allow a subclass to
use them; that can be useful at times
Philipp von Weitershausen wrote:
Benji's example is also beyond any magic of most of the people.
I don't know about that.
*Especially* when you're just new to Python.
There I'll agree with you.
http://codespeak.net/svn/user/philikon/rwproperty/.
I like this type of approach better, but
On Friday 10 March 2006 07:22, Florian Lindner wrote:
> Am Freitag, 10. März 2006 12:45 schrieb Stephan Richter:
> > On Friday 10 March 2006 05:55, Florian Lindner wrote:
> > > layer = centershock does not seem to work anymore (for what is name
> > > attribute of the interface directive?).
> > >
>
Am Freitag, 10. März 2006 12:45 schrieb Stephan Richter:
> On Friday 10 March 2006 05:55, Florian Lindner wrote:
> > layer = centershock does not seem to work anymore (for what is name
> > attribute of the interface directive?).
> >
> > layer="CS.skin.interfaces.ICentershockLayer" seems to work but
On Friday 10 March 2006 05:55, Florian Lindner wrote:
> layer = centershock does not seem to work anymore (for what is name
> attribute of the interface directive?).
>
> layer="CS.skin.interfaces.ICentershockLayer" seems to work but do I always
> have to give the lenghty python path??
Yes, this is
Lennart Regebro wrote:
On 3/10/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
When I first saw constructs like this (using @apply), I was immediately
repelled and came up with this:
http://codespeak.net/svn/user/philikon/rwproperty/.
Yeah, that´s much better and is how I would have
Hello,
I have:
class ICentershockSkin(zope.app.rotterdam.Rotterdam):
What do I have to give for the layer or type (what is the difference?)
attributes of view / pages / ... directives?
layer = centershock does not seem to work anymore (for what is name attribute
of the interface direc
19 matches
Mail list logo
