date:20050829


Garrett Smith wrote:

I'd like to create a proxy where __slots__ is determined (or appended to) when 
the proxy is constructed. E.g.



foo = Foo()
bar = SomeProxy(foo, 'baz')
bar.baz = 123
hasattr(foo, 'baz')


False


hasattr(bar, 'baz')


True

Is it possible to do this?


No, at least not using the standard __slot__ mechanism.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Florent's O-R blog entry



On Aug 27, 2005, at 6:08 AM, Wichert Akkerman wrote:


Previously Gary Poster wrote:


We have at least three maintained and capable ZODB backends,  with
different strengths and weaknesses, appropriate for different  use
cases.  Lets not jump to discard any of them.



With current filesystem developments it might be interesting to try
and use more filesystem capabilities in backends. Storing metadata
in extended attributes would be interesting for example. There is
always room for some experiments :)


Yes, and thank you for letting me agree with you. :-)

I'm not asserting that ZODB BTrees are the answer to world hunger; or  
that O/R mapping is evil and must be destroyed; or that we shouldn't  
experiment to find better solutions to our real problems.  My points  
are intended to be most pertinent to core design decisions for Zope  
community projects, given the current state of the Zope world.


In regards to your example idea, I agree that it might be an  
interesting approach to explore in ZODB backends.  I bet Ape would be  
the easiest way to begin experimenting with it.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:
...


What problem perspectives solves?
--


I think I'm ready to respond to this now. I hope, with your current
thinking that this is still relevent.


local portlets are currently stored in local folders in a .cps_portlets
container with the name of the slot in which they are located.


So, .cps_portlets is a container with an item for each slot, which, is,
itself a container?  Then users add items to this container to add portlets?


It means that the user has to go into a given folder, add a portlet into
a slot and the portlet will be visible starting from this folder. After
a while there are 100 of portlets scattered around the entire site, some
in /sections/A, some in /sections/A/B some in / ...

there is no grouping of portlets.

we find out that what users actually want to do is to define a set of
portlets that will be shown in a given section of the site (eg. in
'education', in 'research', ...) and only there.


Meaning not in subfolders?

 This is somehow done

when portlets are stored in folders, but it is very difficult to group
the portlets together, because there is no notion of group of portlets
displayed in given context.


I don't know what you mean by grouping portlets, or why it is a good thing.


so basically the notion of perspective is just a way of grouping
portlets together and give a name to that collection, so that a user can
decide: when I'm in this section of the site, I want to show this set of
portlets.


This doesn't seem consistent with your current notion of perspectives.


In an application, this makes it possible to keep the portlets used by
the application (action portlets, navigation portlets) separate from
decoration portlets.


I'n not sure what you mean.  By application, do you mean the content
management application, as opposed to the end-user content-delivery
application?


currently we manage the separation by using different themes (one for
the external site, and one for the back office), the slots names are
different, so the portlets in the backoffice on not visible on the
external site.


And how is this solution undersireable?


Also we have problem when a same slot is present in many pages, the
users think that they are add portlets only on a given page, while they
end up also being visible in other pages.


I'm not sure what you mean by page here.  Do you mean theme/master pages
or web pages?

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:
...

Concerning unification:
During the sprint in Göteborg in June  according to what Tres mentionned
it appeared to me said that the issue was to make portlets independent
of any macro mechanism, and that the they should be treated as page
fragments without any assumption about where on the page or inside which
template they'll be displayed.


I would agree that, generally, page fragment will/should generally
be designed independently.  We certainly have use cases for being
able to explicitly assember page fragments to create pages.  This is
typically for the content well.  To be more accurate, we often
compose pages by assembling views of content such that the views are
designed to be page fragments.


the idea was to chop the page into pieces and reuse the pieces.

the rendering engine in cpsskins is designed to do layouting/styling of
the O wrap area in the way that *web designers* are used to work with.


Yup.


By using perspectives end-users can also use the portlet editor to
move portlets on the canvas (as in the google news portal),


By end-users, do you mean content managers? Or end-users of the
content?

Why do they need perspectives to do this?

Do you envision them being able to control the order of
the portlets?

 all that is

needed is a portal page with three slots in it


Why is the number of slots important?

...


This is what I meant with having a unifying concept. And that sounds
very unifying to me already.


Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
are simple separate applications.  They are different ways of working on content
based on tasks.  They could be provided with perspectives, or, more simply,
with different collections of web pages, using different styles.  I
don't understand the benefit you think they provide nor do I see how
they unify anything.


But when it comes to the content well, I strongly think that the
layouting is best delegated to other rendering engines, XForms, for
instance (Julien could tell you more about it), iCal renderers, Flash
plugins, etc.. Otherwise you will lose the generic aspect of cpsskins,
and the layout engine will become extremely complicated to manage. I
think that the content well should in that case be *one* portlet that
knows how to do its own layouting and not be a mixture of portlets.


I think we are in agreement here. :)


rendering a weekly calendar view would otherwise be a real pain if the
meetings booked were portlets...

In CPSSkins for Zope2 for instance it is still CPSDocument that creates
the layout of documents and it is best done that way I think.


Yup.


have a nice week-end!


Thanks. I did. :)

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

 What problem perspectives solves?
 --


 I think I'm ready to respond to this now. I hope, with your current
 thinking that this is still relevent.

good :-)

 local portlets are currently stored in local folders in a .cps_portlets
 container with the name of the slot in which they are located.


 So, .cps_portlets is a container with an item for each slot, which, is,
 itself a container?  Then users add items to this container to add
 portlets?

that's the Zope2 implementation of local portlets. It has advantages:

- the role for managing portlets is the same as the role for managing
content in a folder
- portlets are visible starting from the folder in which they are stored
physically.

the drawbacks:

- portlets get scattered all over the site, there is no unity.
- it is not possible to create a portlet set without first creating the
folder in which they'll reside
- users must have permission to write in the container to add folders,
hence they must have access to the folder
- difficult import / export
- a traversal is needed from the current folder to the root of the site
to determine which portlets will be displayed
- portlet ordering is a pain since there is no unique set of portlet.


 It means that the user has to go into a given folder, add a portlet into
 a slot and the portlet will be visible starting from this folder. After
 a while there are 100 of portlets scattered around the entire site, some
 in /sections/A, some in /sections/A/B some in / ...

 there is no grouping of portlets.

 we find out that what users actually want to do is to define a set of
 portlets that will be shown in a given section of the site (eg. in
 'education', in 'research', ...) and only there.


 Meaning not in subfolders?


probably in subfolders too, depending on where the perspective will be
used (most certainly starting from a given section of a site, until it
is overridden by another perspective) -- this is a separate issue
though, since a perspective is not tied to a given folder, object type
when it is defined..


  This is somehow done

 when portlets are stored in folders, but it is very difficult to group
 the portlets together, because there is no notion of group of portlets
 displayed in given context.


 I don't know what you mean by grouping portlets, or why it is a good
 thing.

I mean creating sets of portlets: the set of portlets used in a blog, in
a calendar, in a section of a site and being able to treat them as a
group. This is for the same reason that user folders have groups of users.

 so basically the notion of perspective is just a way of grouping
 portlets together and give a name to that collection, so that a user can
 decide: when I'm in this section of the site, I want to show this set of
 portlets.


 This doesn't seem consistent with your current notion of perspectives.


in what sense? again there are two separate notions:
- the notion of perspective
- the notion of applying a given perspective to a given context.


 In an application, this makes it possible to keep the portlets used by
 the application (action portlets, navigation portlets) separate from
 decoration portlets.


 I'n not sure what you mean.  By application, do you mean the content
 management application, as opposed to the end-user content-delivery
 application?

I mean a webmail application, a calendar application, a web publishing
application.
Currently the portlets used in a CMF site for instance are of two kinds:
1) portlets that are used by the web publishing application (workflow
actions), login link...
2) portlets that show content (latest news, info text, ...)

