Michel Pelletier wrote:
Message: 7
Date: Wed, 04 May 2005 08:17:09 +0200
From: Achim Domma (Procoders) [EMAIL PROTECTED]
Subject: [Zope3-dev] relational data
To: zope3-dev@zope.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I'm evaluating ZOPE
Hi!
I want to get the location about created object through event
notifications, but there is never enough context (there is Not enough
context to determine location root, ...)
subscriber
handler=.objectevents.objectCreated
for=zope.app.event.interfaces.IObjectCreatedEvent
Stephan Richter wrote:
On Friday 20 May 2005 06:15, Jean-Marc Orliaguet wrote:
I want to get the location about created object through event
notifications, but there is never enough context (there is Not enough
context to determine location root, ...)
At the time an object is created
Derrick Hudson wrote:
On Fri, Aug 12, 2005 at 03:07:33PM +0200, Jean-Marc Orliaguet wrote:
| What I don't like about annotations is that the information is stored on
| the object itself.
FYI the annotations framework can be used while storing the annotation
elsewhere. For example
http
Michel Pelletier wrote:
On Wed, 2005-08-24 at 15:28 -0400, [EMAIL PROTECTED] wrote:
Message: 5
Date: Wed, 24 Aug 2005 20:24:30 +0200
From: Jean-Marc Orliaguet [EMAIL PROTECTED]
Subject: [Zope3-dev] [DRAFT] local portlets and perspectives
It is built on the notion of Perspective
Olivier Grisel wrote:
Jean-Marc Orliaguet wrote:
(SellerURI, merchandiseURI, BuyerURI, Sale Transaction)
Let's rewrite this relation to a prolog equivalent fact:
transaction(SellerURI, merchandiseURI, BuyerURI, Sale Transaction).
There is no primary key in that relation. We could add one
Jean-Marc Orliaguet wrote:
a page has a template like a Zope Page Template, that would correspond
to the idea of layout.
it's as unfortunate as a name as the browser:page / directive that is
associated to a browser view, and a page template. But the idea is the same.
it is more like a browser
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
a page has a template like a Zope Page Template, that would correspond
to the idea of layout.
Sure, but It still seems that a theme page fills the same role as a
template, in that it is meant to be used for many different page.
Let me put
Jim Fulton wrote:
it would not be concerned with index.html / report.html / edit.html
AT ALL.
you would just place a Main Content Portlet in the middle of the page
and let the application underneath take care of rendering the poll
screens.
cf
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
yes, these would be application-specific portlets, as the ones used in a
calendar application for instance showing a monthly agenda. The portlet
gets access to the current view object, to the current page location
(renamed from 'context_obj
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
in that case, using a portlet to display the poll results might not be
the best solution,
Right, but then what if, when displaying the poll results, I wanted to
use some
other portlet. Perhaps I have a portlet that lists the top 10 polls
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
in that case, using a portlet to display the poll results might not be
the best solution,
Right, but then what if, when displaying the poll results, I wanted to
use some
other portlet
Hi!
I've updated the relation store's index in cpsskins to support wildcards
on triadic relations.
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_27_triadic-relations
It gives extremely good scalability from 1 to 10+ users (the script
used to measure query times
Jean-Marc Orliaguet wrote:
Hi!
I've updated the relation store's index in cpsskins to support wildcards
on triadic relations.
for count in range(precision * 1000):
a = storage.search(predicate=predicate, second=portlet)
actually it should read:
storage.search(predicate
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
What problem perspectives solves?
--
I think I'm ready to respond to this now. I hope, with your current
thinking that this is still relevent.
good :-)
local portlets are currently
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
By using perspectives end-users can also use the portlet editor to
move portlets on the canvas (as in the google news portal),
By end-users, do you mean content managers? Or end-users of the
content?
Why do they need perspectives to do
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
This is what I meant with having a unifying concept. And that sounds
very unifying to me already.
Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Yes, I think that Rob mentionned that there was such a use case where
you had customers who wanted to control the way portlets were disposed
on the screen on an individual basis.
This gets to a terminology problem. JSR 168 defines portlets
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Hi!
Somehow related to the discussion on optimizing catalog queries, I have
been thinking about how to best implement local portlets in cpsskins in
terms of scalability, performance and functionality. The implementation
is heavily dependent
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
...
- They introduce a need for some complex infrastructure.
what do you mean by complex? have you seen the prototype? for a user
it does not seem too complex:
- choose a perspective
- add portlets to it
- assign
Tonico Strasser wrote:
Hi!
Jean-Marc Orliaguet schrieb:
Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be pipe-able
through the rendering engine, i.e. they must return some data, the more
ready HTML the data
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
basically if the slot that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.
Cool. So we can define new slot-like things (for example,
for JSR 168-style
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
- this portlet uses this widget
I'm confused. In the doctest you pointed out:
https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt
the portlet and widget are wired up
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
Also this is as bad as storing browser view related attributes in a
content class - otherwise we are back to the Zope2 old days, where every
possible attribute was stored on the objects themselves.
There are advantages in storing data
Hi!
I have summarize how the rendering engine in cpsskins in built, from
content, display and format elements to filters, rendering engines:
http://www.z3lab.org/sections/documentation/cpsskins-rendering
with lots of diagrams and explanations. This part of the architecture
has stabilized.
/JM
Hi Paul!
I just read:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SiteThemes
I think that you mentionned it in a previous mail on z3lab and now I
think that I understand what you meant, my impression is that cpsskins
can be used to generate the themes that you are
Stephan Richter wrote:
On Friday 02 September 2005 04:20, Jean-Marc Orliaguet wrote:
this only solution I found was to write:
tal:define=getDisplay nocall:context/displayable/getDisplay;
display python: getDisplay(param);
But it means that I have to adapt the same object
Stephan Richter wrote:
On Sunday 11 September 2005 11:32, Jean-Marc Orliaguet wrote:
it there any technical reason why:
tal:define=displayable nocall:context/displayable
could not return the adapted object based on the context instead of
triggering a traversal error?
Yes. You
Hi!
is the order of the list of interfaces implemented by an object subject
to internal changes?
I have identified the need for such a pattern:
iface = object.interface()
with:
class someObject(object):
implements(IMainInterface, ISecondaryInterface, ...)
def interface():
Janko Hauser wrote:
Am 13.09.2005 um 12:43 schrieb Jean-Marc Orliaguet:
But where do you put the 'directlyProvides' statement? in the class :
Can't this be put in the interface definition module for
IContentType? You mark other interfaces with the interface IContentType.
__Janko
I
Philipp von Weitershausen wrote:
Florent Guillaume wrote:
Philipp von Weitershausen wrote:
from zope.app.content.interfaces import IContentType
from zope.app.file.interfaces import IFile
from zope.interface import directlyProvides
directlyProvides(IFile, IContentType)
FYI, there is a typo in:
Index: zope/app/i18n/browser/synchronize.py
===
--- zope/app/i18n/browser/synchronize.py(revision 38532)
+++ zope/app/i18n/browser/synchronize.py(working copy)
@@ -117,7 +117,7 @@
if
Hi! I'm having trouble getting strings to be translated using
tal:content=variable or tal:replace=variable
p i18n:translate= i18n:domain=zopeEverybody/p
yield (in French):
pTous/p
but:
p i18n:translate= i18n:domain=zope tal:content=string:Everybody /
gives:
pEverybody/p
which
Roger Ineichen wrote:
Hi together
I added a proposal where is important for the CPSSkin work and the
zope.app.viewlet implementation.
Can you take a look at it and tell me what do you think about.
I hope it will be possible to implement a generic lookup concept
in page templates where we can
Roger Ineichen wrote:
Hi Jean Marc
...
Hi Roger,
I propose,
Regions and their lookup are a concept on the ZPT level,
implementations like CPSSkin or viewlets use this ZPT API
Let's say a region defines a area in a page template. This area
will lookup 'html fragment' and render them
Hi!
I've encountered a problem when trying to render views (there is no
problem with rendering pages), but for instance with the '+' view that
is defined in app/container/browser/configure.zcml
view
for=zope.app.container.interfaces.IContentContainer
name=+
menu=zmi_actions
Hi!
the '+' view now works fine in cpsskins :-), the only problem is that it
also reveals a user interface issue nicely hidden in the original
Rotterdam skin :-) namely that the menu actions are still visible when
the url ends with .../@@+ and the action item urls are not normalized. A
second
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
With the '+' view described above, there is a default page
attribute to
use for displaying the view ('index.html') and but no page attribute
explicitly assigned.
The following patch fixes
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Hi!
the problem is not in the skin itself, but in the model used to create
skins. Filesystem-based skins that depend on ZPT macros are doomed by
definition, unless they are designed to cover most of the site layouts
you'll find on the internet
Jim Fulton wrote:
Paul Winkler wrote:
Hi Jim, just de-lurking for a moment:
On 10/24/05, Jim Fulton [EMAIL PROTECTED] wrote:
I think the biggest problem with the ZPT macro approach to look
and feel
concerns are not separated. CPSSkins deals with this in it's own way.
I couldn't
Dmitry Vasiliev wrote:
Jim Fulton wrote:
IMO, if a template an element with both i18n:translate and tal:content
and the value inserted is not a message id, the template's domain will
be used. This seems like a bad idea. It can hide failures to provide
message ids because everything
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
there are cases where you need to evaluate an expression to get the
msgid for instance in:
there is a workaround, but it is very inelegant:
http://svn.nuxeo.org/trac/pub/changeset/27505
the translation could be done in python, but I guess
to have
something simple that is nevertheless flexible enough to
accommodate to various needs.
So I came up with the following stuff (mainly combining concepts
by Jean-Marc Orliaguet and implementation ideas from Archetypes
1.3) :
A relation is an object providing the IRelation interface
Reinoud van Leeuwen wrote:
On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
A relation is an object providing the IRelation interface. This
has got two attributes ('first', 'second' - dyadic relation) or
I've done this kind of thing in relational databases. Problem with
Reinoud van Leeuwen wrote:
On Fri, Nov 11, 2005 at 04:44:47PM +0100, Jean-Marc Orliaguet wrote:
Reinoud van Leeuwen wrote:
On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
A relation is an object providing the IRelation interface. This
has got two attributes
Helmut Merz wrote:
Am Freitag, 11. November 2005 16:11 schrieb Jean-Marc Orliaguet:
Hi Helmut!
Hi Jean-Marc,
thanks for your remarks,
just before going into more detail: My primary concern was the
API - it would really fine if there could be a simple (as simple
as possible
Helmut Merz wrote:
Am Freitag, 11. November 2005 18:00 schrieb Jean-Marc Orliaguet:
I was thinking more about the policy of assigning unique ids
to objects in a relation. It's the application that really
should decide about that policy.
in fact the unique ids aren't assigned
Helmut Merz wrote:
Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet:
My
impression is that you are thinking of a reference engine
rather than a relation engine
Maybe I just don't see the difference... (There is one, of
course, but I doubt it is really of relevance
Helmut Merz wrote:
Anyway, what we are talking about are not references.
The approach is quite different: references start from the objects
themselves that they connect to other objects using one-way relations (a
pointer, an arrow). The application has to know how to interpret the
Hi!
are there any guidelines / best practises for setting the contents of
__init__.py, interfaces.py, and the packages that they import or that
they expose? there are too many alternatives and too many ways of ending
up doing circular imports and I'd like to have a consistent pattern for
Martijn Faassen wrote:
Hi there,
Hi Martijn,
Jean-Marc Orliaguet wrote:
some packages have an interfaces.py file others have a interfaces
folder, others have the interface definitions in the implementation
code itself ...
The pattern changed over time during Zope 3 development. In my
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the same
package or in a subpackage?
- public interfaces are stored in interfaces.py
- private interfaces are written along with the implementation code
- what
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
unless for the convenient import of other modules located in the
same package or in a subpackage?
Actually, primarily for convenient import by external packages.
yes indeed
Jim Fulton wrote:
yes indeed, but no cross imports between packages that are siblings.
Huh? Why? I'm not at all sure I know what you mean.
the question is what relation between the importer and the imported are
OK: if I add such imports in __init__.py, I should only import from
There is another place where there seems to be two different patterns too:
sometimes we have:
import zope.schema
name = zope.schema.TextLine(...)
and sometimes:
from zope.schema import TextLine
name = TextLine(...)
any reason to use one or the other (speed, verbosity, avoiding
Hi!
what is the rationale between the unique integer ids utility and the
usage policy?
more specifically: why are newly added objects registered in *all*
IntIds utilities? It does not make sense if the utility is registered
locally. If they are local they should not be concerned with
j.kartnaller wrote:
This has already been added to the bug collector :
http://www.zope.org/Collectors/Zope3-dev/466
Jürgen
Jean-Marc Orliaguet wrote:
Hi!
what is the rationale between the unique integer ids utility and the
usage policy?
more specifically: why are newly added objects
for a template to create an manage entire
sites disappears.
see for instance:
Unified model for managing application resources
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_11_10_unified-model-for
The separation of concerns (the site manager manages filesystem and TTW
resources
Martijn Faassen wrote:
my impression is that if you want TTW editing you'll have to do it on
an application level using what's available in the framework
(utilities, ZPT, ...) Zope3 allows you to do this already and in a
much cleaner way than with zope2..
That's great! How to make this
Martijn Faassen wrote:
Jean-Marc Orliaguet wrote:
[snip]
It is a bit like this: the zope2 community wants the zope3 technology
and zope3 wants the zope2 community.
I like this analysis. :)
I think the question about the technology should be treated as such
on a technical level
erik wrote:
Hi,
HI!
I'm just a tiny little bit confused here, what is a view and what is a resource
- in Zope2 and in Zope3 ? ;-)
there's a notion of resource already in Zope3 that encompasses: images,
files and templates
in cpsskins (zope3) the notion also encompasses more
Martin Aspeli wrote:
I think there are two cases: The first is the tinkerer, who
wants to customise primarily the template as easily as possible,
preferably TTW.
OK, I buy this. You want to be able to modify resources, try
different options ... Then you might want to export them the
Florent Guillaume wrote:
Well I don't want to appear to defend Apple Mail too much here, but
splitting a URL after a / can be seen as a natural location.
And in any case this wouldn't be a problem if Mozilla coders weren't
lazy :-) (decoding rfc3676 (which is nearly 2 years old now) is
Florent Guillaume wrote:
Redirecting to a relative url is illegal in the HTTP spec. You must
always use a fully qualified url.
Florent
+redirect_url = REQUEST['HTTP_REFERER'] or '.'
+RESPONSE.redirect(redirect_url)
OK, but can you raise that one zope3-dev? It is used all over
Jean-Marc Orliaguet wrote:
Florent Guillaume wrote:
Redirecting to a relative url is illegal in the HTTP spec. You must
always use a fully qualified url.
Florent
+redirect_url = REQUEST['HTTP_REFERER'] or '.'
+RESPONSE.redirect(redirect_url)
OK, but can you raise that one
Hi!
I'm about to write an xml importer for importing simple data
(properties, dictionaries). Exporting is easy, importing is trickier
because a parser is required.
Is there any prefered framework for doing such things in zope3 (zope2)?
CMFSetup uses sax, GenericSetup uses sax too. ZCML
Tarek Ziadé wrote:
Florent Guillaume wrote:
Tarek Ziadé wrote:
Hi all,
Some UI works have been done lately around and in Zope 3. I am thinking
about the work that has been done at Neckar sprint (Zope3.org website,
Viewlets, etc..), and on projects like CPSSkins for Z3 at ECM.
I
Andreas Jung wrote:
--On 6. Dezember 2005 16:46:02 +0100 Jean-Marc Orliaguet
[EMAIL PROTECTED] wrote:
Hi!
I'm about to write an xml importer for importing simple data
(properties,
dictionaries). Exporting is easy, importing is trickier because a parser
is required.
Is there any
Martijn Faassen wrote:
Andreas Jung wrote:
I'm about to write an xml importer for importing simple data
(properties,
dictionaries). Exporting is easy, importing is trickier because a
parser
is required.
Is there any prefered framework for doing such things in zope3 (zope2)?
Sax or
Hi!
Here is an implementation of "compound storages" in CPSSkins (this
concerns the CPSSkins AJAX toolkit only so it also applies to Zope3 in
general, or to any other server that can handle JSON requests and
responses).
First of all, this is a great step towards simplifying the development
Hi!
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. For the record MochiKit also has something equivalent called
MochiTAL that supports tal:content and tal:repeat.
Anyway, CTAL implements
Balazs Ree wrote:
Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
írta:
I almost felt that something was missing, because I'm so used to inserting
tal:define in page templates. But now I realize that this is a mistake.
There was a discussion recently on the list about
kit BLAKE wrote:
In 'normal' tal we often refactor our defines to improve efficiency.
When something is called more than once in a template, we define it at
the beginning, and then use it multiple times. This improves
performance dramatically of course.
kit
--
kit BLAKE
Infrae · infrae.com ·
Andreas Jung wrote:
--On 12. Februar 2006 19:18:51 +0100 Max M [EMAIL PROTECTED] wrote:
a href=#
tal:attributes=href here/absolute_url;
title here/title;
id here/getId
tal:content=here/TitleTitle/a
I could write this:
a
Tonico Strasser wrote:
Hi Jean-Marc!
I agree that a view should not be able to modify the data model. But I
think tal:define is a must have :)
For example: I need tal:define to define names for generic macros:
ul tal:define=list main_navigation
li metal:use-macro=macros/li_repeat/
/ul
Tonico Strasser wrote:
(Again with the right quote, sorry.)
Jean-Marc Orliaguet wrote:
That's exactly what I'm saying: if templates did not try to create
their own data layer, the 'li_repeat' macro could get the data from
the model (instead it has to rely on cross-template communication
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tonico Strasser wrote:
I'm interested in your opinion about parameters for macros.
Do you think this is explicit enough?:
ul tal:define=list main_navigation
li metal:use-macro=macros/li_repeat/
/ul
Or do you think
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 couldn't find it, but I'm
intrigued. Any link
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
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
Hi!
there is a bug in TAL interpreter (zope2.8 / zope2.9), the following markup
div tal:attributes=a python:'é'; b python:u'é'.../div
(which mixes unicode- and non unicode-encoded attributes) generates an
exception::
result = self.pt_render(extra_context=bound_names)
File
Martijn Faassen wrote:
I don't think it has an implementation of string TALES expressions.
It's parsing anything that's actually *inside* the attributes you add
on HTML with tal, such as detecting whether a TALES expression type
identifier is used ('string:' or 'python:', say), or
Paul Winkler wrote:
On Thu, Feb 16, 2006 at 07:06:03PM +0100, Jean-Marc Orliaguet wrote:
Yes, that's what I mean. Clearsilver is a good example. There are
several advantages:
- the data structures are platform-independent (they can be encoded in
JSON, C, python), and they can be easily
' to 'font-style: bold' (which is pure
presentation logic).
tal:define is OK if it handles presentation data that only the
template/view is concerned with.
/JM
original message:
On 11. Feb 2006, at 21:03, Jean-Marc Orliaguet wrote:
I almost felt that something was missing, because I'm so used
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
[snip]
I would vote for spelling out Zed (which would also be a little easier
to google but might create trademark problems). The namespace package
could either be 'z' or 'zed'.
Then again, I really should take Jim's side and stay out
Rob Jeschofnik wrote:
Jim Fulton wrote:
I think a lack of a realistic vision means that we are pulling in
different directions. I think this is causing a lot of harm.
I think the crux of the issue here is that presently, we do not have a
consistent answer to the question What is `Zope'?.
Max M wrote:
Geoff Davis wrote:
Jeff Shell has posted some thought-provoking pieces on his blog that are
relevant to Jim's recent attempt to better articulate a vision for Zope:
http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html
Paul Everitt wrote:
Shane Hathaway wrote:
Stephan Richter 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 breaks
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Yup.
BTW, a general thing to keep in mind:
- Indirection and abstraction are inherently bad because they
hide things. :)
(This is a corolary of explicit is better than implicit.)
- But indirection and abstraction can
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
I was refering to high-level ZCML, such browser:page, browser:menu, etc
vs low-level directives like adapter.
Jim
I would say that they paraphrase more lines of code than the
low-level ones, but they fundamentally add no extremely valuable
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
Zachery Bir wrote:
On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote:
which is strictly equivalent to Implicit is better than explicit,
except when it's not. :-) and when it's not ... explicit is better.
Clearly arbitraritude is better than claritization, except when
Jim Fulton wrote:
I'd also like to acknowledge Tres' point about high-level non-Python
definition mechanisms for things like forms and schemas. I agree
with him that such facilities could be a good thing. I may disagree
with him on whether these should be ZCML. I definately don't think
that
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
I stand by my conclusions on this approach sounding simple in theory,
but still being a bit harder than it should be in practice. :)
I think this is pretty simple:
def makeAnnotationAdapter(for_, factory,
Martijn Faassen wrote:
Jean-Marc Orliaguet wrote:
[snip]
excuse me, but can someone explain what problem the pattern /
workaround is supposed to fix, does it create and return a default
annotation value in case an annotation key does not exist? shouldn't
the annotation machinery be fixed
Martijn Faassen wrote:
Jean-Marc Orliaguet wrote:
[snip]
OK, basically you mean that the 'annotations' given in your original
post should implement a 'setdefault' method?
I don't see how that would help - you'd still end up writing a factory
that uses the setdefault, right?
I don't want
Jim Fulton wrote:
Stephan Richter wrote:
On Friday 17 March 2006 06:34, Jim Fulton wrote:
The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.
Of course, the undo feature has other benefits,
Hi!
what is the best way in zope3 to create a collection of interfaces
without using classes, lists, etc.?
I have a number of interfaces that I'd like to group into a same
interface category.
e.g. ISomeCollection = I1, I2, I3, I4
and I'd like to be able to query which interfaces
Hi!
I've began formalizing some ideas about how to identify application
resources:
http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/io/README.txt
I post to zope3-dev too in case someone has some ideas about it. A lot
of the points described are pertinent to zope3.
1 - 100 of 123 matches
Mail list logo