Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Christian Zagrodnick
On 2008-09-01 06:58:16 +0200, Christian Theune [EMAIL PROTECTED] said:

 
 
 
 
 Hi,
 
 sorry for removing all the quotes, but I need to clarify your baseline
 question a bit.
 
 On Sun, 2008-08-31 at 23:23 +0200, Roger Ineichen wrote:
 Yes exactly, it's up to the developer how they implement something
 useful for handle ISource objects.
 =20
 If it comes to implement a widget framework is looks a little bit
 different. A widget framework can define an API which othter can use.
 ITerms in zope.app.form does that already. You can do what ever
 you need to do in such an ITerms adapter for access the ISource and
 return standard ITerm objects which the widget can handle.
 =20
 The ITrems is a standard API for handle ISource, doesn't nmatter
 how you will query or get our data form an ISource.
 
 This sounds like you want to implement something different than ITerms
 but that you see a structural similarity between what you want and what
 ITerms already do.
 
 I think this causes some confusion (and resistance by my side) right
 now.
 
 Can you try to phrase what you want to achieve and maybe not use the
 word 'ITerms' (for now)?

Right. What's the difference from the ITerms we have now? Why do I need it?

-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Christian Zagrodnick
On 2008-08-31 22:51:38 +0200, Marius Gedminas [EMAIL PROTECTED] said:

 
 
 
 
 On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
 Wait. zope.schema really shouldn't know about terms. Terms are about=20
 the user interface, hence title/token. That has really *nothing* to do=20
 with zope.schema. For searching you don't need titles or tokens. For a=20
 search *UI* you do, but that doesn't belong to zope.schema either.
 
 Are you arguing that zope.schema.Field should not have a title
 attribute?

No no no, sorry :)

I only don't see why I need titles for a source all the time. If you 
need both tied toogether (which frankly quite often is the case) 
zc.sourcefactory does the right thing (for me). If you just need to 
define a set of values you can just define the source (i.e. 
__contains__).


-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Roger Ineichen
Hi Christian

 Betreff: Re: [Zope-dev] Make simple ISource usable

[...]

  Are you arguing that zope.schema.Field should not have a title 
  attribute?
 
 No no no, sorry :)
 
 I only don't see why I need titles for a source all the time. 
 If you need both tied toogether (which frankly quite often is 
 the case) zc.sourcefactory does the right thing (for me). If 
 you just need to define a set of values you can just define 
 the source (i.e. 
 __contains__).

You've got the point zc.sourcefactory does the right thing for 
you. Do you know why?

It uses the bridge to the widget world. It offers component
from ISource to ITerms.

e.g.
class MappedTerms(object):
A terms implementation that knows how to handle a source that was 
created through a source factory.


zope.interface.implements(zope.app.form.browser.interfaces.ITerms)


This very important ITerms interface which other widget framework
can use should be a part of zope.schema and not zope.app.form

Right now only the zope.app.form offering the missing part and makes
the ISource working. I don't think every widget framework should 
depend on zope.app.form. And other framework can not reuse zc.sourcefactory
because z3c.form will never depend on zope.app.form.

Right now it's a of;
If we move ITerms from zope.app.form, then we can useit in z3c.form
and reuse all existing ISource implementations whihc offer ITerms
support within z3c.form out of the box. If this interface will stay
in zope.app.form we never can use such ITerms/ISource component.

Of corse we could remove the request as a required adapter 
discriminator from ITerms by default.

Regards
Roger Ineichen

 --
 Christian Zagrodnick · [EMAIL PROTECTED]
 gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) 
 · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 
 345 1229889 1 Zope and Plone consulting and development
 
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Roger Ineichen
Hi Christian

 Betreff: Re: [Zope-dev] Make simple ISource usable

[...]


  This sounds like you want to implement something different 
 than ITerms 
  but that you see a structural similarity between what you want and 
  what ITerms already do.
  
  I think this causes some confusion (and resistance by my 
 side) right 
  now.
  
  Can you try to phrase what you want to achieve and maybe 
 not use the 
  word 'ITerms' (for now)?
 
 Right. What's the difference from the ITerms we have now? Why 
 do I need it?