the site visitors are usually not interested in 1)

 currently we manage the separation by using different themes (one for
 the external site, and one for the back office), the slots names are
 different, so the portlets in the backoffice on not visible on the
 external site.


 And how is this solution undersireable?


these portlets are associated to different activities and they are
usually meant to be seen by different target audiences.


 Also we have problem when a same slot is present in many pages, the
 users think that they are add portlets only on a given page, while they
 end up also being visible in other pages.


 I'm not sure what you mean by page here.  Do you mean theme/master pages
 or web pages?

 Jim

this is a minor problem actually and I've changed my mind on this issue
since last week, I think that slots should be identified by their name
that can be shared between slots located on different pages and not by
an id that is unique per slot, to make it possible for an application
designer to specify the slot in which portlets should be shown ('left',
'right', ...) as it is done with CMFDefault.

I have written a doctest that explains this:

RE: [Zope3-dev] Proxy and slots

2005-08-29 Thread Garrett Smith

I ended up using 'type' to create a new proxy with a dynamically created 
__slots__. I haven't run into any weirdness with that approach, so far :)

 -- Garrett

 -Original Message-
 From: Jim Fulton [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 29, 2005 9:03 AM
 To: Garrett Smith
 Cc: 'zope3-dev@zope.org'
 Subject: Re: [Zope3-dev] Proxy and __slots__

 Garrett Smith wrote:
  I'd like to create a proxy where __slots__ is determined 
 (or appended to) when the proxy is constructed. E.g.

 foo = Foo()
 bar = SomeProxy(foo, 'baz')
 bar.baz = 123
 hasattr(foo, 'baz')

  False

 hasattr(bar, 'baz')

  True

  Is it possible to do this?

 No, at least not using the standard __slot__ mechanism.

 Jim

 -- 
 Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
 CTO  (540) 361-1714http://www.python.org
 Zope Corporation http://www.zope.com   http://www.zope.org

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Makefile and python version number

2005-08-29 Thread Julien Anguenot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

http://svn.zope.org/Zope3/trunk/Makefile?rev=37919r1=37889r2=37919

The reason is not explained within the logs ??

The problem is when you have the following installed :

python-2.3.5
python-2.4.1 as the default Python version on the system.

When you're running make everything's fine except that it will use the
python.2.4.1 and if you're running the ./z3.py or ./test.py then it
doesn't work with the following error :

Traceback (most recent call last):
  File ./z3.py, line 63, in ?
run()
  File ./z3.py, line 58, in run
from zope.app.server.main import main
  File /home/zopes/Zope-3.2/src/zope/app/server/main.py, line 25, in ?
import ZODB.interfaces
  File /home/zopes/Zope-3.2/src/ZODB/__init__.py, line 21, in ?
from persistent import TimeStamp
  File /home/zopes/Zope-3.2/src/persistent/__init__.py, line 19, in ?
from cPersistence import Persistent, GHOST, UPTODATE, CHANGED, STICKY
ImportError: /home/zopes/Zope-3.2/src/persistent/cPersistence.so:
undefined symbol: PyUnicodeUCS4_AsEncodedString

I think this changeset made the problem appear :
http://svn.zope.org/Zope3/trunk/Makefile?rev=38056r1=37919r2=38056

with

- --install-dir


Should we add back the Python version number within the Makefile (it
solves the problem) ?

J.
- --
Julien Anguenot | Nuxeo RD (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDEy8AGhoG8MxZ/pIRAsyuAJ9MG2fD/fObM+EjFKSKfDzLgf8hMwCcCzLl
exyTsnI30EvrWPG6zB24dfo=
=pCbH
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

 By using perspectives end-users can also use the portlet editor to
 move portlets on the canvas (as in the google news portal),


 By end-users, do you mean content managers? Or end-users of the
 content?

 Why do they need perspectives to do this?

 Do you envision them being able to control the order of
 the portlets?


Yes, I think that Rob mentionned that there was such a use case where
you had customers who wanted to control the way portlets were disposed
on the screen on an individual basis.

Generally speaking, portlets are associated to slots but the ordering
information is neither stored in the portlet itself nor in the slot, but
in a display element. There are as many display elements associated to
a given slot as there are perspectives.

In this way visual ordering is not a problem, and it should also be
possible to place the portlets inside the slot's display canvas on using
(x, y) coordinates. I don't know about a use case for this unless maybe
in the content well, I think you mentionned something about this in a
previous mail?


  all that is

 needed is a portal page with three slots in it


 Why is the number of slots important?

 ...


It's not --- it was an example, it is the number of slots used in
google's news portal ...


 This is what I meant with having a unifying concept. And that sounds
 very unifying to me already.


 Perspectives, if I understand how you are describing them, and how
 Eclipse describes them,
 http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,

 are simple separate applications.  They are different ways of working
 on content
 based on tasks.  They could be provided with perspectives, or, more
 simply,
 with different collections of web pages, using different styles.  I
 don't understand the benefit you think they provide nor do I see how
 they unify anything.


I'm going to put a diagram online showing what they add in terms of
separating responsability in the design of a web application, web sites, ...

The idea is that the three roles:
- theme designer (creates themes, styles, etc...)
- programmer (creates portlets, special views for some object types, ...)
- application / UI designer (puts all the pieces together)

are completely orthogonal.

With this you can ask a group of graphic designers to work on some
graphic designer for an application, or a site. They'll be able to work
on their own without interfering with programmers. They'll create a
couple of master pages, they'll place slots inside the pages. This is
where their responsibility ends.
 
simultaneously you can ask a group of programmers to create portlets
(page fragments) that define the functionality of the site / application.

then the application designers, UI designers, website content creators
are able to put everything together be creating perspectives. They'll be
able to do this before the site with all its content (folder, etc...)
even exists.

Bottom line: there is a very clear separation of roles. You can't do
this today, because the roles are too intertwined.


/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: Florent's O-R blog entry

2005-08-29 Thread Florent Guillaume


Hi folks,

I've just returned from vacation, I'll read your numerous emails and  
try to provided detailed answers ASAP :)


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

 This is what I meant with having a unifying concept. And that sounds
 very unifying to me already.


 Perspectives, if I understand how you are describing them, and how
 Eclipse describes them,
 http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,

 are simple separate applications.  They are different ways of working
 on content
 based on tasks.  They could be provided with perspectives, or, more
 simply,
 with different collections of web pages, using different styles.  I
 don't understand the benefit you think they provide nor do I see how
 they unify anything.


I've read the article, it is clear to me that the main idea is to be
able to reuse components, not to create a collection of web pages just
to present an application from a slightly different perspective. With 3
master pages and a set of 5 perspectives you get 15 combinations. That
would be 15 pages in html to maintain.

The main idea is to define visibility in a coherent way, not with a
series of CSS hacks (hidden {display:none}), div
tal:condition=not:first_login .../div, img tal:condition=python:
current_path.startswith('/section/news'), scattered around 100 page
templates... or by using visibility conditions in the portlets own code.

the assumption is that portlet visibility is not a propriety of
*individual* portlets, but this is something that is related to some
activity of the user, or some usage context.

I think that Eric summarized this quite clearly in his blog:


What for ?

Imagine that when writing a new component, you also can easily define
perspective. Let's take an example : a blog application. Well you can
define a Blog Perspective that would be activated when accessing to a
blog and that would arrange the portal to offer a blog view putting
portlets in right places. WIth this and the whole CPSSkins machinery, it
would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative
work, personal portal dashboard, etc. The application would then only
define portlets and perspectives (no more pages, view, whatever :-).
From the user point of view, it would really improve the usability and
how it the portal can adapt itself to his need. The user would also be
albe to define its own perspectives (like it's dashboard) and switch
between them.

It would be new approach in the design of web applications, that would
allow to think them as user-oriented applications and not as a chains of
html pages.



The idea is to move away from the website approach to designing web
applications, with the endless poliferation of templates and macros. I
fully agree though that this is a change from the page / view approach.

/JM


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Makefile and python version number

2005-08-29 Thread Julien Anguenot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok I just changed the version number to correct the problem.

I'll try to read the previous discussions you mentionned below.

Cheers,

J.

Fred Drake wrote:
 On 8/29/05, Julien Anguenot [EMAIL PROTECTED] wrote:
 
http://svn.zope.org/Zope3/trunk/Makefile?rev=37919r1=37889r2=37919

The reason is not explained within the logs ??
 
 
 That particular change was because I'd managed to add the version
 number back accidentally; it had previously been removed (I think by
 Stephan Richter).
 
 
The problem is when you have the following installed :
 
 ...
 
I think this changeset made the problem appear :
http://svn.zope.org/Zope3/trunk/Makefile?rev=38056r1=37919r2=38056
 
 
 I'm skeptical of that, though.
 
 Regardless of the revision that caused the problem, the problem
 specifically is that there's more than one place where the Python
 executable is named.  Ideally, there should be only one place, but
 that doesn't work well with the sh-bang lines in Unix scripts.  :-(
 
 The right way to spell the name of the Python executable has been
 discussed extensively at various times, and its not clear to me that
 we've ever reached a real conclusion.  There are actually two issues:
 
 1.  How should we spell the Python executable in a checkout?
 
 2.  How should we spell the Python executable in an installation?
 
 The ideal way to do the later is likely platform specific (Windows
 v. Unix again; I don't know if Mac OS X really introduces a third
 variant or not).
 
 The specific case you cite is checkout-specific, however, so platform
 is irrelevant; you get what's in the checkout.
 
 The version number was initially added to the spelling of the Python
 executable to ensure that the right version was selected; this was
 done before Python 2.4 was available.  At this point, there are more
 acceptable versions (2.3.5 and 2.4.x), and it's even common for
 python2.3 not to be installed by default (which I suspect was why the
 Makefile was modified).  Python 2.3 certainly wasn't installed on my
 Ubuntu system until I added a local installation fairly recently.
 
 What the right thing is needs to be considered again.  Changing the
 Makefile back to specify python2.3 is acceptable, I think, because we
 do still require compatibility with Python 2.3.5.  It's not ideal, but
 we're not likely to agree on what's ideal for a checkout anyway, even
 for Unix users.
 
 
   -Fred
 


- --
Julien Anguenot | Nuxeo RD (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDE0HRGhoG8MxZ/pIRAiAIAJ43qVeOGd6X/ilTHK9vWAbEGopIKACfZKQg
FCGURptgYtgWNQ3QqzGDGjU=
=IZW3
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:
...



By using perspectives end-users can also use the portlet editor to
move portlets on the canvas (as in the google news portal),



By end-users, do you mean content managers? Or end-users of the
content?

Why do they need perspectives to do this?

Do you envision them being able to control the order of
the portlets?




Yes, I think that Rob mentionned that there was such a use case where
you had customers who wanted to control the way portlets were disposed
on the screen on an individual basis.


This gets to a terminology problem.  JSR 168 defines portlets to
mean something quite different. In particular, JSR 168 specifies
portlets that are used by end users, by which I mean the final users,
as opposed to content managers, of a site to control what they
personally see on a site. This is what Rob was refering to.
(BTW, we would prefer that the term portlet be used to talk
about portlets as defined by JSR 168.)

Your local portlets are used by content managers to define
content to appear in the o-wrap, based on site location.


Generally speaking, portlets are associated to slots but the ordering
information is neither stored in the portlet itself nor in the slot, but
in a display element. There are as many display elements associated to
a given slot as there are perspectives.


You still seem to have the desire have portlet assignment apply to a
a folder and to subfolders, with subfolders being able to add
portlet definitions.  As you pointed out in another note, this makes
order control challenging.

You introduce new term display element, but you don't say enough
about what it does.  I'm happy to let that pass. ;)


In this way visual ordering is not a problem, and it should also be
possible to place the portlets inside the slot's display canvas on using
(x, y) coordinates. I don't know about a use case for this unless maybe
in the content well, I think you mentionned something about this in a
previous mail?


I also mentioned that there are several distinct activities that I
think should remain distinct.  In particular, and I think you agreed,
the system we are discussing here should not try to address the content
well.

...

This is what I meant with having a unifying concept. And that sounds
very unifying to me already.



Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,

are simple separate applications.  They are different ways of working
on content
based on tasks.  They could be provided with perspectives, or, more
simply,
with different collections of web pages, using different styles.  I
don't understand the benefit you think they provide nor do I see how
they unify anything.




I'm going to put a diagram online showing what they add in terms of
separating responsability in the design of a web application, web sites, ...

The idea is that the three roles:
- theme designer (creates themes, styles, etc...)
- programmer (creates portlets, special views for some object types, ...)
- application / UI designer (puts all the pieces together)

are completely orthogonal.

With this you can ask a group of graphic designers to work on some
graphic designer for an application, or a site. They'll be able to work
on their own without interfering with programmers. They'll create a
couple of master pages, they'll place slots inside the pages. This is
where their responsibility ends.
 
simultaneously you can ask a group of programmers to create portlets

(page fragments) that define the functionality of the site / application.

then the application designers, UI designers, website content creators
are able to put everything together be creating perspectives. They'll be
able to do this before the site with all its content (folder, etc...)
even exists.

Bottom line: there is a very clear separation of roles. You can't do
this today, because the roles are too intertwined.


I just don't see perspectives adding anything here.  The application
designer can just as easily use different master pages for different
activities/tasks and assigne different portlets to different slots
in the different master pages.

I see some negatives with perspectives:

- They introduce a need for some complex infrastructure.

- It's not clear what impact they have on URLs.  If, for
  example, perspectives are set via cookies or session
  data, then both bookmarking and caching become more complicated.

- By introducing modes, I worry that they will make it
  harder to talk about and teach systems build with them.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:
...



This is what I meant with having a unifying concept. And that sounds
very unifying to me already.



Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,

are simple separate applications.  They are different ways of working
on content
based on tasks.  They could be provided with perspectives, or, more
simply,
with different collections of web pages, using different styles.  I
don't understand the benefit you think they provide nor do I see how
they unify anything.




I've read the article, it is clear to me that the main idea is to be
able to reuse components, not to create a collection of web pages just
to present an application from a slightly different perspective.


OK, then we have very different perspectives on perspectives.
I see eclipse perspectives as primarily a way to tailor the UI
to the task at hand, which, BTW, I don't see as simply
persenting an application from slightly different perspectives.


 With 3

master pages and a set of 5 perspectives you get 15 combinations. That
would be 15 pages in html to maintain.


Perhaps, although it's not clear to me that separate perspectives
would want to share the same master pages.  To be honest, it's
not clear to me that different applications would/should want to mess
with the o-wrap in the first place.


The main idea is to define visibility in a coherent way,


We're both in favor of that.



not with a
series of CSS hacks (hidden {display:none}), div
tal:condition=not:first_login .../div, img tal:condition=python:
current_path.startswith('/section/news'), scattered around 100 page
templates... or by using visibility conditions in the portlets own code.


I wasn't suggesting that. I was suggesting a model where separate
applications didn't share the same layout for parts that were
application specific.


the assumption is that portlet visibility is not a propriety of
*individual* portlets, but this is something that is related to some
activity of the user, or some usage context.


This implicit assignment of portlets to slots worries my, both from
the point of implementation complexity and understandability.


I think that Eric summarized this quite clearly in his blog:


What for ?

Imagine that when writing a new component, you also can easily define
perspective. Let's take an example : a blog application. Well you can
define a Blog Perspective that would be activated when accessing to a
blog and that would arrange the portal to offer a blog view putting
portlets in right places. WIth this and the whole CPSSkins machinery, it
would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative
work, personal portal dashboard, etc. The application would then only
define portlets and perspectives (no more pages, view, whatever :-).

From the user point of view, it would really improve the usability and

how it the portal can adapt itself to his need. The user would also be
albe to define its own perspectives (like it's dashboard) and switch
between them.

It would be new approach in the design of web applications, that would
allow to think them as user-oriented applications and not as a chains of
html pages.



The idea is to move away from the website approach to designing web
applications, with the endless poliferation of templates and macros. I
fully agree though that this is a change from the page / vi


You seem to allow only two choices: perspectives and very low-level
HTML/CSS/ZPT.  We're all in favor of page composition that allows
pages to be assembles in various ways by various users.  I'm having
a hard time buying the benefits of the approach you are suggesting
over other high-level approaches.

Here's what I think you are proposing:

- Different components should appear in the o-wrap of a page
  depending on the task being performed.

- The control of the portlets displayed in the o-wrap
  should be controlled by a mode called a perspective.

I think this could be a good approach for some applications.

I'm not convinced that varying the o-wrap by task is a
good idea for all or even most sites.  If I did want to do
that, I might prefer to do so by actually using different
o-wraps (master pages) for different tasks.

Don't get me wrong, I think the perspectives idea has a lot
of merit.  I want it to be optional though.

I'll summarize my thoughts in a response to your original
posting.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:



 Yes, I think that Rob mentionned that there was such a use case where
 you had customers who wanted to control the way portlets were disposed
 on the screen on an individual basis.


 This gets to a terminology problem.  JSR 168 defines portlets to
 mean something quite different. In particular, JSR 168 specifies
 portlets that are used by end users, by which I mean the final users,
 as opposed to content managers, of a site to control what they
 personally see on a site. This is what Rob was refering to.
 (BTW, we would prefer that the term portlet be used to talk
 about portlets as defined by JSR 168.)

 Your local portlets are used by content managers to define
 content to appear in the o-wrap, based on site location.


no, they are used by end-users as well -- this is already the case in
the Zope2 version of cpsskins -- inside the perspective that they have
permission to work in.

this is where I don't understand how you can with a view / adapter /
page template paradigm get the JSR 168 portlets to fit in. Views,
adapters are for programmers, not for end-users, not even for content
creators.


 Generally speaking, portlets are associated to slots but the ordering
 information is neither stored in the portlet itself nor in the slot, but
 in a display element. There are as many display elements associated to
 a given slot as there are perspectives.


 You still seem to have the desire have portlet assignment apply to a
 a folder and to subfolders, with subfolders being able to add
 portlet definitions.  As you pointed out in another note, this makes
 order control challenging.

 You introduce new term display element, but you don't say enough
 about what it does.  I'm happy to let that pass. ;)


this is the required element that makes portlets ordering not
challenging anymore. But this is another issue..


 In this way visual ordering is not a problem, and it should also be
 possible to place the portlets inside the slot's display canvas on using
 (x, y) coordinates. I don't know about a use case for this unless maybe
 in the content well, I think you mentionned something about this in a
 previous mail?


 I also mentioned that there are several distinct activities that I
 think should remain distinct.  In particular, and I think you agreed,
 the system we are discussing here should not try to address the content
 well.


it depends on what the content well looks likes, if the content well
consists of 6 portlets, side by side or one below the other, then this
is not a problem to let the cpsskins layout mechanism take care of that.
I'm still not sure about what you put inside the content well, this is why.

if the content well contains a document with some advanced layout and a
lot of widgets then this is outside the scope of the cpsskins layout
renderer.


 Bottom line: there is a very clear separation of roles. You can't do
 this today, because the roles are too intertwined.


 I just don't see perspectives adding anything here.  The application
 designer can just as easily use different master pages for different
 activities/tasks and assigne different portlets to different slots
 in the different master pages.


this is what we do already.. but this is clumsy. Because it forces us to
design a new page just for some portlets that should be hidden.
Maintaining a page, with the styles, layouts, etc takes more time than
maintaining a perspective that only consists of a list of portlets
assigned to some slots.

 I see some negatives with perspectives:

 - They introduce a need for some complex infrastructure.

what do you mean by complex? have you seen the prototype? for a user
it does not seem too complex:

- choose a perspective
- add portlets to it
- assign the perspective to some context

 - It's not clear what impact they have on URLs.  If, for
   example, perspectives are set via cookies or session
   data, then both bookmarking and caching become more complicated.

what about skins?

 - By introducing modes, I worry that they will make it
   harder to talk about and teach systems build with them.

 Jim

what should we say about skins then? they introduce exactly the same
problems. However they exist in Zope3.

a perspective is a skin but for the portlets in a page. If you think
that perspectives are too complex then the skins mechanism should be
reconsidered...

/JM



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

We'll be doing some work on the widget/schema code at the Rivah  
sprint, Thursday and Friday this week.  This email identifies the  
possible tasks, and proposes the actual choice of work (short answer:  
potentially all but the biggest, and last, 2).  Interested parties  
are invited to comment and suggest, whether or not you plan to be at  
the Rivah sprint.


Some of the ideas below would require proposals before the sprint.   
If I get positive feedback to them on the mailing list, I'd try to  
have small proposals tomorrow so that we could get official consensus  
by time the sprint starts Thursday.  Ones that I think need a  
proposal are marked with *would need proposal*.  I only want to write  
each of these if I believe it's likely I have consensus, so please  
tell me now if you are concerned. :-)


Many of the ideas below have code that Zope Corp already has waiting,  
which need a little bit of TLC to be put in the core.  These are  
marked with *code exists*


Possible topics

1 Flesh out the 'source' design and implementation so it can replace  
and deprecate vocabularies.  Specifically, to match the capabilities  
of vocabularies, we'll add an interface that a source can implement  
if they want to be bound to a context; and we will make it possible  
to have iterable sources (for small collections as would be  
appropriate for selections, radio button groups, checkbox groups,  
etc.).  This will reduce the potential for confusion by letting  
sources be the 'one true way' to describe possible options for a  
choice, instead of the current overlap of vocabularies and sources.   
The primary advantage to sources over vocabularies are that the model  
is cleaner; the only additional feature is the ability to configure  
different tokens for a given source.


2 Clean up the exceptions widget framework.  The use of the widget  
input error is quite messy: see collector issue 273.  The idea would  
be to make the use of the errors argument more consistent and more  
restricted, and make the 'doc' implementation simpler.


3 Make the arbitrary constraints in the schema framework more  
powerful: specifically, allow a field to accept more than one  
constraint, and have the constraints raise errors (with an i18n doc,  
if desired) rather than return an uninformative Boolean.  This can be  
done in a backwards (and deprecation) compatible way by keeping the  
constraint argument and adding a constraints argument wit the new  
semantics; or with another approach. *would need small proposal*  
*code exists*


4 Recognize and document that the 'default' field argument is  
actually 'initial value'.  That is, if you set a field with a default  
to the missing_value, the default does not become the field's value:  
the 'default' value is only used if the value has never been set  
(i.e., during creation or when there is no previous state of the  
value).  Possibly rename to 'initial_value' (with deprecation  
support).  *would need proposal*


5 Allow fields to accept a default (or initial_value, as above) *or*  
a default_getter (or initial_value_getter, as above).  default_getter/ 
initial_value_getter would be a callable passed the field's context.   
It should return the desired initial value.  Use cases include  
initializing to now, today, the current user, etc.  *would need small  
proposal* *code exists*


6 Add union field and widget to schema and form, respectively.  A  
union field allows a user to fill in one of several types of values.   
Use cases include faux combo boxes (i.e., a choice or a text line),  
date/duration choices, etc.  Widget is reasonable and has been used  
by ZC for more than a year.  *would need small proposal* *code exists*


7 add combination field and widget to schema and form, respectively.   
A combination field allows a user to fill in multiple values  
simultaneously, and returns a tuple of the combined values.  Use  
cases overlap somewhat with object field/widget, but this is simpler  
to use for simple use cases.  Use cases include range fields.  *would  
need small proposal* *code exists*


8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets  
provide a drop down of suggested (specifically most recently used for  
the MRU widget) values for a choice field.  They really make using  
choice widgets much nicer in many cases.  *code exists* *proposal  
needed for also adding another of our packages to the core, on which  
this relies*


9 Add standard timezone source and widget.  *code exists* for  
something that should really be a shared community effort.  Relies on  
suggestion widget and MRU widget, above.


10 The big restructuring of schema: divide up schema into interface  
values and usage relationships.  This is too big to explain in this  
email, and probably too big to even adequately begin in two days.   
This is the direction Jim wants to take schema, though, and I'm +1.


11 Brainstorm current state of the widget API and base

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:




Yes, I think that Rob mentionned that there was such a use case where
you had customers who wanted to control the way portlets were disposed
on the screen on an individual basis.



This gets to a terminology problem.  JSR 168 defines portlets to
mean something quite different. In particular, JSR 168 specifies
portlets that are used by end users, by which I mean the final users,
as opposed to content managers, of a site to control what they
personally see on a site. This is what Rob was refering to.
(BTW, we would prefer that the term portlet be used to talk
about portlets as defined by JSR 168.)

Your local portlets are used by content managers to define
content to appear in the o-wrap, based on site location.




no, they are used by end-users as well -- this is already the case in
the Zope2 version of cpsskins -- inside the perspective that they have
permission to work in.


I'm talking about end users who don't have permission to work on any
part of the site.  Further, when users's manipulate JSR 168 portlets,
they only effect what *they* see, not what others see.  The goals
are very different.


this is where I don't understand how you can with a view / adapter /
page template paradigm get the JSR 168 portlets to fit in. Views,
adapters are for programmers, not for end-users, not even for content
creators.


I don't know what you mean.  You can implement a JSR 168 pertlet system
in a variety of ways, including with adapters, views, ZPT etc.  I wasn't
talking about implementation strategy.  I was talking about the kind of
application -- the nature of the user interaction.

...


it depends on what the content well looks likes, if the content well
consists of 6 portlets, side by side or one below the other, then this
is not a problem to let the cpsskins layout mechanism take care of that.
I'm still not sure about what you put inside the content well, this is why.

if the content well contains a document with some advanced layout and a
lot of widgets then this is outside the scope of the cpsskins layout
renderer.


We have applications that layout the content well using a content-reuse
paradigm.  Here, users slot content and then specify how it
should dispayed.  The point is that the paradigm is very different
from site layout.  There are different users with different goals.




what do you mean by complex? have you seen the prototype? for a user
it does not seem too complex:

- choose a perspective
- add portlets to it
- assign the perspective to some context



- It's not clear what impact they have on URLs.  If, for
 example, perspectives are set via cookies or session
 data, then both bookmarking and caching become more complicated.



what about skins?

...


- By introducing modes, I worry that they will make it
 harder to talk about and teach systems build with them.

Jim



what should we say about skins then? they introduce exactly the same
problems. However they exist in Zope3.

a perspective is a skin but for the portlets in a page. If you think
that perspectives are too complex then the skins mechanism should be
reconsidered...


Perspectives are used in exclipse muc the same way we use views in
Zope 3.  They are much more akin to Zope 3 views than to skins.
People will change perspectives often, but they will rarely change
skins.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Stephan Richter

On Monday 29 August 2005 15:30, Gary Poster wrote:
 We'll be doing some work on the widget/schema code at the Rivah  
 sprint, Thursday and Friday this week.  This email identifies the  
 possible tasks, and proposes the actual choice of work (short answer:  
 potentially all but the biggest, and last, 2).  Interested parties  
 are invited to comment and suggest, whether or not you plan to be at  
 the Rivah sprint.

I am open for any of them. However, I would be most interested in writing 
proposals on things that we want to get implemented in the near future, i.e. 
for Zope 3.2. We will have a unique combination of developers there, since 
all of the participants I know of have significant Zope 3 experience. If all 
developers there agree on an approach, it is very unlikely that anyone will 
have issues. On the other hand, I realize that writing proposals is a very, 
very dry and boring task for a sprint.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Jim Fulton wrote:


...


- They introduce a need for some complex infrastructure.



what do you mean by complex? have you seen the prototype? for a user
it does not seem too complex:

- choose a perspective
- add portlets to it
- assign the perspective to some context


I meant to reply to this in my last note.

I wasn't talking about the user experience, I was talking about the
underlying implementation.  You require a centralize database of triads
with a scalable query engine.  This seems rather complex to me.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives


Jean-Marc Orliaguet wrote:

Hi!

Somehow related to the discussion on optimizing catalog queries, I have
been thinking about how to best implement local portlets in cpsskins in
terms of scalability, performance and functionality. The implementation
is heavily dependent on being able to performance effective catalog
queries (it is OK to wait 2 seconds in an ECMS to search 1 million
documents, but it is not OK to have to wait 2 seconds to render a page
containing portlets).

Here is the proposal:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets

It is built on the notion of Perspective (see the link) and on the
idea of querying the catalog using triadic relations instead of joining
sets of query results based on dyadic predicates (such as with RDF).


Well, after our various discussions, I think I understand what this
is about.

I have the following suggestions:

- I think the perspective idea has a lot of merit, however, I'd
  like it to be optional.  In particular, I'd like to be able to use
  CPS Skins without having to use perspectives.

- You said that cells can be filled with portlets or with slots.
  Why not make a slot another kind of portlet?  Then people could
  introduce new slot types and innovations without affecting the
  rest of CPS Skins.

- Use of the term portlet here leads to confusion with JSR 168
  portlets, which are different.   I would prefer to see a different
  term used for what CPS calls portlets. Absent that, we'll need to
  find some modifiers to disambiguate.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 29, 2005, at 3:44 PM, Stephan Richter wrote:


On Monday 29 August 2005 15:30, Gary Poster wrote:


We'll be doing some work on the widget/schema code at the Rivah
sprint, Thursday and Friday this week.  This email identifies the
possible tasks, and proposes the actual choice of work (short answer:
potentially all but the biggest, and last, 2).  Interested parties
are invited to comment and suggest, whether or not you plan to be at
the Rivah sprint.



I am open for any of them. However, I would be most interested in  
writing
proposals on things that we want to get implemented in the near  
future, i.e.
for Zope 3.2. We will have a unique combination of developers  
there, since
all of the participants I know of have significant Zope 3  
experience. If all
developers there agree on an approach, it is very unlikely that  
anyone will
have issues. On the other hand, I realize that writing proposals is  
a very,

very dry and boring task for a sprint.


I agree that would be useful, and I know you have some big ideas.   
Maybe we can do some of both.  What I sprint on is up to Jim. :-)  He  
mentioned the schema/form stuff, which makes sense too.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

Jean-Marc Orliaguet wrote:

Hi!

Somehow related to the discussion on optimizing catalog queries, I have
been thinking about how to best implement local portlets in cpsskins in
terms of scalability, performance and functionality. The implementation
is heavily dependent on being able to performance effective catalog
queries (it is OK to wait 2 seconds in an ECMS to search 1 million
documents, but it is not OK to have to wait 2 seconds to render a page
containing portlets).

Here is the proposal:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets

It is built on the notion of Perspective (see the link) and on the
idea of querying the catalog using triadic relations instead of joining
sets of query results based on dyadic predicates (such as with RDF).

Well, after our various discussions, I think I understand what this
is about.

I have the following suggestions:

- I think the perspective idea has a lot of merit, however, I'd
like it to be optional. In particular, I'd like to be able to use
CPS Skins without having to use perspectives.

that's possible, when you can more you can less (or differently)

- You said that cells can be filled with portlets or with slots.
Why not make a slot another kind of portlet? Then people could
introduce new slot types and innovations without affecting the
rest of CPS Skins.

yes, this is a possible extension, it is also possible to create a new
types of objects that fits your needs that are neither slots nor
portlets but that are contained inside cells.

why not create a portlet that does what you want? the main formal
difference between slots and portlets is that slots are inner nodes
(physically or virtually contain other objects) and that portlets are
node leaves (must render some data).

here is the actual base classes:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/elements/__init__.py

this is important for the theme editor.

if the new type of object that you are thinking of work like an inner
node, then it's a slot otherwise it's a portlet.

basically if the slot that you're thinking about contains portlets
then it's a sort of slot not a sort of portlet.

- Use of the term portlet here leads to confusion with JSR 168
portlets, which are different. I would prefer to see a different
term used for what CPS calls portlets. Absent that, we'll need to
find some modifiers to disambiguate.

Jim

yes, any term, boxes are not OK, since they refer to the portlet's
display (view) with the frame and the decorations but any term that is
understood by users / developers is ok.

/JM

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] [DRAFT] local portlets and perspectives

Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:

 Jim Fulton wrote:


 ...

 - They introduce a need for some complex infrastructure.


 what do you mean by complex? have you seen the prototype? for a user
 it does not seem too complex:

 - choose a perspective
 - add portlets to it
 - assign the perspective to some context


 I meant to reply to this in my last note.

 I wasn't talking about the user experience, I was talking about the
 underlying implementation.  You require a centralize database of triads
 with a scalable query engine.  This seems rather complex to me.

 Jim

Yes, if you store portlets in local folders (this is what you were
thinking about?) you won't have the same scalability problems unless you
have to traverse 20 folders from the site root to the current folder.

This is a trade-off. This is how it was implemented in CPSSkins (Zope2)
inspired from the earlier implementation (CPSBoxes). The simplicity of
the implementation in terms of storage has meant some very difficult
issues to solves in terms of user interface. So now I'm willing to
invest some time in finding a generic way of storing triadic relations
in a storage.

For me it is more important to allow users to place portlets anywhere in
the site (on the front page, etc...), even if the site exists already or
not,  but I agree that it should be possible to use the local folder
storage  approach in the Zope3 version too. Technically speaking there
is nothing that prevents the creation of varieties of slots that save
portlets in local folders.

/JM

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)


