Hello everyone,
I have a question about how to get raw data sent by a flash
application in Zope (a zope method/function).
The flash application uses the method in the link below to send to the
server an image (jpg):
Try REQUEST.BODYFILE
On 25.11.2009, at 12:30, Dragos Chirila wrote:
The question is: how can I get this data on the server side in Zope?
Becasue:
- REQUEST.form is empty
- HTTP_RAW_POST_DATA is missing
- there is no other key or value in the REQUEST to indicate the value
I am looking
Doesn't work: AttributeError: BODYFILE
On Wed, Nov 25, 2009 at 1:59 PM, Stefan H. Holek ste...@epy.co.at wrote:
Try REQUEST.BODYFILE
On 25.11.2009, at 12:30, Dragos Chirila wrote:
The question is: how can I get this data on the server side in Zope?
Becasue:
- REQUEST.form is empty
-
Hello Mailinglist,
we've been using ZOPE in combination with the Silva CMS for around four
years now to serve our University's homepage. And everything worked fine
so far.
A week ago we switched to a new layout (for corporate reasons) and now
we're experiencing frequent crashes of the Zope
At first, try to eliminate error outside of the Zope itself. Try to install
it all into plain whole new (and reliable!) machine. Do not use restore of
any backups!
- Original Message -
From: Andreas Krasa andreas.kr...@wu-wien.ac.at
A week ago we switched to a new layout (for
The data is actually received by Zope, but its broken into pieces.
Please find a sample of the REQUEST.form here
http://media.fourhooks.ro/request_form.jpg
Any hints on how to put the image back together?
On Wed, Nov 25, 2009 at 4:58 PM, Dragos Chirila objectval...@gmail.com wrote:
Doesn't
I am passing a variable named 'column' to the following script and
trying to fill a select box with the result of a zsqlmethod chosen
dynamically using this variable.
print select name=nonboolean method=post
command=context.column()
for row in command:
code=row.code
getattr(context, column)()?
-aj
On Wed, Nov 25, 2009 at 19:53, Garry Saddington
ga...@schoolteachers.co.ukwrote:
I am passing a variable named 'column' to the following script and
trying to fill a select box with the result of a zsqlmethod chosen
dynamically using this variable.
print
IF it's a variable passed to the script wouldn't you simply access it as
'column'?
Also, is it a variable or a function? Or is the variable the name of a function
somewhere?
If it's the former just call it: column().
If it's the latter, Andreas should be correct, getattr(context, column)() or
Jeff Peterson wrote:
IF it's a variable passed to the script wouldn't you simply access it as
'column'?
Also, is it a variable or a function? Or is the variable the name of a
function somewhere?
If it's the former just call it: column().
If it's the latter, Andreas should be correct,
Summary of messages to the zope-tests list.
Period Tue Nov 24 12:00:00 2009 UTC to Wed Nov 25 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Tue Nov 24 20:38:32 EST 2009
URL:
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer du...@qwer.tk wrote:
Ah, thanks that could be. My current version is zope.security-3.4.1 (as from
KGS-3.4.0).
The real bad thing about this is that it seems I'm stuck with that release as
trying to upgrade to zope.security-3.7.1 fails due
Hi,
I'm about to work a bit on z3c.schema2json [1]. As has been briefly
discussed before (a while ago [2]), z3c. schema2json is so similar to
z3c.schema2xml [3] in what it does and how it does it, that I wonder
about merging the two packages somehow.
One way to do this - maybe - is to use
Thomas Lotze wrote:
Stephan Richter wrote:
On Tuesday 24 November 2009, Thomas Lotze wrote:
Could somebody please give me PyPI rights for zope.browserresource? I'd
like to release a new version of it which includes the recent fixes to its
dependencies. Thank you very much.
I am in the
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document-navigation {overflow:
Benji York wrote:
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
Hi there,
Reading the thread Chris McDonough started (and ended) about modifying
the way utility registration works reminded me of the following
thinking. It's quite independent and probably even antithetical to
Chris's approach as it uses interfaces, but that's fine.
The goal is to make it
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
faas...@startifact.com wrote:
[snip good stuff]
Multiadapter:
IFoo.multi(x, y)
I'm not sure I like the following suggestion better than the above, but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
Multiadapter with default:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious use case, but what if I want to adapt
a tuple?
Matt
On Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote:
...
Thoughts?
FWIW, this mirrors some of the thoughts I've had, after a lot of discussions
with Launchpad/Canonical engineers about the pros and cons of the Zope
interface and component code. My OSCON presentation touched on some of these
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and consistent API for all components including
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I seem to remember there had been some discussion at some point about
dropping
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote:
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I seem to remember there
Gary Poster wrote:
FWIW, I'm saying that utilities and adapters are different. I share
your/Martijn's/other people's general thoughts about merging adapters and
multiadapters in the interface __call__ syntax.
There might should be more obvious APIs for just *retrieving* an adapter based
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote:
Gary Poster wrote:
FWIW, I'm saying that utilities and adapters are different. I share
your/Martijn's/other people's general thoughts about merging adapters and
multiadapters in the interface __call__ syntax.
There might should be
Chris McDonough wrote:
There might should be more obvious APIs for just *retrieving* an adapter
based
on a set of interfaces; it's useful to be able to retrieve an adapter without
invoking it. Currently this is possible via registry.adapters.loookup, which
is fine.
And I know it's
On Wed, Nov 25, 2009 at 04:30:57PM +0100, Thomas Lotze wrote:
Benji York wrote:
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
//
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benji York wrote:
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
faas...@startifact.com wrote:
[snip good stuff]
Multiadapter:
IFoo.multi(x, y)
I'm not sure I like the following suggestion better than the above, but
throwing it out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious use case,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very stupid... What's wrong with the it?
Can't we define
On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote:
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
This also doesn't allow you to use this (anti?)pattern:
class Foo:
implements(IFoo)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Sutherland wrote:
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
This also doesn't
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will short circuit, leading you into
infinite recursion. Except that it doesn't:
[snip example]
which strikes me as
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
Regards,
Martijn
Marius Gedminas mar...@gedmin.as writes:
On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote:
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but throwing it out there anyway:
Multiadapter:
Chris McDonough wrote:
If some set of ZCA APIs made it the responsibility of the *caller* to invoke
the adapter with arguments would go a long way between normalizing the
difference between utilities and adapters (because they would essentially
then
be the same thing).
The very core
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote:
Chris McDonough wrote:
If some set of ZCA APIs made it the responsibility of the *caller* to
invoke the adapter with arguments would go a long way between normalizing
the difference between utilities and adapters (because they would
Hi all
Betreff: Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure
*why* it must be ruled out.
Am 25.11.2009 um 15:49 schrieb Chris Withers:
[...]
Yes, PyPI is broken if you're an admin of many packages, feel free to
me too on this issue:
http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503
It's fixed since yesterday.
Yours sincerely,
--
Michael Howitz ·
Michael Howitz wrote:
Am 25.11.2009 um 15:49 schrieb Chris Withers:
[...]
Yes, PyPI is broken if you're an admin of many packages, feel free to
me too on this issue:
http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503
It's fixed since yesterday.
Well, by some
45 matches
Mail list logo
