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
s
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
separate now when Zope
Martijn Faassen wrote:
> With a package in the 'zope' namespace, what am I supposed to do when I
> install it? Symlink it into lib/python of my Zope 3 software home?
For the record: no.
You can simply have multiple directories for a namespace package when
you use 'pkgutil'. See
http://python.org/
Martijn Faassen wrote:
> Just to drop a note that I think a discussion about a potential brand
> name for Zope 3 is far less important than actually fixing our website
> and presenting Zope 3 (and Zope 2 for that matter) in a better way.
>
> Perhaps we can better redirect our energies to that than
Jim Fulton wrote:
> Some recent discussions on the distutils-sig mailing list have
> helped me to understand some issues related to the ways we
> extend the Zope application server. Traditionally, in Zope 2,
> you extended Zope by "dropping" product packages into a special
> "Products" package. T
Chris McDonough wrote:
>> I'm told that the ZODB is the de-facto way of storing content. Maybe
>> soon the default may be a filesystem. Mmm...
>
>
> My feelings are that there should be a "classic" Zope 3 release which
> is exactly what exists now (it should make the assumption that ZODB is
>
Shane Hathaway wrote:
> Any thoughts or gut reactions?
For the record, my gut reaction: Very interesting idea!
I think there are two parts to the rationale here:
1) Making it easy to quickly prototype an app on the filesystem using
methods that people are familiar with. You mention that above.
Jim Fulton wrote:
In summary, I think we need *both* approaches, as they serve different
needs.
I'd have to agree... so +1
.. but I'd suggest that the application/plugin should have a way of
defining which ways it can (or prefers, if it can't be enforced) to be
included, so it is clear that P
Shane Hathaway wrote:
Zope is a feast with many kinds of food. When people come to the
feast, most are not willing to try everything at once, particularly
the entrees from the land of OODBMS. First let them have some
familiar foods. When they find out how finely prepared the food is,
they
On Fri, 10 Feb 2006 16:56:23 -, 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 firs
On Fri, 10 Feb 2006 23:49:55 -, Shane Hathaway <[EMAIL PROTECTED]>
wrote:
So, I'm serving static content like Apache, I'm interpreting file
types like Apache and I'm using .htaccess files like Apache. But I'm
using Zope.
Why am I not just using Apache?
Would I be learning this beas
Some recent discussions on the distutils-sig mailing list have
helped me to understand some issues related to the ways we
extend the Zope application server. Traditionally, in Zope 2,
you extended Zope by "dropping" product packages into a special
"Products" package. This was very convenient in
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 imple
I really like this idea. I spend most of my time developing applications
with Plone, and am just starting to use zope 3. Most of what I spend my
time on is site customisation and one off development. But I've never
really found a nice way to layout my applications, Product (or more
standard pyt
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 ou
On Feb 11, 2006, at 9:24 AM, Martin Aspeli wrote:
I'm told that the ZODB is the de-facto way of storing content.
Maybe soon the default may be a filesystem. Mmm...
My feelings are that there should be a "classic" Zope 3 release which
is exactly what exists now (it should make the assumption
On 2/11/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
> There are two types of deprecation, though - one is deprecating specific
> packages or methods or classes. Another is deprecating fundamental
> patterns and ways of working. Am I supposed to use ZCML for this or
> Python? Well, a while ago, it
On Sat, 11 Feb 2006 10:39:52 -, Lennart Regebro <[EMAIL PROTECTED]>
wrote:
things. Extreme example: In Plone the core Plone product is called
CMFPlone. It pisses Alexander off. Should we rename it 'Plone' and thus
break every product that ever imported from CMFPlone? Should we make a
jungl
> things. Extreme example: In Plone the core Plone product is called
> CMFPlone. It pisses Alexander off. Should we rename it 'Plone' and thus
> break every product that ever imported from CMFPlone? Should we make a
> jungle of aliases and deprecation warnings? Or should we live with our
> mistakes
19 matches
Mail list logo