Stephan Richter wrote:

On Monday 29 August 2005 15:30, Gary Poster wrote:

We'll be doing some work on the widget/schema code at the Rivah  
sprint, Thursday and Friday this week.  This email identifies the  
possible tasks, and proposes the actual choice of work (short answer:  
potentially all but the biggest, and last, 2).  Interested parties  
are invited to comment and suggest, whether or not you plan to be at  
the Rivah sprint.



I am open for any of them. However, I would be most interested in writing 
proposals on things that we want to get implemented in the near future, i.e. 
for Zope 3.2.


I thought you and I would work on publisher-related topics.

 We will have a unique combination of developers there, since
all of the participants I know of have significant Zope 3 experience. If all 
developers there agree on an approach, it is very unlikely that anyone will 
have issues.


Lots of people have a stake in the widget framework, especially Garrett.

 On the other hand, I realize that writing proposals is a very,

very dry and boring task for a sprint.


But sprints are a good place to brainstorm.  One topic I'd like to
brainstorm is the last stage of the publishing process.  Now,
we don't have a formal publishing interface. Informally, an object is
called and returns something. I'd like to flesh this out a bit more. :)
I'd also like to make it possible to plug in additional processing, for
example to provide site look at feel.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] thread.local da-connection

2005-08-29 Thread Garanin Michael

