On Wednesday 14 April 2004 01:49 am, Andreas Jung wrote:
What is the recommend way to migrate existing code?
I assume using:
import logging
logger = logging.getLogger(loggername).
That works, and certainly matches what I've been doing, and what we see in the
Zope 3 codebase as well.
Note that the reason I suggested renaming Zope to zope2 (or whatever) as
opposed to zope to zope3 is because Zope 3 uses absolute imports almost
everywhere; it would be far less work to change Zope to Zope2 because
Zope 2 either uses relative imports or assumes it can find what it needs on
b i18n:translate= i18n:domain=ibc i18n:target=string:czGood
morning/b
Is my syntax wrong?
Maybe. Get i18ndude (google) and search for i18n docs for ZPT (google,
too) :)
Believe me, I googled before I wrote my original post. The syntax I used
is derived from documentation at
I realize that my original post implied that I failed to do the
homework. Here's the info:
My .po file is OK. Zope 2.7 reads it correctly, as shown in startup log.
When I test the translation in
/Control_Panel/TranslationService/manage_main, it translates the message
'Good morning' correctly.
From: Andreas Jung [EMAIL PROTECTED]
When I look through the Zope HEAD code then you are using e.g.
'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we
have to agree on some common usage of the logger names?
E.g. for logging calls in the reST packagebetter using 'Zope' or
On Tue, 2004-04-13 at 20:53, [EMAIL PROTECTED] wrote:
Hello,
Hmmm, well it's as stable as Ape and Subversion are respectively :)
I wouldn't call it stable no, it's something I did over the long week-end we
just had, and that's about it :)
Ape is at 0.8 and therefore becoming quite
On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
On Tue, 13 Apr 2004 [EMAIL PROTECTED] wrote:
Thanks for the extra tips, I'll check out those interfaces! I'm also getting
up to speed on the whole mapper concept, where the work regarding properties
handling seems to be ?
Ape supports
On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
since
objects modified in a version are in essence locked from participating
in other transactions, actions like modifying content in a version in a
cmf site amounts to locking the catalog
granted the svn integration has lots of coolness factors including
richer client integration, but things like zope version control
(zope.org cvs) are already production quality and not so hard to
integrate in for basic version control.
-kapil
On Tue, 2004-04-13 at 14:13, Arthur Chan Chi Chuen
Jim Fulton wrote:
Zope 2 has a package named Zope. Zope 3 has a package named zope.
Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2.
As things stand, this will require having both Zope and zope packages.
Python can handle this fine, however, it will require putting the packages
On Wed, 14 Apr 2004 06:59:05 -0400
Kapil Thangavelu [EMAIL PROTECTED] wrote:
On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote:
On Tue, 13 Apr 2004, Kapil Thangavelu wrote:
since
objects modified in a version are in essence locked from
participating in other transactions, actions
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
snip
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates
agreement
On Wed, 14 Apr 2004 09:50:17 -0400
Casey Duncan [EMAIL PROTECTED] wrote:
[..]
In practical terms this would mean that the versioned catalog would
need to keep track of the uids that had been cataloged, uncataloged
and reindexed in the version. The merge would mean cataloging,
uncataloging and
+1 this is a problem.
The question is whether curing it is *more* of a problem.
-Casey
On Wed, 14 Apr 2004 09:00:26 -0400
Jim Fulton [EMAIL PROTECTED] wrote:
Jim Fulton wrote:
Zope 2 has a package named Zope. Zope 3 has a package named
zope. Starting with Zope 2.8, parts of Zope 3 will
Kapil,
Right now, the svn transactions are entirely contained within a single
fileops operation: for example a mkdir connects to a transaction root,
performs the necessary operations, and commits, all in one shot.
Last night I took some more time to try and learn more about Ape's
functionning
Kapil Thangavelu wrote:
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
snip
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...)
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live in 'lib/python'. No case problem
On Wednesday 14 April 2004 09:54 am, Kapil Thangavelu wrote:
its probably a problem imo for mac users who are on a case insensitive
fs.
Is this still an issue for Mac OS X, or is your concern for classic Mac OS? I
don't know if we support that (simply because I've never heard anyone mention
-1, it is not really a problem. As Chris pointed out, this will be hard to
explain in documentation, but I think it will not be as big of a pain as
requiring 3rd parties to change their code (this is for both, Zope 2 and 3).
Furthermore, I really dislike the option of renaming zope in Zope 3 to
Philipp von Weitershausen wrote:
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live
Shane,
As Kapil already mentionned, svn's support for properties is quite flexible,
so that doesn't worry me too much.
I would imagine and administrator having the flexibility of choosing how
objects get translateds to files might be handy.
My initial, uneducated thoughts on the topic were
--On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
From: Andreas Jung [EMAIL PROTECTED]
When I look through the Zope HEAD code then you are using e.g.
'zodb.conn' or 'zodb.storage' but also 'Zope' as loggername. Do we
have to agree on some common usage of
The property schema thing is a good point, though I'm not sure we could ever
do anything about it, not with the purpose to help naive gui clients work
better with the repository.
By nature the object structure (Class instance) is not fixed, so the
amount/name/data of properties could vary
--On Mittwoch, 14. April 2004 16:45 Uhr +0200 Andreas Jung
[EMAIL PROTECTED] wrote:
--On Mittwoch, 14. April 2004 10:57 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
From: Andreas Jung [EMAIL PROTECTED]
When I look through the Zope HEAD code then you are using e.g.
'zodb.conn' or
Jim Fulton wrote:
Jim Fulton wrote:
...
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to
summarize
Wrong. People don't find the question useful.
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
+1
A response with a positive sign (e.g. +1, +0, +2, ...) indicates
agreement that this is a probelm. :)
Jim
Andrew
--
Zope Corporation
Software Engineer
(540) 361-1700
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits with the expansion of Zope:
Z
Stephan Richter wrote:
On Tuesday 13 April 2004 22:17, Tres Seaver wrote:
snip
Of course, having two packages with names differing only in case is a
bit ugly.
Do we want to consider renaming one or both of these packages
to avoid the conflict?
-1 to renaming 'Zope'; the amount of third-party
Chris McDonough wrote:
Note that the reason I suggested renaming Zope to zope2 (or whatever) as
opposed to zope to zope3 is because Zope 3 uses absolute imports almost
everywhere; it would be far less work to change Zope to Zope2 because
Zope 2 either uses relative imports or assumes it can find
Greetings.
Does anyone know of a good (stable, reliable, fast enough for
production use in a web app) ZODB-equivalent for persisting Java
objects?
Thanks,
..Ian
-- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
Dr. Ian Beatty [EMAIL PROTECTED]
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to z.
Examples (from the buddydemo example):
import z.interface
from z.app import zapi
from z.app.event import publish
from z.app.event.objectevent import ObjectModifiedEvent
hi,
you should search on freshmeat.net.
-aj
--On Montag, 12. April 2004 16:05 Uhr -0400 Ian Beatty
[EMAIL PROTECTED] wrote:
Greetings.
Does anyone know of a good (stable, reliable, fast enough for production
use in a web app) ZODB-equivalent for persisting Java objects?
Thanks,
..Ian
--
Stephan Richter wrote:
On Wednesday 14 April 2004 11:08, Jim Fulton wrote:
...
What about z.app.foo or z.i18n?
The shortness of this example is very attractive, but it is still a compromise
in my opinion.
Again, I think educating is easier than anything else. People understand that
this is
From: Andreas Jung [EMAIL PROTECTED]
Keep the product name as it is...means Products/ should use
Zope. as logger name. No need to introduce a new mapping. Keep it
simple.
Yeah, but is it reasonable to think that people who write new products will
do this? A rule that most people will
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote:
Because in general I don't like version numbers in the path. I also think that
zope is the only name that is 100% right on. Everything else is a
compromise I would try to avoid. We will be sorry about it later, when many
more people run
On Wednesday 14 April 2004 11:36, Jim Fulton wrote:
Again, I think educating is easier than anything else. People understand
that this is due to a merge of codebases and is for a transition period
only. And, the TTW scripter will not care.
But this is a really important transition. It's a
On Wednesday 14 April 2004 11:44, Barry Warsaw wrote:
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote:
Because in general I don't like version numbers in the path. I also think
that zope is the only name that is 100% right on. Everything else is a
compromise I would try to avoid. We will
On Wednesday 14 April 2004 11:44 am, Lennart Regebro wrote:
Yeah, but is it reasonable to think that people who write new products
will do this? A rule that most people will break is a bad rule... That
people working on Zope itself can be well versed enough to use Zope.
for things in
Jim Fulton wrote:
Chris McDonough wrote:
I think the breakage, although literally incalculable (as is
every change to Zope 2, given that it has no canonical API), would be
manageable given enough lead time. In fact, if we did change the module
name, we could just leave a bruce package in place
Hi
I try to get the icons of the installed products
I try to get it with the self.all_meta_types()/instance/icon
My better result is something like:
misc_/Audio/mp3.gif
with these path I can use:
self.unrestrictedTraverse(icon)
where icon is the path above (misc_/Audio/mp3.gif)
With these
On Wednesday 14 April 2004 10:52 am, Jim Fulton wrote:
packages become very unsttractive. It turns out that pkgutil will be
confused by the Zope package on Windows or Mac OS, adding it's directory
to the zope package's path. This is a bug in pkgutil that can be fixed,
but it is an example
Marius Gedminas wrote:
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to z.
Examples (from the buddydemo example):
import z.interface
from z.app import zapi
from z.app.event import publish
from z.app.event.objectevent import
Jim Fulton wrote:
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits with the
+1 from me !
I'm always in favor of less typing :P Besides, you make good points :)
J.F.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jim Fulton
Sent: April 14, 2004 3:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:
Hello All,
I am trying to use ZPT within a Zope
Product I am trying to build.
I want to test the container type I am addding to to determine what
action
to take. The following though
from
Products.PageTemplates.PageTemplateFile import PageTemplateFile
def
On Wednesday 14 April 2004 10:45 am, Andreas Jung wrote:
For consitency: Zope.Products.
For lazy writers: Zope. X
I prefer the second solution...everyone should know what are products and
what
are packages. In fact the name does not matter because you can see in the
traceback
On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote:
My initial, uneducated thoughts on the topic were simplistic, but then I'm a
big K.I.S.S. fan: simply pickle the entire object back and forth as one
entity. This means for each object, there is one file on the fs. The
benefit is greater
On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote:
Right now the fs implementation stores script commands that are cummulated
upon connect() (I think?), validated as best as possible upon vote() and run
upon finish(). I don't see why this couldn't be adapted to SVN txn's ...
connect() = start a
On Wed, 14 Apr 2004 [EMAIL PROTECTED] wrote:
Fact is if one wanted a client to interact with a svn repository that stores
zope objects, it would need to be fairly specifically designed for it ...
How would a client (Say dreamweaver with a subversion plug-in) know that
when editing an image,
On 04/14/04 12:27, yuppie wrote:
Jim Fulton wrote:
But I think that this is a big problem. Backward compatibility for Z2
*is*
important. It's too bad that lots of test files have to import Zope.
Sigh.
Why is that a *big* problem?
- It's not nice to break tests, but that doesn't necessarily
On Wed, Apr 14, 2004 at 03:53:43PM -0400, Jim Fulton wrote:
| Other reasons I like z:
|
| - Less noise in imports
|
| - Echos the circle z
|
| - The packages in z can be used for more than just Zope
|
| - Emphasizes the more minimalist nature of Zope 3 relative
| to Zope 2
|
| - z is a
cool, let me try the cmfsvnbrowser first
thanks. =)
Arthur
On Wed, 14 Apr 2004 10:35:14 -0400, Jean-Francois.Doyon wrote
Well there you go, perfect :)
-Original Message-
From: Kapil Thangavelu [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 6:49 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL
On Thu, 15 Apr 2004, Arthur Chan Chi Chuen wrote:
I know you're pretty busy preparing the SVN stuff, but let me ask you a quick
question about VerboseSecurity.
Sorry, I didn't mean to drop this. My inbox got too full. :-)
Someone online said the cvs.zope.org works in 2.7, but it's not.
On Wed, 2004-04-14 at 18:53, Fred Drake wrote:
Keeping it simple is good, but I'd still like to see every logging subsystem
in code that ships with the Zope 2 core start with Zope. This is a
potential backwards compatibility issue, though, since log-trawling tools are
already using the
[Chris McDonough]
There probably are no log-trawling tools. The output generated by zLOG
is basically unparseable.
Alas, that hasn't stopped people from writing trawlers to analyze ZEO server
and client logs. That one's going to be my headache to fix(*), and has
some urgency since ZODB/ZEO's
Oh, a very good idea indeed! We'll have to look at that eventually.
The mechanism you describe is preferable, but it should be noted that
subversion properties are easily accessible using the clients.
So long as said properties are human readable/writable, that's also an
option.
The main
56 matches
Mail list logo