I know that you are using the zc.sourcefactory package.
Take a look at that package and you will see that this 
package can't do what it does without ITerms from
zope.app.form. If we don't move that from zope.app.form
to another location. We can never support ITerms in
z3c.form.

ITerms is the bridge from ISource to the widget world.

Regards
Roger Ineichen

 --
 Christian Zagrodnick · [EMAIL PROTECTED]
 gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) 
 · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 
 345 1229889 1 Zope and Plone consulting and development
 
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Roger Ineichen
Hi Christian

 Betreff: Re: [Zope-dev] Make simple ISource usable

[...]

  The ITrems is a standard API for handle ISource, doesn't 
 nmatter how 
  you will query or get our data form an ISource.
 
 This sounds like you want to implement something different 
 than ITerms but that you see a structural similarity between 
 what you want and what ITerms already do.
 
 I think this causes some confusion (and resistance by my 
 side) right now.
 
 Can you try to phrase what you want to achieve and maybe not 
 use the word 'ITerms' (for now)?

I don't like to implement something different then ITerms
defined in zope.app.form. I'm fine if we remove the request
as an adapter discriminator.

ITerms could adapt only the ISource as a single object.

The important thing is. zope.schema defines ITerm and 
ITitledTokenizedTerm and offers support wihthin the 
SimpleTerm for implement simple usable components
if it comes to using widgets.

A widget needs most the time a label for represent
a token and needs a HTML aware token id.

This ITerm is not a requirement for make an ISource
implementation usable. It's just one concept, but this
one is accepted and used in zope e.g. zope.app.security.

Right now ITerms defined in zope.app.form brings in
some bad dependencies to zope.app.form. e.g. in 
zope.app.security and makes it impossible to use it in 
z3c.form. 

That's all I like to solve.


My  Fazit is,
all of you agree on the ITerms pattern and you are
using that pattern within zc.sourcefactory.

Can you explain why this ITerms interface should be 
a part of a specific form framework like zope.app.form?


Regards
Roger Ienichen




 Christian
 
 --
 Christian Theune · [EMAIL PROTECTED]
 gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) 
 · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 
 345 1229889 1 Zope and Plone consulting and development
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Make simple ISource usable

2008-09-01 Thread Roger Ineichen
Hi Christian

 Betreff: Re: [Zope-dev] Make simple ISource usable
 
 On Sun, 2008-08-31 at 16:51 -0400, Marius Gedminas wrote:
  On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian 
 Zagrodnick wrote:
   Wait. zope.schema really shouldn't know about terms. 
 Terms are about 
   the user interface, hence title/token. That has really 
 *nothing* to 
   do with zope.schema. For searching you don't need titles 
 or tokens. 
   For a search *UI* you do, but that doesn't belong to 
 zope.schema either.
  
  Are you arguing that zope.schema.Field should not have a title 
  attribute?
 
 IMHO he is not. To me that idea feels like architecture astronaucy.
 However, I think we do have a couple of cases where the 
 field's title doesn't directly become the widget's title.
 
 But then again, a static title that doesn't tie the schema 
 framework to the interaction is fine by me.
 
 I guess there's some 80/20 rule at work here. Or at least 99/1.

Moving ITerms to zope.schema, even if we skip the request as 
adapter discrimintator, can offer support for your 20% or 1%.
This let us implement ITerm or title tokenized term adapter
based on a standard ITerms interface for ISource.

I'm not 100% sure, but it looks to me that if you use
zc.sourcefactory every ISource implementation from you
will 100% depend on ITerms if it comes to widgets, doesn't 
matter if you use title token term or what ever. You don't 
have to implement that part because zc.sourcefactory does 
it for you.

Can you agree that every ISource implementation based on
zc.sourcefactory depends on ITerms from zope.app.form.

Take a look at MappedTerms in zc.sourcefactory.browser.mapping.
I guess this mapping is used for any zc.resourcefactory
implementation. right?
I'm not sure because I don't use that package right now.


Regards
Roger Ineichen 

 Christian
 
 --
 Christian Theune · [EMAIL PROTECTED]
 gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) 
 · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 
 345 1229889 1 Zope and Plone consulting and development
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope Tests: 5 OK