Hello!
I have situation: 
1) I have PostgreSQL database: max-connection == 5
2) I have one IZopeDatabaseAdapter
2) I create 10 threads and join's (!!!)  to main thread
2.1) In each thread i get IZopeConnection from IZopeDatabaseAdapter
2.2) execute simple select-statement  call transaction.commit

Result: sometimes (~ 1/10) i get exception connection limit exceeded. 
I think: problem is safety stopped threads (and his locals) in memory
along short time = connections also in memory short time and not
destroed and not closed. Of course, i can call 'disconnect' every time,
but it's bad.

May be make connections-pool (only da with threadsafety==2) and after
transaction.commit\abort move connection to connections-pool for use in
other threads?

attach: 
1) thread_test.py
2) pgda.py - simple da for PostgreSQL for pyPgSql

Thanks!




  
 



# -*- coding:utf-8 -*-
  простая реализация DA к PostgreSQL
$Id$

from zope.app.rdb import ZopeDatabaseAdapter, parseDSN
import pyPgSQL.PgSQL as PgSQL


class PgDA(ZopeDatabaseAdapter):
 simple pyPgSQL adapter for Zope3
__name__ = __parent__ = None

threadsafety = 1

def _connection_factory(self):
conn_info = parseDSN(self.dsn)

encoding = conn_info.get('client_encoding','UTF-8')

