[Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 9
Fabrice Monaco
fmonaco at cirb.irisnet.be
Tue Dec 6 09:44:04 EST 2005
Why not XUL?
-----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: mardi 6 decembre 2005 15:27
To: zope3-dev at zope.org
Subject: Zope3-dev Digest, Vol 29, Issue 9
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. Ajax in Zope 3 (Tarek Ziad?)
2. Re: RFC: undeprecate auto-message id translation
(Florent Guillaume)
3. Re: RFC: undeprecate auto-message id translation (Dmitry Vasiliev)
4. Re: Ajax in Zope 3 (Uwe Oestermeier)
5. Re: Ajax in Zope 3 (Benji York)
6. Re: RFC: undeprecate auto-message id translation (Jim Fulton)
7. Re: Ajax in Zope 3 (Gary Poster)
8. Re: RFC: Make HTTP streaming of large data simpler (Jim Fulton)
9. Re: RFC: Make HTTP streaming of large data simpler
(Sidnei da Silva)
10. Re: RFC: Make HTTP streaming of large data simpler (Jim Fulton)
----------------------------------------------------------------------
Message: 1
Date: Tue, 06 Dec 2005 11:00:18 +0100
From: Tarek Ziad? <tziade at nuxeo.com>
Subject: [Zope3-dev] Ajax in Zope 3
To: zope3-dev at zope.org
Message-ID: <43956132.2080306 at nuxeo.com>
Content-Type: text/plain; charset=ISO-8859-15
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 am planning to work on UI things as well, and on Ajax things in
particular, both for Zope 2 and Zope 3 applications, and trying to
choose the right Javascript toolkit for this.
Before starting it up, I was thinking that it would be nice if the whole
Z3 community would be using the same toolkit, and maybe, even integrate
it into Z3 itself.
This would allow developers to start some js things today under Z2/Five
and port them. This would also probably lead into a "Z3 way" to do ajax
and javascript things.
What people think ?
If this sounds like a good Idea, I would like to start a Z3 proposal on
this topic, and contribute on its integration in Z3.
Regards,
Tarek
--
Tarek Ziadi | Nuxeo R&D (Paris, France)
CPS Plateform : http://www.cps-project.org
mail: tziade at nuxeo.com | tel: +33 (0) 6 30 37 02 63
You need Zope 3 - http://www.z3lab.org/
------------------------------
Message: 2
Date: Tue, 06 Dec 2005 12:24:39 +0100
From: Florent Guillaume <fg at nuxeo.com>
Subject: [Zope3-dev] Re: RFC: undeprecate auto-message id translation
To: Martijn Faassen <faassen at infrae.com>
Cc: zope3-dev <zope3-dev at zope.org>
Message-ID: <439574F7.2020109 at nuxeo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Martijn Faassen wrote:
> Current (deprecated) behavior of Zope 3
> ----------------------------------------
>
> If a message id is defined in python, such as _("Foo"), it gets
> translated by the page template engine automatically when it enters
> through a tal:content, tal:replace, or tal:attributes. No i18n:translate
> is needed.
> [...]
> My proposal is to recommend the use of i18n:translate for ZPT
> translation only, and let the ZPT engine automatically translate
> messages when they come from Python.
+1.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com fg at nuxeo.com
------------------------------
Message: 3
Date: Tue, 06 Dec 2005 14:29:12 +0300
From: Dmitry Vasiliev <lists at hlabs.spb.ru>
Subject: Re: [Zope3-dev] RFC: undeprecate auto-message id translation
To: Martijn Faassen <faassen at infrae.com>
Cc: zope3-dev at zope.org
Message-ID: <43957608.5090802 at hlabs.spb.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Martijn Faassen wrote:
> * if a i18n:translate has to be explictily added, extraction tools will
> find the i18n:translate="" in the ZPT and think there's a message in the
> ZPT to translate. But there's not, it's coming from Python code. This
> might result in the extraction tool mistakenly extracting dummy text:
>
> <p tal:content="context/something" i18n:translate="">This dummy text is
> replaced</p>
>
> Unless the tool is so smart it notices this case. Anyway, the tools
> already extracted the *real* message anyway.
Currently i18nextract just extracts '${DYNAMIC_CONTENT}' marker for all
dynamic
content.
> Risks
> -----
+1 for translate message ids without explicit 'i18n:translate' attribute but
some open questions still remain:
* currently you can translate any string (not only a message id) like this:
<p tal:content="string: STRING TO TRANSLATE" i18n:translate=""></p>
In this case the string will be automatically converted to message id and
then
translated. I think we definitely shouldn't translate any string, only
message ids.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
------------------------------
Message: 4
Date: Tue, 06 Dec 2005 13:36:41 +0100
From: "Uwe Oestermeier" <u.oestermeier at iwm-kmrc.de>
Subject: Re: [Zope3-dev] Ajax in Zope 3
To: "Tarek Ziad? " <tziade at nuxeo.com>
Cc: zope3-dev at zope.org
Message-ID: <fc.000f4a01002cfae53b9aca0004e5e0ca.2cfb8d at iwm-kmrc.de>
Content-Type: text/plain; charset=ISO-8859-1
Hi Tarek,
>
>
>Before starting it up, I was thinking that it would be nice if the whole
>Z3 community would be using the same toolkit, and maybe, even integrate
>it into Z3 itself.
a toolkit that is shared by the whole Zope community would be great,
independent of the question whether it should be part of Z3 core or not.
As an alternative http://svn.zope.org/zope3org could also be a place where
all contributors could access and maintain such a library.
>
>If this sounds like a good Idea, I would like to start a Z3 proposal on
>this topic, and contribute on its integration in Z3.
+1 on a proposal. I would like to contribute to such a package too.
>
>
Regards,
Uwe
------------------------------
Message: 5
Date: Tue, 06 Dec 2005 08:26:07 -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
Message-ID: <4395916F.4060009 at zope.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Tarek Ziadi wrote:
> Before starting it up, I was thinking that it would be nice if the whole
> Z3 community would be using the same toolkit, and maybe, even integrate
> it into Z3 itself.
I think that instead of settling one a single toolkit we should come up
with some simple ideas for offering up server-side components for the
client to use. That way we can easier to use (almost) any client-side
toolkit with Zope 3.
> If this sounds like a good Idea, I would like to start a Z3 proposal on
> this topic, and contribute on its integration in Z3.
I'm very interested in coming up with a one or more relatively simple
server-side proposals to make Ajax stuff easier, but I think the Ajax
stuff (and even the whole JavaScript world) is too immature to settle on
one client-side implementation. Therefore we should concentrate on
doing things that help most or all of the JS toolkits be more usable
with Z3.
--
Benji York
Senior Software Engineer
Zope Corporation
------------------------------
Message: 6
Date: Tue, 06 Dec 2005 08:49:52 -0500
From: Jim Fulton <jim at zope.com>
Subject: Re: [Zope3-dev] RFC: undeprecate auto-message id translation
To: Martijn Faassen <faassen at infrae.com>
Cc: zope3-dev at zope.org
Message-ID: <43959700.6030203 at zope.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
I still don't like the implicit translation of message ids, but I'll bow
to the majority opinion. This really needs to be run by the ZPT and Zope
lists as well.
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.
Certainly a big advantage of this for me is that it makes clear that i18n:
tags in the ZPT *only* affect the zpt source, which is a significant
conceptual
simplification IMO. For example, it makes it clear that the i18n:domain
only
applies to template text, not to dynamically inserted text.
We need to stop thinking about Zope 3 ZPT vs Zope 2 ZPT and switch to having
one ZPT used by both. This should be a goal for the June release. I hope
someone has time to work on this.
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: 7
Date: Tue, 6 Dec 2005 08:53:34 -0500
From: Gary Poster <gary 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: <D18C8CD6-B7FF-4BCE-BDDF-A25B90039027 at zope.com>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
On Dec 6, 2005, at 8:26 AM, Benji York wrote:
> Tarek Ziadi wrote:
>> Before starting it up, I was thinking that it would be nice if the
>> whole
>> Z3 community would be using the same toolkit, and maybe, even
>> integrate
>> it into Z3 itself.
>
> I think that instead of settling one a single toolkit we should
> come up with some simple ideas for offering up server-side
> components for the client to use. That way we can easier to use
> (almost) any client-side toolkit with Zope 3.
>
>> If this sounds like a good Idea, I would like to start a Z3
>> proposal on
>> this topic, and contribute on its integration in Z3.
>
> I'm very interested in coming up with a one or more relatively
> simple server-side proposals to make Ajax stuff easier, but I think
> the Ajax stuff (and even the whole JavaScript world) is too
> immature to settle on one client-side implementation. Therefore we
> should concentrate on doing things that help most or all of the JS
> toolkits be more usable with Z3.
Agree 100% with Benji.
I have two basic bits on the server side that I want to see--and that
I want to see usable by widget code, portlet code, etc.
- I want a standard server side traversal story to address nested
page components, so that, for instance, client-side code for a widget
in a portlet can have a reliable way of addressing itself on the server.
- I want this approach to be part of--or at least not get in the way
of--a standard pattern for persisting the state of nested page
components.
I have old proposals for this, and some revisions of them on the
basis of conversations with Jim, Fred, Stephan, and Benji. I'll try
to get some bandwidth to update the proposals at least. I really
wanted to have time to test how the proposal would work within the
new widget implementation I have, but I have other priorities on my
time.
FWIW, as far as Ajax libraries, ZC has chosen mochikit so far. It
has a lot going for it.
Gary
------------------------------
Message: 8
Date: Tue, 06 Dec 2005 08:55:56 -0500
From: Jim Fulton <jim at zope.com>
Subject: Re: [Zope3-dev] RFC: Make HTTP streaming of large data
simpler
To: Paul Winkler <pw_lists at slinkp.com>
Cc: zope3-dev at zope.org
Message-ID: <4395986C.7080303 at zope.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Interesting. I wasn't aware of this in Z2. Zope 3 definately
doesn't have this. Sindnei, have you verified that this actially
works in Z2? I didn't think the Zope 2 publisher actually started
propducing output until the request was finished.
Jim
Paul Winkler wrote:
> On Mon, Dec 05, 2005 at 04:31:03PM -0200, Sidnei da Silva wrote:
>
>>There are a couple conditions that must be met for 'chunked' to work
>>with Zope 2.
>
>
> Cool. Does Z3 behave the same way?
>
>
>>1. A Content-Length header must not be set.
>>2. The request must be HTTP 1.1
>>3. You must be streaming
>>4. No 'Connection: close' header has been set during the request
>
>
> Does "be streaming" mean something that isn't covered by the
> other requirements?
> ... hmmm, (reading more code), do you mean that RESPONSE._streaming must
> be true? Aha, I see that RESPONSE.write() implicitly sets that flag.
>
>
>>If all of that is met, then it works just fine. The signal for 'end of
>>data' in chunked mode is '0\r\n\r\n', which Zope properly inserts when
>>appropriate.
>
>
> OK. Aha, I'm now looking at medusa/producers.py and I see that happens in
> chunked_producer.
>
> Thanks for the info.
>
--
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: 9
Date: Tue, 6 Dec 2005 12:01:37 -0200
From: Sidnei da Silva <sidnei at enfoldsystems.com>
Subject: Re: [Zope3-dev] RFC: Make HTTP streaming of large data
simpler
To: Jim Fulton <jim at zope.com>
Cc: Paul Winkler <pw_lists at slinkp.com>, zope3-dev at zope.org
Message-ID: <20051206140137.GQ4874 at cotia>
Content-Type: text/plain; charset=us-ascii
On Tue, Dec 06, 2005 at 08:55:56AM -0500, Jim Fulton wrote:
| Interesting. I wasn't aware of this in Z2. Zope 3 definately
| doesn't have this. Sindnei, have you verified that this actially
| works in Z2? I didn't think the Zope 2 publisher actually started
| propducing output until the request was finished.
Yes, I can confirm it works like I described. I've been using and
relying on this (where this == chunked response producing output
before the request is finished) on Enfold Desktop for a while.
--
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
------------------------------
Message: 10
Date: Tue, 06 Dec 2005 09:26:53 -0500
From: Jim Fulton <jim at zope.com>
Subject: Re: [Zope3-dev] RFC: Make HTTP streaming of large data
simpler
To: Philipp von Weitershausen <philipp at weitershausen.de>
Cc: zope3-dev at zope.org
Message-ID: <43959FAD.4020008 at zope.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Philipp von Weitershausen wrote:
> Jim Fulton wrote:
>
>>There are a number of reasons we needed IResult:
>>
>>- We want to be able to adapt existing output, especially
>> string output and we needed an interface to adapt to.
>
>
> I see. I presume this is for the reason you state below, namely to be able
to customize
> the setting of the Content Type, etc. I guess that's valid use case, but
it seems like a
> separate issue from streaming or trickling data. Maybe we should make
them separate
> interfaces: The IOutputHeaders adapter would be responsible for figuring
out output
> headers on a result object (incl. a string), the IBodyIterator adapter
would be
> responsible for streaming/trickling.
We could do it that way. I'm not conviced that it is significantly better.
Certainly, it's not enough better in my opinion to change it at this late
date.
>>- An adapter may need to affect outut headers, so IResult
>> needed to provide header data.
>
>
> Well, the view, before falling into iteration, could set response headers
itself.
Yes, it could, but we often done't want the view to be bothered with that.
>
>>- We needed iterable data for WSGI.
>
>
> I don't understand how my example of a generator view fails there. It
*does* provide
> iterable data to the publishing framework. In fact, the generator itself
is the iterable
> data.
You figured this out below.
>
>>There are two interesting use cases that would drive
>>applications to pay attention to IResult:
>>
>>A. Returning large amounts of data
>>
>>B. Dribbling data from the application, for example
>> to provide progress on a long-running application.
>>
>>For A, you want to compute that data and then leave
>>application code. You don't want to stay in the
>>application, holding application resources, like database
>>connections, while the data is being consumed. In this case,
>>you generally want to create a temporary file and return that
>>as the IResult body.
>
>
> Ah, yes, good point. So, while IResult seems to be needed for the
decoupling of
> application space and server space, I still think the interface itself is
too
> complicated. Instead of requiring this 'body' attribute which is iterable,
IResult itself
> should be iterable. I propose to change it to:
>
> class IResult(Interface):
> ...
>
> headers = Attribute('A sequence of tuples of result headers, such
as'
> '"Content-Type" and "Content-Length", etc.')
> def __iter__(self):
> """Provide the body data of the response"""
Do you really think this makes implementations any simpler?
Note that things like strings and temprary files are already iterable.
So satisfying the current interface often mearly requires setting an
attribute.
> Or, if we adopt my suggestion of separating headers from body iterators,
we'd have two
> interfaces:
>
> class IOutputHeaders(IReadMapping):
> """Provide headers for the response output"""
>
> class IBodyIterator(Interface):
> """Provide the response body in an iterable manner"""
>
> def __iter__(self):
> """Provide the body data of the response"""
>
> Implementations of IBodyIterator that would create temporary files like
you suggest could
> then easily implement __iter__ by returning
iter(file_handle_of_the_tempfile).
I don't agree that this is simpler.
>
>>BTW, your implementation also doesn't work because it doesn't
>>set the content length.
>
>
> I don't think setting content length is mandatory. It's definitely nice,
though,
> especially for the usability of the app.
Hm, I though the spec said it was required, but it look like you are right.
>
>>Unfortunately, we still aren't addressing use base B above.
>>Some more API enhancements will be needed to address that.
>>There will need to be some way to signal that the publisher
>>should not release applicatuon resources (not call
>>publication.endRequest and request.close) until after the data
>>has been streamed. In any case, this needs more thought and
>>a proposal before we attack this.
>
>
> Indeed. Also, I still haven't given up my implementation for case B, but
of course I'm not
> attached to it. My goal is to have a *simple* way of writing views that A)
stream large
> data (I guess the indirection of a temporary file masked by
IResult/IBodyIterator is
> needed here) and B) trickle data to the client.
Why does this need to be simple. I'd even argue for making it harder.
Applications that trickle data back to the client tie up valuable resources
and better have a darn good reason for doing so.
> I would presume for B) we could still also use IResult/IBodyIterator by
writing something
> like this (assuming my suggestion of making IResult objects iterable from
above):
>
> class StreamingView(BrowserView):
> implements(IBodyIterator)
>
> def __iter__(self):
> return self
>
> def next(self):
> data = self.context.getMoreDataToTrickle()
> if not data:
> raise StopIteration
> return data
>
> This would be sufficiently simple I think, but a simple generator like my
original
> suggestion or the one below would still be more straight-forward.
I don't understand this example. Are you saying that this would be
published?
or that this would be returned by something that is published?
>
>>We'll need a way to inspect the output to determine which
>>strategy is being used. An interface seems to be a good
>>way to do this.
>
>
> Yes.
>
>
>>I think that either of these use cases is advanced and
>>should be handled explcitly.
>
>
> Sure. So what would be wrong with:
>
> class TrickleView(BrowserView):
> # tell the publisher that we'll be trickling data the client slowly
> # so that all resources stay available for that period of time
> implements(IWantToStayInApplicationSpacePlease)
>
> def __call__(self):
> yield self.context.getDataToTrickle()
> yield self.context.getMoreDataToTrickle()
> yield self.context.getEvenMoreDataToTrickle()
This would require the publisher to inspect the published object
and adjust it's behavior based on the published object rather than
the result. I'd rather branch pof the result.
>
>>Yet another use case was to make pluggable the traditional
>>implicit determination of output content type and text
>>encoding. The adaptation to IResult allows this to be
>>customized.
>
>
> Like I said, this seems like a separate issue from streaming/trickling
data to the client.
It largely is. After all, the IResult framework doesn't deal with tricking
data to the client either.
My point was mainly that we need an interface to adapt to that provides the
data we need. IResult is a pretty simple interface that is easy to
implement
and provides control over both the headers and the body. I don't really
see value in separating these concerns, especially since, often, they will
be dealt with together. I especially don't see a justification to try to
deal with this issue *now* in the middle of a release.
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
------------------------------
_______________________________________________
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 9
****************************************
More information about the Zope3-dev
mailing list