[Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 14
Fabrice Monaco
fmonaco at cirb.irisnet.be
Wed Dec 7 08:44:24 EST 2005
Message: 1
Date: Tue, 06 Dec 2005 18:32:47 -0500
From: Benji York <benji at zope.com>
Subject: Re: [Zope3-dev] Ajax in Zope 3
To: Tarek Ziad? <tziade at nuxeo.com>
Cc: "zope3-dev at zope.org \(E-mail\)" <zope3-dev at zope.org>
Message-ID: <43961F9F.1030204 at zope.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ajax in Zope 3 (Benji York)
Hi,
I just one remark for XUL, Xul is supported by engine Gecko, Gekco is engine
for all application Mozilla (FireFox, Thunderbird, Camino, Xulrunner, ...).
One application developed in XUL is MultiPlateform and more is possibel to
use XPI package for automatic installation.
-----Original Message-----
From: zope3-dev-bounces+fmonaco=cirb.irisnet.be at zope.org
[mailto:zope3-dev-bounces+fmonaco=cirb.irisnet.be at zope.org]On Behalf Of
zope3-dev-request at zope.org
Sent: mercredi 7 decembre 2005 11:44
To: zope3-dev at zope.org
Subject: Zope3-dev Digest, Vol 29, Issue 14
Send Zope3-dev mailing list submissions to
zope3-dev at zope.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.zope.org/mailman/listinfo/zope3-dev
or, via email, send a message with subject or body 'help' to
zope3-dev-request at zope.org
You can reach the person managing the list at
zope3-dev-owner at zope.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Zope3-dev digest..."
Today's Topics:
1. Re: Ajax in Zope 3 (Benji York)
2. Re: Re: Ajax in Zope 3 (Benji York)
3. Twisted Publisher and Zope 2 (Sidnei da Silva)
4. Re: Proposal for zopectl extensions (Tres Seaver)
5. Re: Twisted Publisher and Zope 2 (Jim Fulton)
6. Re: xml import / export in z2 & z3 (Jean-Marc Orliaguet)
7. Re: Zope 3.2.0 Beta 1 released (baiju m)
8. RFC: Simplify Skinning (Philipp von Weitershausen)
9. Re: RFC: undeprecate auto-message id translation
(Philipp von Weitershausen)
10. Re: RFC: undeprecate auto-message id translation
(Philipp von Weitershausen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 06 Dec 2005 18:32:47 -0500
From: Benji York <benji at zope.com>
Subject: Re: [Zope3-dev] Ajax in Zope 3
To: Tarek Ziad? <tziade at nuxeo.com>
Cc: "zope3-dev at zope.org \(E-mail\)" <zope3-dev at zope.org>
Message-ID: <43961F9F.1030204 at zope.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Tarek Ziadi wrote:
> I don't know if Javascript is mature...
I meant that there are many new Ajax toolkits out there that haven't
been there for long. I wouldn't consider any of them mature. Mochikit
comes the closest as far as I can tell.
> I was talking about a toolkit because it seems that most of the time
> there's a cohesion between a web framework, its community, and a js
> toolkit
I would hate to see Z3 create its own JS toolkit. I would love to see
the community begin to use one or more and find good ways for Z3 to make
using them easy. Jean-Marc had some good points on what we could do to
make it easier.
> But anyway, it seems wise to start up with server side ajax views and
> other helper.
>
> I am looking forward for the proposal revision :)
Me too.
--
Benji York
Senior Software Engineer
Zope Corporation
------------------------------
Message: 2
Date: Tue, 06 Dec 2005 18:43:44 -0500
From: Benji York <benji at zope.com>
Subject: Re: [Zope3-dev] Re: Ajax in Zope 3
To: Florent Guillaume <fg at nuxeo.com>
Cc: zope3-dev at zope.org
Message-ID: <43962230.7000809 at zope.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Florent Guillaume wrote:
> Myself I absolutely love the approach taken by CrackAjax
>
(http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_fr
amework)
It's funny you mention that. I was intrigued by that too, but I can
only characterize his implementation as a toy. :(
I've been working on something similar but have tried to be a bit more
"professional" about it (unit tests, trying to be a good designer,
etc.). Like CrackAjax it only does translation of Python syntax to
JavaScript, but it does a good job and I really like the ability to
define client-side methods on the view. Here's an example from my
prototype (the canvas tag only works in Safari, Konquerer, and Firefox 1.5):
from anguine.view import AnguineView
from anguine.decorator import clientside
from zope.app.publisher.browser import BrowserView
class TestView1(BrowserView, AnguineView):
@clientside
def getContext():
canvas = document.getElementById('test_canvas')
return canvas.getContext('2d')
@clientside
def draw():
ctx = getContext()
ctx.translate(75,75)
for i in range(6):
ctx.save()
ctx.fillStyle = 'rgb('+(51*i)+','+(255-51*i)+',255)'
for i in range(6):
ctx.rotate(Math.PI*2/(i*6))
ctx.beginPath()
ctx.arc(0,i*12.5,5,0,Math.PI*2,true)
ctx.fill()
ctx.restore()
@clientside
def clearCanvas():
ctx = getContext()
ctx.clearRect(0, 0, 150, 150)
Here's the ZPT:
<html metal:use-macro="context/@@standard_macros/view">
<script
metal:fill-slot="headers"
tal:content="structure view/_anguine__js_code"/>
<body metal:fill-slot="body" tal:omit-tag="">
<br>
<canvas id="test_canvas" width="150" height="150"
style="border: 1px solid black;"></canvas>
<button onclick="draw()">Draw</button>
<button onclick="clearCanvas()">Clear</button>
</body>
</html>
I consider this a mad scientist experiment, so I don't expect it to be
officially included anywhere or even get any work from me once the
novelty wears off. You are warned; I don't want angry villagers with
pitchforks and torches coming to my castle. :)
--
Benji York
Senior Software Engineer
Zope Corporation
------------------------------
Message: 3
Date: Tue, 6 Dec 2005 21:56:13 -0200
From: Sidnei da Silva <sidnei at enfoldsystems.com>
Subject: [Zope3-dev] Twisted Publisher and Zope 2
To: zope3-dev at zope.org
Message-ID: <20051206235613.GW4874 at cotia>
Content-Type: text/plain; charset=us-ascii
Hi there,
There's a couple of mad brazilian pythoneers that might hang out
together early in January in some hidden beach somewhere, and one of
the proposed tasks for working on (of course, powered by caipirinha)
was to take a stab at replacing Zope 2's ZServer/ZPublisher by Zope
3's Twisted/Publisher.
I know the brave folks involved in the Zope 3 move-away from ZServer
might have some interesting tips to share, so I hereby invite you to
share your experience.
Best I can tell, it should be pretty doable no?
--
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
------------------------------
Message: 4
Date: Tue, 06 Dec 2005 19:16:47 -0500
From: Tres Seaver <tseaver at palladion.com>
Subject: [Zope3-dev] Re: Proposal for zopectl extensions
To: zope3-dev at zope.org
Message-ID: <439629EF.6090001 at palladion.com>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Zachery Bir wrote:
> I'd like to propose forward porting some behavior from the Zope2
> world's zopectl implementation:
>
> - 'run' command ('run' for hysterical reasons, I'd prefer to call it
> 'exec'): take a filesystem python script and execute it on the
> instance, with access to the root container in locals. The command will
> in turn call the instance/bin/scriptzope script
>
> - 'debug' command will have 'root = debugger.root()' added to the
> debugzope script, so as not to be required. every. single. time. you
> enter a debug session.
>
> Thoughts? While these are technically features, I'd be happy to get
> them in the 3.2 branch as well as the trunk. Neither are invasive, IMHO.
+1.
Tres.
- --
===================================================================
Tres Seaver +1 202-558-7113 tseaver at palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDlinv+gerLs4ltQ4RAhyhAKC2Ix+AtEVEX2g21+qoVCyHoHXfZACfRNBl
G7JNEHmdXfuP4rrFXtMVItY=
=luHP
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Tue, 06 Dec 2005 19:56:00 -0500
From: Jim Fulton <jim at zope.com>
Subject: Re: [Zope3-dev] Twisted Publisher and Zope 2
To: Sidnei da Silva <sidnei at enfoldsystems.com>
Cc: zope3-dev at zope.org
Message-ID: <43963320.5010008 at zope.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Sidnei da Silva wrote:
> Hi there,
>
> There's a couple of mad brazilian pythoneers that might hang out
> together early in January in some hidden beach somewhere, and one of
> the proposed tasks for working on (of course, powered by caipirinha)
> was to take a stab at replacing Zope 2's ZServer/ZPublisher by Zope
> 3's Twisted/Publisher.
>
> I know the brave folks involved in the Zope 3 move-away from ZServer
> might have some interesting tips to share, so I hereby invite you to
> share your experience.
>
> Best I can tell, it should be pretty doable no?
The key is to move to WSGI. Zope 3's publisher now uses
WSGI and so does twisted. For HTTP, the Zope 3 pubisher isn't
based on twisted, it is based on WSGI. There is twisted-specific
glue for FTP.
The most important project here, IMO, is to rewire Zope 2
to use the Zope 3 publisher. And, of course, to update the
Zope 3 publisher with features from the Zope 2 publisher that
are missing from the Zope 3 publisher (e.g. streaming).
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
------------------------------
Message: 6
Date: Wed, 07 Dec 2005 03:02:10 +0100
From: Jean-Marc Orliaguet <jmo at ita.chalmers.se>
Subject: Re: [Zope3-dev] xml import / export in z2 & z3
To: Andreas Jung <lists at andreas-jung.com>
Cc: "zope3-dev at zope.org \(E-mail\)" <zope3-dev at zope.org>
Message-ID: <439642A2.9040001 at ita.chalmers.se>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Andreas Jung wrote:
>
>
> --On 6. Dezember 2005 16:46:02 +0100 Jean-Marc Orliaguet
> <jmo at ita.chalmers.se> 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 prefered framework for doing such things in zope3 (zope2)?
>>
>
> Sax or DOM...it depends on the usecase and the algorithmic approach
> you take. Sax is fast but you have to build your own datastructures,
> DOM is slow, takes a lot of memory but it gives you a tree to perform
> any fancy operation on it..
>
> -aj
>
now I've tried both, DOM (minidom) works the best by far for small
objects (that's by the way used in CMFSetup too). Updating global
datastructures from events with Sax is a pain...
thanks
/JM
------------------------------
Message: 7
Date: Wed, 7 Dec 2005 09:26:58 +0530
From: baiju m <baiju.m.mail at gmail.com>
Subject: Re: [Zope3-dev] Zope 3.2.0 Beta 1 released
To: zope3-dev at zope.org
Message-ID:
<3171e4820512061956pb5fd60ja69079379b78ec53 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 12/6/05, Jim Fulton <jim at zope.com> wrote:
> The Zope 3 development team is proud to announce Zope 3.2.0 beta 1.
Can anyone recommend the best method to install Zope 3.2 in Debian 3.1
(Sarge)
Python version:
1. Install Python 2.4.1 (available in Sarge)
2. Install Python 2.4.2 from testing
3. Install Python 2.4.2 from Python source
Any Zope 3.2 deb packages available?
Thanks,
Baiju M
------------------------------
Message: 8
Date: Wed, 07 Dec 2005 09:55:17 +0100
From: Philipp von Weitershausen <philipp at weitershausen.de>
Subject: [Zope3-dev] RFC: Simplify Skinning
To: zope3-dev at zope.org
Message-ID: <1133945717.4396a375deb43 at mail.philikon.de>
Content-Type: text/plain; charset=ISO-8859-1
Looking for your comments at http://dev.zope.org/Zope3/SimplifySkinning.
This is a follow-up proposal from
http://www.zope.org/Collectors/Zope3-dev/444.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
------------------------------
Message: 9
Date: Wed, 07 Dec 2005 11:17:29 +0100
From: Philipp von Weitershausen <philipp at weitershausen.de>
Subject: [Zope3-dev] Re: RFC: undeprecate auto-message id translation
To: Florent Guillaume <fg at nuxeo.com>
Cc: zope3-dev at zope.org, Martijn Faassen <faassen at infrae.com>
Message-ID: <4396B6B9.7080004 at weitershausen.de>
Content-Type: text/plain; charset=ISO-8859-1
Florent Guillaume wrote:
> Martijn Faassen wrote:
>
>> Zope 2.8 *is* actually interpolating and translating message ids
>> correctly *without* i18n:translate already. I think that this is the
>> same as Zope 3's (deprecated) behavior.
>>
>> The problem is when 'structure' is used in TALES. If this isn't used,
>> translations happen normally. If it is used, translations suddenly
>> break, as do_insertStructure_tal is used instead of do_insertText_tal.
>>
>> I can see that this makes sense if you "structure in" large pieces of
>> HTML -- they won't have translations. It does however break a usecase
>> where your message ids contain HTML. This isn't really clean, but very
>> handy for translators sometimes, especially if they want to use HTML
>> entities and the like. You can then use i18n:translate="" explicitly
>> on the structure, which will cause the *string* to be translated,
>> without interpolation happening. This put me on the wrong track
>> initially, not realizing the impact of 'structure' on the functioning
>> of the TAL interpreter.
>
> I agree that the use case of having translations containing HTML is
> important, and thus that we'll have to make sure do_insertStructure_tal
> also does correct interpolation when faced with a MessageID.
The Zope 3's TALGenerator/TALInterpreter implementation goes a slightly
different way. This May, Dmitry Vasiliev implemented a couple of fixes
regarding i18n in TAL, among them were:
- tal:replace and i18n:translate="" can be used together. This was
something Martijn mentioned isn't possible in Zope 2. It's possible
in Zope 3 now, though.
- tal:content, tal:replace without i18n:translate="" raises
a DeprecationWarning for MessageID/Message objects. This is the
"fix" we want to undeprecate again...
You can see the whole revision here:
http://svn.zope.org/Zope3/trunk/src/zope/?rev=30413&view=rev
Not mentioned in the changelog is a fix for i18n:translate in
combination with structure. But if you look at the diffs of
talinterpreter.py and talgenerator.py, you will see that the generator
now emits the proper bytecode and the interpreter has two new bytecode
handlers, do_insertI18nStructure_tal and do_insertI18nText_tal.
Personally, I would suggest to port this portion of Dmitry's fix. It
might be slightly more complicated than necessary (there are comments
mentioning some unnecessary code duplication), but at least the
ZPT implementations would be kept in sync. This is important for when
we'll switch Zope 2 over to the Zope 3 ZPT implementation some day
(hopefully for Zope 2.10 as Jim mentioned).
Philipp
------------------------------
Message: 10
Date: Wed, 07 Dec 2005 11:44:39 +0100
From: Philipp von Weitershausen <philipp at weitershausen.de>
Subject: [Zope3-dev] Re: RFC: undeprecate auto-message id translation
To: jim at zope.com
Cc: zope3-dev at zope.org
Message-ID: <4396BD17.7020600 at weitershausen.de>
Content-Type: text/plain; charset=ISO-8859-1
Jim Fulton wrote:
> I still don't like the implicit translation of message ids,
I thought like that, too. You really would want implicit translation of
message ids, though, not because implicitness is the right choice here,
but because of general separation of concerns. This is along the same
lines as the domains issue you also mention: The template author has and
should have no control over what he's getting in, the i18n: tags only
affect the ZPT source, like you say.
The i18n domain setting is a good example, another good one is variable
interpolation. The template author might not care about i18n but reuse a
message id from somewhere that uses variable interpolation and has a
mapping with values. Unless translation is turned on, the ${variables}
won't be interpolated with the values from the mapping. So, even though
the template author doesn't care about i18n, he still has to use
i18n:translate="" to trigger variable interpolation.
> If we do this, then it would be tempting to deprecate allowing
> i18n:translate to be used in combination with tal:content or
> tal:replace, however, it is still appropriate to use i18n:translate
> in combination with tal:content if there is a chance that the default
> would be used.
Good point.
> We need to stop thinking about Zope 3 ZPT vs Zope 2 ZPT and switch to
> having one ZPT used by both.
+10
It is crucial that we switch soon. It's not only a p.i.t.a. to maintain
two different implementations, the gap between the two implementations
also gets wider by the minute. Switching over PageTemplateFile shouldn't
be too hard, it gets trickier with persistent PageTemplate objects and
forward compatibility of the pickles. Of course, everything has to be
switched over at once because of macro incompatabilies between Zope 2
and 3 implementations... Oh boy...
Philipp
------------------------------
_______________________________________________
Zope3-dev mailing list
Zope3-dev at zope.org
http://mail.zope.org/mailman/listinfo/zope3-dev
End of Zope3-dev Digest, Vol 29, Issue 14
*****************************************
More information about the Zope3-dev
mailing list