pg_conn = PgSQL.connect(host=conn_info['host'],
database=conn_info['dbname'],
client_encoding=encoding, 
user=conn_info['username'],
password=conn_info['password'])  

return ProxyConnection(pg_conn)
 

class ProxyConnection:
 прокси-класс для  перехвата вызовов метода cursor() 

def __init__(self, connection):
self.conn = connection

def __getattr__(self, key):
return getattr(self.conn, key)

def cursor(self):
return ProxyCursor(self.conn.cursor())
  

class ProxyCursor:
 прокси-класс для перехвата вызова метода execute и executemany: исправляет ? на %s ибо того хочет pyPgSQL

# TODO: простой replace - плохо = надо заменить или найти другое решение
def __init__(self, cursor):
self.cursor = cursor

def __getattr__(self, key):
return getattr(self.cursor, key)

def execute(self, sql, params=None):
sql = sql.replace('?', '%s')
if params:
return self.cursor.execute(sql, params)
else:
return self.cursor.execute(sql)
   
def executemany(self, sql, params):
sql = sql.replace('?', '%s')
#return self.cursor.executemany(sql, params)
total_sql = ''
for param in params:
new_param = tuple(map(_quote,param))
total_sql += (sql % new_param) + ';'   

self.cursor.execute(total_sql)


import string
import types
def _quote(x):
copy/paste/modified from PyGresSQL
if isinstance(x, unicode):
x = x.encode( 'utf-8' )

if isinstance(x, types.StringType):
x = ' + string.replace(
string.replace(str(x), '\\', ''), ', '') + '
elif isinstance(x, (types.IntType, types.LongType, types.FloatType)):
pass
elif x is None:
x = 'NULL'
elif isinstance(x, (types.ListType, types.TupleType)):
x = '(%s)' % string.join(map(lambda x: str(_quote(x)), x), ',')
elif hasattr(x, '__pg_repr__'):
x = x.__pg_repr__()
else:
raise InterfaceError, 'do not know how to handle type %s' % type(x)

return x
#! /usr/bin/env python
# -*- coding:utf-8 -*-

import time
import threading

import transaction
from zope.app import zapi
from zope.app.testing import ztapi
from zope.app.rdb.interfaces import IZopeDatabaseAdapter

from pgda import PgDA

def f(num):
print 'start thread ', num
zda = zapi.getUtility(IZopeDatabaseAdapter)
conn = zda()
sql = 'select count(*) from pg_user;'
cur = conn.cursor()
cur.execute(sql)

transaction.commit()
print 'end thread ', num

def setupPgDA():
da = PgDA('dbi://test:[EMAIL PROTECTED]/testdb')
ztapi.provideUtility(IZopeDatabaseAdapter, da)

def start():
for i in range(7):
t = threading.Thread(target=f,args=(i+1,))
t.start()
t.join()
   
   
if __name__ == '__main__':
setupPgDA()
for i in range(2):
start()
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)


Gary Poster wrote:
...
4 Recognize and document that the 'default' field argument is  actually 
'initial value'.  That is, if you set a field with a default  to the 
missing_value, the default does not become the field's value:  the 
'default' value is only used if the value has never been set  (i.e., 
during creation or when there is no previous state of the  value).  
Possibly rename to 'initial_value' (with deprecation  support).  *would 
need proposal*


5 Allow fields to accept a default (or initial_value, as above) *or*  a 
default_getter (or initial_value_getter, as above).  default_getter/ 
initial_value_getter would be a callable passed the field's context.   
It should return the desired initial value.  Use cases include  
initializing to now, today, the current user, etc.  *would need small  
proposal* *code exists*


I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.

...

