Message: 1 Date: Tue, 06 Dec 2005 18:32:47 -0500 From: Benji York <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] Ajax in Zope 3 To: Tarek Ziad? <[EMAIL PROTECTED]> Cc: "zope3-dev@zope.org \(E-mail\)" <zope3-dev@zope.org> Message-ID: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: mercredi 7 decembre 2005 11:44 To: zope3-dev@zope.org Subject: Zope3-dev Digest, Vol 29, Issue 14 Send Zope3-dev mailing list submissions to zope3-dev@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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] Ajax in Zope 3 To: Tarek Ziad? <[EMAIL PROTECTED]> Cc: "zope3-dev@zope.org \(E-mail\)" <zope3-dev@zope.org> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] Re: Ajax in Zope 3 To: Florent Guillaume <[EMAIL PROTECTED]> Cc: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Zope3-dev] Twisted Publisher and Zope 2 To: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Zope3-dev] Re: Proposal for zopectl extensions To: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] Twisted Publisher and Zope 2 To: Sidnei da Silva <[EMAIL PROTECTED]> Cc: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] xml import / export in z2 & z3 To: Andreas Jung <[EMAIL PROTECTED]> Cc: "zope3-dev@zope.org \(E-mail\)" <zope3-dev@zope.org> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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 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 <[EMAIL PROTECTED]> Subject: Re: [Zope3-dev] Zope 3.2.0 Beta 1 released To: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 On 12/6/05, Jim Fulton <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Zope3-dev] RFC: Simplify Skinning To: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Zope3-dev] Re: RFC: undeprecate auto-message id translation To: Florent Guillaume <[EMAIL PROTECTED]> Cc: zope3-dev@zope.org, Martijn Faassen <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Subject: [Zope3-dev] Re: RFC: undeprecate auto-message id translation To: [EMAIL PROTECTED] Cc: zope3-dev@zope.org Message-ID: <[EMAIL PROTECTED]> 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@zope.org http://mail.zope.org/mailman/listinfo/zope3-dev End of Zope3-dev Digest, Vol 29, Issue 14 ***************************************** _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