2008-09-01 Thread Zope Tests Summarizer
Summary of messages to the zope-tests list.
Period Sun Aug 31 11:00:00 2008 UTC to Mon Sep  1 11:00:00 2008 UTC.
There were 5 messages: 5 from Zope Tests.


Tests passed OK
---

Subject: OK : Zope-2.8 Python-2.3.6 : Linux
From: Zope Tests
Date: Sun Aug 31 20:53:12 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010095.html

Subject: OK : Zope-2.9 Python-2.4.4 : Linux
From: Zope Tests
Date: Sun Aug 31 20:54:42 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010096.html

Subject: OK : Zope-2.10 Python-2.4.4 : Linux
From: Zope Tests
Date: Sun Aug 31 20:56:12 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010097.html

Subject: OK : Zope-2.11 Python-2.4.4 : Linux
From: Zope Tests
Date: Sun Aug 31 20:57:43 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010098.html

Subject: OK : Zope-trunk Python-2.4.4 : Linux
From: Zope Tests
Date: Sun Aug 31 20:59:13 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010099.html

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Philipp von Weitershausen
El 30 Aug 2008, a las 07:50 , Dieter Maurer escribió:
 Chris Withers wrote at 2008-8-29 10:25 +0100:
 Dieter Maurer wrote:
 Then, we could get rid of the {get|query}[Multi]Adapter altogether
 and consistently use I() with appropriate optional  
 parameters --
 what a simplification and homogenization :-)

 Yeah, but since when has simplification or homogenisation been a  
 goal of
 Zope 3? ;-)

 It was with the Service geddon: make Service and Utility  
 homgogenous.

Indeed.

I've personally thought for some time that it would be quite nice if  
all you had to do was call an interface to look up a utility (which is  
sort of a multi-adapter of order 0) or to do some kind of adaption, no  
matter how many objects you wanted to adapt. E.g.:

   auth = IAuthentication() # utility
   auth = IAuthentication(default=None)
   langs = IUserPreferredLanguages(request) # adapter
   langs = IUserPreferredLanguages(request, default=None)
   view = IBrowserPage((obj, request), name='index')# named  
multi-adapter

etc.

Personally I would favour such consistency higher than the current  
behaviour, which may have been invented intentionally but still causes  
confusion once in a while.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.

2008-09-01 Thread Chris Withers
Marius Gedminas wrote:
 So either let's make zope.app.testing not depend on the whole world, 

+1

 or
 let's extract the core of zope.app.testing 

+10

 and put it somewhere else
 (zope.testing?).

-1

cheers,

Chris

-- 
Simplistix - Content Management, Zope  Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Chris Withers
Philipp von Weitershausen wrote:
 I've personally thought for some time that it would be quite nice if  
 all you had to do was call an interface to look up a utility (which is  
 sort of a multi-adapter of order 0) or to do some kind of adaption, no  
 matter how many objects you wanted to adapt. E.g.:

+sys.maxint. This is nice.

auth = IAuthentication() # utility
auth = IAuthentication(default=None)
langs = IUserPreferredLanguages(request) # adapter
langs = IUserPreferredLanguages(request, default=None)
view = IBrowserPage((obj, request), name='index')# named  
 multi-adapter

Right, but how do you differentiate adapting a tuple to IBrowserPage 
versus adapting obj and request together to IBrowserPage?

cheers,

Chris

-- 
Simplistix - Content Management, Zope  Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Philipp von Weitershausen
El 1 Sep 2008, a las 17:23 , Chris Withers escribió:
 Philipp von Weitershausen wrote:
 I've personally thought for some time that it would be quite nice  
 if  all you had to do was call an interface to look up a utility  
 (which is  sort of a multi-adapter of order 0) or to do some kind  
 of adaption, no  matter how many objects you wanted to adapt. E.g.:

 +sys.maxint. This is nice.

   auth = IAuthentication() # utility
   auth = IAuthentication(default=None)
   langs = IUserPreferredLanguages(request) # adapter
   langs = IUserPreferredLanguages(request, default=None)
   view = IBrowserPage((obj, request), name='index')# named   
 multi-adapter

 Right, but how do you differentiate adapting a tuple to IBrowserPage  
 versus adapting obj and request together to IBrowserPage?