7 add combination field and widget to schema and form, respectively.   A 
combination field allows a user to fill in multiple values  
simultaneously, and returns a tuple of the combined values.  Use  cases 
overlap somewhat with object field/widget, but this is simpler  to use 
for simple use cases.  Use cases include range fields.  *would  need 
small proposal* *code exists*


I have an open mind, but I'm a bit skeptical (as you know :).  I expect
this proposal to be a bit controversal.  Perhaps we can plan to go another
round of brainstorming during the sprint.

10 The big restructuring of schema: divide up schema into interface  
values and usage relationships.  This is too big to explain in this  
email, and probably too big to even adequately begin in two days.   This 
is the direction Jim wants to take schema, though, and I'm +1.


See:
http://mail.zope.org/pipermail/interface-dev/2004-June/48.html

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)


Garrett Smith wrote:
...


Jim has been complaining vociferously about SimpleInputWidget. It's probably 
time to nuke it (fine, deprecrete) and replace it with helper functions ala 
utility.py.

There's quite a bit on the plate here. I'd be inclined to flesh out in more detail 
the infrastructural pieces (vocab - source, constraints, widget API refactor) 
and leave new fields and widgets for later.

I can probably free up some time to look at SimpleInputWidget.


Ah, this is a good one.  My suggestion would be to write a
SingleInputWidget that:

- Addresses inputs that map onto single HTML inputs (e.g.
  text, float, int, etc.)

- provides a good well-documented example of how to use
  the lower-level widget framework.

This would be an excellent sprint topic, IMO.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:


Gary Poster wrote:
...

4 Recognize and document that the 'default' field argument is   
actually 'initial value'.  That is, if you set a field with a  
default  to the missing_value, the default does not become the  
field's value:  the 'default' value is only used if the value has  
never been set  (i.e., during creation or when there is no  
previous state of the  value).  Possibly rename to  
'initial_value' (with deprecation  support).  *would need proposal*
5 Allow fields to accept a default (or initial_value, as above)  
*or*  a default_getter (or initial_value_getter, as above).   
default_getter/ initial_value_getter would be a callable passed  
the field's context.   It should return the desired initial  
value.  Use cases include  initializing to now, today, the current  
user, etc.  *would need small  proposal* *code exists*




I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.


Initial value is a concept in XMLSchema (http://www.w3.org/TR/ 
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty sure  
they are talking about what we are talking about.  I think it does  
belong in a statement about a logical schema.


Moreover, I regard any lookup code as an intellectual cost for  
developers: a cost both for making and for finding the associated  
configuration.  For schemas, being able to look in one place is very  
valuable, at least to me.  APIDoc can help, but is not a panacea.  I  
don't think this particular configuration division would be a win.


I think dropping the functionality of default would be a loss for  
reasonable schema functionality.  I think renaming it to initial or  
initial_value would be a win for accurate names.  I'm willing to drop  
the getter: it is kind of ugly, I admit.


You ok with just changing the name?


...


7 add combination field and widget to schema and form,  
respectively.   A combination field allows a user to fill in  
multiple values  simultaneously, and returns a tuple of the  
combined values.  Use  cases overlap somewhat with object field/ 
widget, but this is simpler  to use for simple use cases.  Use  
cases include range fields.  *would  need small proposal* *code  
exists*


I have an open mind, but I'm a bit skeptical (as you know :).  I  
expect
this proposal to be a bit controversal.  Perhaps we can plan to go  
another

round of brainstorming during the sprint.


OK--I must admit that I have a bit of the hack willies about it  
too.  :-)  It's useful, though, and I haven't been convinced by any  
alternatives yet.  This one's off the table for the sprint then,  
except perhaps for discussion.


For the record, here are the use cases that the Combination field  
fills now:


- range
- main value plus modifier(s): find something supervised by X (a  
person), directly or indirectly (a Bool); and select something for  
publication (an object), in a given context (local, global, whatever).


I know you don't like the first one, and I do ATM :-).  The second  
one makes me more suspicious, though.  A combination field can  
fulfill it, but we have had a real use case, or at least desire, for  
a list widget of this sort of data structure.  Without a concept of  
main value and secondary values (and a combination widget doesn't  
promise anything like that) you can't get what we wanted.


10 The big restructuring of schema: divide up schema into  
interface  values and usage relationships.  This is too big to  
explain in this  email, and probably too big to even adequately  
begin in two days.   This is the direction Jim wants to take  
schema, though, and I'm +1.




See:
http://mail.zope.org/pipermail/interface-dev/2004-June/48.html


Cool, thanks.

Gary

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 29, 2005, at 4:24 PM, Garrett Smith wrote:

To ease our own development, I forked the schema and widgets code a  
while back. I don't think we've deviated too severely, but I've  
added whatever 2 cents based on my experience below.




1 Flesh out the 'source' design and implementation so it can replace
and deprecate vocabularies.  Specifically, to match the capabilities
of vocabularies, we'll add an interface that a source can implement
if they want to be bound to a context; and we will make it possible
to have iterable sources (for small collections as would be
appropriate for selections, radio button groups, checkbox groups,
etc.).  This will reduce the potential for confusion by letting
sources be the 'one true way' to describe possible options for a
choice, instead of the current overlap of vocabularies and sources.
The primary advantage to sources over vocabularies are that
the model
is cleaner; the only additional feature is the ability to configure
different tokens for a given source.



This sounds good. The one main hassle I've faced with vocabularies  
is the seeming complexity of the queriables UI scheme. I've spent  
much time tracking down how everything fits together, but  
unfortunately never spent the time to figure out a simpler  
approach. If it's already as simple as possible, fine -- sometimes  
stuff's just hard to simplify.


It isn't the easiest thing to grok, no.  We don't have any ideas to  
improve it either, except to add more documentation, which is still  
lacking AFAIK.  Maybe writing more documentation will reveal other  
ideas...



2 Clean up the exceptions widget framework.  The use of the widget
input error is quite messy: see collector issue 273.  The idea would
be to make the use of the errors argument more consistent and more
restricted, and make the 'doc' implementation simpler.



I have a ValidationError that looks like this:

class ValidationError(zope.schema.interfaces.ValidationError):

def __init__(self, msg, *args):
zope.schema.interfaces.ValidationError.__init__(self, *args)
self.msg = msg

def doc(self):
return self.msg

This was to workaround the strangeness of displaying a class-level  
description, rather than the specific msg provided with the error.


Cool: yes, that's very, very similar to our internal one, except I  
have an optional mapping arg (for values to be placed in the  
i18n.Message) and no *args.



3 Make the arbitrary constraints in the schema framework more
powerful: specifically, allow a field to accept more than one
constraint, and have the constraints raise errors (with an i18n doc,
if desired) rather than return an uninformative Boolean.
This can be
done in a backwards (and deprecation) compatible way by keeping the
constraint argument and adding a constraints argument wit the new
semantics; or with another approach. *would need small proposal*
*code exists*

4 Recognize and document that the 'default' field argument is
actually 'initial value'.  That is, if you set a field with a
default
to the missing_value, the default does not become the field's value:
the 'default' value is only used if the value has never been set
(i.e., during creation or when there is no previous state of the
value).  Possibly rename to 'initial_value' (with deprecation
support).  *would need proposal*



Our version of IField has an 'initial' attribute. We don't use  
default. I prefer 'initial' to 'initial_value'.


That sounds good to me.  I don't feel strongly about initial_value:  
short is good.



5 Allow fields to accept a default (or initial_value, as above) *or*
a default_getter (or initial_value_getter, as above).
default_getter/
initial_value_getter would be a callable passed the field's
context.
It should return the desired initial value.  Use cases include
initializing to now, today, the current user, etc.  *would
need small
proposal* *code exists*



Couldn't 'initial_getter' just be implemented using a property  
version of 'initial'?


Yes, it could.  The only downside is that it wouldn't be usable as an  
initialization argument.  I don't feel very strongly about it one way  
or the other.  It sounds like Jim is a definite -1 (as I thought he  
might be :-) so I'm happy to drop it.



6 Add union field and widget to schema and form, respectively.  A
union field allows a user to fill in one of several types of
values.
Use cases include faux combo boxes (i.e., a choice or a text line),
date/duration choices, etc.  Widget is reasonable and has been used
by ZC for more than a year.  *would need small proposal* *code  
exists*


7 add combination field and widget to schema and form,
respectively.
A combination field allows a user to fill in multiple values
simultaneously, and returns a tuple of the combined values.  Use
cases overlap somewhat with object field/widget, but this is simpler
to use for simple use cases.  Use cases include range fields.
 *would
need small proposal* *code exists*


Cool. I

RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Garrett Smith


 I'm uncomfortable with this. Right now, I think fields do too much.
 They have too much application logic.  This would add more.  The whole
 concept of initial value seems to be very application dependent.
 Maybe it would be best to just drop the default field altogether
 and introduce adapters for computing initial values in those special
 cases when we need them.

Funnily, I just faced this dilema earlier today. I nearly created an interface 
like this:

  class IInitialValue(Interface):
  An interface for obtaining an initial value for an object.

  def get():
  Returns the initial value.

IMO, this is superior to field.initial. E.g.

  zapi.getMultiAdapter((field, context), IInitialValue).get()

Perhaps this pattern could be used for getting an ISource from a field. E.g.

  zapi.getMultiAdapter((field, context), ISource)

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Stephan Richter

On Monday 29 August 2005 16:43, Jim Fulton wrote:
  I am open for any of them. However, I would be most interested in writing
  proposals on things that we want to get implemented in the near future,
  i.e. for Zope 3.2.

 I thought you and I would work on publisher-related topics.

Great! This is definitely my favorite topic too. :-) I am glad we are on the 
same line. :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)



On Aug 29, 2005, at 6:37 PM, Garrett Smith wrote:


On Monday, August 29, 2005 4:33 PM, Gary Poster wrote:



Couldn't 'initial_getter' just be implemented using a property
version of 'initial'?


Yes, it could.  The only downside is that it wouldn't be
usable as an
initialization argument.  I don't feel very strongly about it
one way
or the other.  It sounds like Jim is a definite -1 (as I thought he
might be :-) so I'm happy to drop it.


I think I agree with Jim, see my other post.


OK.  He and I brainstormed a bit more about it.  That does sound like  
part of a fruitful area for sprint conversations.



Cool. I don't know if this is the same thing, but we have a widget
that handles editing two related fields. One field is a boolean
that, when False, renders the other field not-applicable. E.g. when
the user unselects a checkbox, a list box becomes disabled. Our
implementation is a bit of a hack, since the widget has to cheat
and get access to additional fields.



Huh, interesting.  It sounds different.  What is the typical use for
this sort of field?



It's not a field -- it's a widget that cheats and updates multiple  
fields because the fields are closely related. Probably not worth  
worrying about at this point.


OK


I can probably free up some time to look at SimpleInputWidget.


That would be great--you mean, during the same time as the
sprint, or
before, or after?  If before or during, we should probably  
coordinate.


If the API falls into a collaboration category, I can try to be  
available via IRC. I suspect it will be more efficient to just have  
a brainstorm during the sprint, put together a simple proposal and  
work up a prototype. The SingleInputWidget Jim's talking about will  
end up looking a lot like SimpleInputWidget.


:-)


When is the sprint anyway? :-)


This Thursday and Friday, Sept. 1  2.

Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Bug in i18n timezones (was Re: [Zope3-Users] obtaining time zone from http request)



On Aug 29, 2005, at 7:18 PM, Alen Stanisic wrote:


On Mon, 2005-08-29 at 09:50 -0400, Gary Poster wrote:


And FWIW, once you get your browser settings correct, for the
timezone part of the locale database, en-* is all the same--that is,
if my locale is en-US, I get all en* locations (including Casablanca,
Tokyo, and other interesting locations). :-)  I think you will too.


Correct, I get exactly the same locations (EST, LA, Casablanca,
Tokyo, ...) with en-US or en-AU locale, and no Australian locations??


You know, I was about to write back and say, hey, don't blame us,  
it's those crazy Unicode people: http://unicode.org/cldr/data/common/ 
main/ .  We are using their database.


Then, when I was looking up how to submit bug reports to the  
database, I saw this on http://www.unicode.org/cldr/ 
filing_bug_reports.html : Similarly, the timezones for different  
regions are to be derived from Olson data, and are not in the locale  
data..


It seems we are supposed to be getting our i18n timezone data,  
mapping country code to timezone name, from the Olson database.  AU,  
for instance, gets this much more reasonable list from the current  
Olson database's 'zone.tab' file:


AU  -3133+15905 Australia/Lord_Howe Lord Howe Island
AU  -4253+14719 Australia/HobartTasmania - most  
locations

AU  -3956+14352 Australia/CurrieTasmania - King Island
AU  -3749+14458 Australia/Melbourne Victoria
AU  -3352+15113 Australia/SydneyNew South Wales -  
most locations
AU  -3157+14127 Australia/Broken_Hill   New South Wales -  
Yancowinna
AU  -2728+15302 Australia/Brisbane  Queensland - most  
locations
AU  -2016+14900 Australia/Lindeman  Queensland - Holiday  
Islands

AU  -3455+13835 Australia/Adelaide  South Australia
AU  -1228+13050 Australia/DarwinNorthern Territory
AU  -3157+11551 Australia/Perth Western Australia

If you are interested, the columns four are ISO 3166 2-character  
country code, latitude and longitude of the zone's principal  
location, zone name, and comments, respectively.


I was also personally happy to see that en-US does not include Tokyo  
or Casablanca.


I'd say this is a bug: we should be including the Olson zone.tab file  
in with our 18n data and getting our timezone names from it.  Moving  
this to the Zope 3 dev list now for discussion there.


Stephan, do you have any concerns about incorporating the Olson  
information in 18n?  I suppose another approach would be to see if  
Stuart would be willing to have pytz grow this mapping, and have the  
i18n package depend on pytz.  I'd actually prefer that, if you and  
Stuart agreed and were willing, since he already has his automatic  
processing of the Olson database, and is already keeping up with the  
Olson releases.


Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: Bug in i18n timezones (was Re: [Zope3-Users] obtaining time zone from http request)

2005-08-29 Thread Stuart Bishop

Gary Poster wrote:

 And FWIW, once you get your browser settings correct, for the
 timezone part of the locale database, en-* is all the same--that is,
 if my locale is en-US, I get all en* locations (including Casablanca,
 Tokyo, and other interesting locations). :-)  I think you will too.

 You know, I was about to write back and say, hey, don't blame us,  it's
 those crazy Unicode people: http://unicode.org/cldr/data/common/ main/
 .  We are using their database.
 
 Then, when I was looking up how to submit bug reports to the  database,
 I saw this on http://www.unicode.org/cldr/ filing_bug_reports.html :
 Similarly, the timezones for different  regions are to be derived
 from Olson data, and are not in the locale  data..
 
 It seems we are supposed to be getting our i18n timezone data,  mapping
 country code to timezone name, from the Olson database.  AU,  for
 instance, gets this much more reasonable list from the current  Olson
 database's 'zone.tab' file:
 
 AU  -3133+15905 Australia/Lord_Howe Lord Howe Island
 AU  -4253+14719 Australia/HobartTasmania - most  locations

 Stephan, do you have any concerns about incorporating the Olson 
 information in 18n?  I suppose another approach would be to see if 
 Stuart would be willing to have pytz grow this mapping, and have the 
 i18n package depend on pytz.  I'd actually prefer that, if you and 
 Stuart agreed and were willing, since he already has his automatic 
 processing of the Olson database, and is already keeping up with the 
 Olson releases.

I'm happy to expose this through pytz. There is a new set of data files
released yesterday (including the 2006 changes the US has just signed into
law) so I can push out a new release in the next day or two with this added.

Stephan - Should this update go into the 3.1 branch, or just the trunk?

-- 
Stuart Bishop [EMAIL PROTECTED]
http://www.stuartbishop.net/


signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Re: [Zope3-dev] Re: RDFLib and Zope 3