You don't, I guess. I'd say that multi-adaption is *defined* as the  
adaption of a tuple.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Increasing the Zope Security [EMAIL PROTECTED]

2008-09-01 Thread Andreas Jung

Hi there,

I just submitted a possible security related Zope issue on Launchpad and
noticed that the bug has been assigned to the Zope Security Team which 
consists only of Jim. I suggest that a number of competent developers
of the Zope 2 and Zope 3 world volunteer to join the team in order to make 
sense to the Zope Security team.


Andreas

--
ZOPYX Ltd.  Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK

E-Publishing, Python, Zope  Plone development, Consulting


pgpQYCuQcW5L0.pgp
Description: PGP signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Dieter Maurer
Philipp von Weitershausen wrote at 2008-9-1 14:07 +0200:
 ...
I've personally thought for some time that it would be quite nice if  
all you had to do was call an interface to look up a utility (which is  
sort of a multi-adapter of order 0) or to do some kind of adaption, no  
matter how many objects you wanted to adapt. E.g.:

   auth = IAuthentication() # utility
   auth = IAuthentication(default=None)
   langs = IUserPreferredLanguages(request) # adapter
   langs = IUserPreferredLanguages(request, default=None)
   view = IBrowserPage((obj, request), name='index')# named  
multi-adapter

etc.

Personally I would favour such consistency higher than the current  
behaviour, which may have been invented intentionally but still causes  
confusion once in a while.

I am with you in this respect (as you probably already knew) :-)



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Dieter Maurer
Chris Withers wrote at 2008-9-1 16:23 +0100:
 ...
auth = IAuthentication() # utility
auth = IAuthentication(default=None)
langs = IUserPreferredLanguages(request) # adapter
langs = IUserPreferredLanguages(request, default=None)
view = IBrowserPage((obj, request), name='index')# named  
 multi-adapter

Right, but how do you differentiate adapting a tuple to IBrowserPage 
versus adapting obj and request together to IBrowserPage?

One way would be to use *objs in the Interface.__call__ signature.
Then, multi-adaptation could be I(obj1, obj2, ...) and
tuple adaptation I((obj1, obj2, ...)).
Of course, all other parameters would need to be keyword parameters
(a good thing).

Do you have a serious use case for tuple adaptation?



-- 
Dieter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Increasing the Zope Security [EMAIL PROTECTED]

2008-09-01 Thread Sidnei da Silva
It's not possible to join the team:


Restricted Team: New members can only be added by one of the team's
administrators.


On Mon, Sep 1, 2008 at 2:06 PM, Andreas Jung [EMAIL PROTECTED] wrote:
 Hi there,

 I just submitted a possible security related Zope issue on Launchpad and
 noticed that the bug has been assigned to the Zope Security Team which
 consists only of Jim. I suggest that a number of competent developers
 of the Zope 2 and Zope 3 world volunteer to join the team in order to make
 sense to the Zope Security team.

 Andreas

 --
 ZOPYX Ltd.  Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
 Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
 
 E-Publishing, Python, Zope  Plone development, Consulting

 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )





-- 
Sidnei da Silva
Enfold Systems http://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results

2008-09-01 Thread Philipp von Weitershausen
El 1 Sep 2008, a las 19:26 , Dieter Maurer escribió:
 Chris Withers wrote at 2008-9-1 16:23 +0100:
 ...
   auth = IAuthentication() # utility
   auth = IAuthentication(default=None)
   langs = IUserPreferredLanguages(request) # adapter
   langs = IUserPreferredLanguages(request, default=None)
   view = IBrowserPage((obj, request), name='index')# named
 multi-adapter

 Right, but how do you differentiate adapting a tuple to IBrowserPage
 versus adapting obj and request together to IBrowserPage?

 One way would be to use *objs in the Interface.__call__ signature.
 Then, multi-adaptation could be I(obj1, obj2, ...) and
 tuple adaptation I((obj1, obj2, ...)).
 Of course, all other parameters would need to be keyword parameters
 (a good thing).

 Do you have a serious use case for tuple adaptation?

IIRC, the twisted guys do.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )