Re: [Zope3-dev] Re: Catalog improvements
Dieter Maurer wrote: Martijn Faassen wrote at 2005-8-25 13:49 +0200: ... AdvancedQuery ... I need to figure out the lazy sorting concept too and how to port it to the Zope 3 catalog... I see elsewhere in the thread you also mention it supports a simple form of joins, which is also very interesting. No, "AdvancedQuery" does not support joins. But, Python is a very powerful gluing language which allows you to implement simple joins yourself. Okay, I misunderstood then. Of course Python allows one to implement joins oneself. :) I don't think we want everybody to write their own joins, though. It certainly cost me some headscratching thinking about it, especially how to do it efficiently and express it compactly, and it would be good if we could come up with a reasonably efficient solution (using indexes?) in the Zope 3 core. We could even start it out as not being very efficient -- it would already be useful to have an abstraction present and we can always make it more efficient in the future. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Hello, My problems on this subject didn't get resolved since my last post, but I have some new info and questions - The sympthoms (Zope 3.1.0c1): Database adapters are not usable by principals other than the zope.Manager, in the principals.zcml file. Any other principal is unauthenticated - I tried principals.zcml regular user with zope.ManageContent, zope.UseDatabaseConnections and zope.View granted, pluggable authentication user with the zope.Manager role granted, and finally - principals.zcml regular user with zope.Manager role. All principals are able to see and manage the connection object, but can't retrieve results. This is tested and true for both psycopg and Gadfly database adapters. This is the exception I get when trying to use SQL script: * Module zope.app.sqlscript.browser.sqlscript, line 39, in getArguments for argname, argvalue in self.context.getArguments().items(): Unauthorized: (0xa03e86c>, 'items', 'zope.ManageContent') This is the excpetion from the test page of the connection object (in /++etc++site/tools) when I use principal with zope.Manager granted: * Module zope.app.rdb, line 372, in queryForResults cursor = conn.cursor() Unauthorized: (, 'cursor', 'zope.ManageContent') Hmm... Database adapter working just fine for me. Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) and the ZopeConnection class does not have anything, that deals with security, as far as I can see. See zope/app/rdb/configure.zcml for security declarations. My question is, does this eventually mean, that ZopeConnection objects, which are created at run-time, are not security proxied and consequently unauthorized in all cases (except the system_user) and if yes, what should be done? I'm not familiar with the Zope3 environment and I don't know how and where objects get proxied. Or is there something I'm missing here ? Can you repeat all this experiments on clean Z3 setup (without any additional components and without your old Data.fs file, check also for all possibly conflicting modules on the PYTHONPATH)? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] security problems with database adapters (second edition)
I forgot to add cc: for the list, sorry Dmitry Vasiliev wrote: >> Looking at the code, the ZopeConnection object is created by the ZopeDatabaseAdapter class in zope.app.rdb (inherited by the actual DatabaseAdapter) with a simple call - self._v_connection = ZopeConnection(self._connection_factory(), self) >> and the ZopeConnection class does not have anything, that deals with security, as far as I can see. > > > > See zope/app/rdb/configure.zcml for security declarations. > I mean - I see in the zcml configuration, that zope.ManageContent permission is required for ZopeConnection, but I don't see what in the ZopeConnection object could provide it for the user. So my explanation is that the security policy simply allows one special kind of user in all cases, without ever checking permission and actually I found exactly the code, that does that, by seeing if the user is system_user and just granting access if yes. I didn't go deep enough to confirm that a user with zope.Manager granted _from principals.zcml_ is assigned that property, it's just my guess. However, it seems to me that when the zope.Manager role is granted by the UI grant tool, the user doesn't get system_user, permissions are cheked, a proxy is not found for the ZopeConnection and access is denied in all cases. I can eventually create a functional test to demonstrate, but it will take too much effort to browse around for the bits I need (since it is a really good framework and code, but it is a complete nightmare for the newcommer to follow the logic trough it). The problem is easy to reproduce in a few simple steps - assuming clean installation from the .tgz release, here is what I do: 1. create an instance (of course), zope.Manager granted principal is crated by the mkzopeinstance script. 2. uncomment the sample zope.Member principal 'frodo' in principals.zcml and run zope -- using the browser from now on: 3. login with the zope.Manager principal use the grant tool to grant zope.Manager role at the top of the site to the 'frodo' principal 4. go to manage site -> site management and add a database adapter, gadfly will do, dbi is something in the form of dbi://dbname;dir=/tmp, or any other dir as apropriate 5. login as frodo and go to /++etc++site/tools/yourdbaname 6. select the test page and just click on 'execute' 7. unauthorized 8. if you try (5),(6) with the zope.Manager principal, you will see the database adapter working as expected (producing an error in this example actually, but not 'unauthorized' exception) > > > Can you repeat all this experiments on clean Z3 setup (without any additional components and without your old Data.fs file, check also for all possibly conflicting modules on the PYTHONPATH)? > I just downloaded Zope-3.1.0c2, installed it clean and got the same behaviour. I am using python 2.4.1 and I will check with 2.3.5 if needed, but I saw enough Zope3 code already and I don't think this will change anything. I don't have much idea what module could be conflicting in the case of Zope3 and database adapters. The setup is clean, the test machine is freshly configured and I don't see what could get in the way, but I will check that more carefully too, if you can not reproduce the error at your side. Regards, Velko Ivanov P.s.: I changed the permissions for ZopeConnection, ZopeCursor and ZopeRow in zope/app/rdb/configure.zcml to zope.Public and it of course works, but that is again by going around the security policy, as with the system_user - it is just unconditionally allowing acces if the permission is zope.Public ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
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
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 docte
RE: [Zope3-dev] Proxy and __slots__
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, http://svn.zope.org/Zope3/trunk/Makefile?rev=37919&r1=37889&r2=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=38056&r1=37919&r2=38056 with - --install-dir Should we add back the Python version number within the Makefile (it solves the problem) ? J. - -- Julien Anguenot | Nuxeo R&D (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
Re: [Zope3-dev] Makefile and python version number
On 8/29/05, Julien Anguenot <[EMAIL PROTECTED]> wrote: > http://svn.zope.org/Zope3/trunk/Makefile?rev=37919&r1=37889&r2=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=38056&r1=37919&r2=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 -- Fred L. Drake, Jr. Zope Corporation ___ 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
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 R&D +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}), ..., , 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
-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=37919&r1=37889&r2=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=38056&r1=37919&r2=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 R&D (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: ... 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 Why is this a disadvantage? - difficult import / export I don't follow this. Do you mean that you'd like to export/import portlet assignments independent of everything else? - 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.. In that case, I don't understand why what you have now is inadequate. Now, users define a portlet in exactly one part of a site (and all subfolders). What am I missing? 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. You mean you want users to select different collections of portlets for different activities? If so, then why not just use different master pages and slots for the different activities? 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. Perspectives are about providing separate task-oriented UIs. A perspective is about performing a particular type of task on input. In many ways, it's like the Zope 3 view/adapter model, where we have different views selected by input and by type, where type expresses the kinds of tasks performed. It is not simply an arbitrary grouping of components. 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. I don't understand your answer. 1. I don't know what you mean by "these portlets". Do you mean in the current (undesireable) solution or in the new solution. It seems the statement applies to both. 2) I don't understand why being associated with different activities or targeted to different target audiences is 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? this is a minor problem actually and I've changed my mind on this issue since last week, I still don't know which pages you were talking about so I don't know what you changed your mind about. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.
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: http://mail.
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}), ..., , 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 class
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)
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: > >> Jim Fulton wrote: >> >> >> 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. > for me the Eclipse definition is a subset of what I mean. I took it as an inspiration, the application of perspective needs not be restricted to UI tasks. Again a perspective can be seen as a skin for portlets. It is as if you'd claim that skins can only be used in some situations and not in others.. > > > 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. > Use case: you are looking at a site from some "external website" perspective (cf. zope.org) you want to change the content of some document. So you need to interact with an action box that is invisible to anonymous users, and interact with a navigation portlet to find documents. Are you going to create a new zope.org page for that? Or just switch to the "web publisher" perspective? >> The main idea is to define visibility in a coherent way, > > > We're both in favor of that. > > good, I think that it is about time we find areas of agreements .. >> not with a >> series of CSS hacks (hidden {display:none}), > tal:condition="not:first_login" >..., , 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. they don't have too, you can switch the page (theme page) just like you switch perspectives .. pages and perspectives are orthogonal, they have to be combined but the combination is not determined in advance. the combination of 2 orthogonal concepts is worth a lot in terms of productivity. It is like the separation of form and content. > >> 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. For the user this could not be simpler in terms of UI. This is how newspaper CMSs work already, cf Polopoly (www.polopoly.se) used in many Swedish sites (cf. www.dn.se, www.svt.se) There are templates with slots (equivalent of pages in cpsskins) and there are sets of portlets assigned to slots. The perspective in Polopoly for each slot is even written using URLs, you can change it directly in the URL. In the end, and this is where I'm trying to get at: a site is a combination of pages and perspectives (the two notions being 100% orthogonal) when it comes to the implementation, I don't see how saving portlets in folders is better. I still don't understand how you can have 1 users add portlets inside a same slot and manage portlet order easily. > >> 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 al
RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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. > 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. > 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'. > 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'? > 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 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. > 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 widge
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
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 don
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: 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. Cool. So we can define new slot-like things (for example, for JSR 168-style slots) and use your slots or not, as we wish. In particular, we can use CPS skins without being forced to install triad registries unless we want to use your slots. - 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. Cool. "Pagelets"? 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)
> 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)
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. >> 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. >> 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? :-) -- 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)
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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> basically if the "slot" that you're thinking about contains portlets >> then it's a sort of slot not a sort of portlet. > > > Cool. So we can define new slot-like things (for example, > for JSR 168-style slots) and use your slots or not, as we wish. > > In particular, we can use CPS skins without being forced to > install triad registries unless we want to use your slots. > In that case it is possible to plug in other relation store backends (e.g RDF) that do not support genuine triadic predicates, which means that only "local folder" types of slots will be available, but some relation storage is required for the dyadic relations between elements and styles, widgets... because the relations between the elements are not stored on the elements themselves. > >>> - 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. > > > Cool. "Pagelets"? > > Jim > yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. Of course it is possible for a "pagelet" to render HTML directly and consider the HTML produced as data (that's a question of semantic), but then other rendering engines (text-based, SVG, RSS, ATOM, etc.) won't be able to do anything with the HTML data that they get. Anyway, pagelets or portlets whatever they called and no matter what data they produce (structured data or raw HTML) must be "pipe-able" through the rendering engine, i.e. they must return some data, the more "ready HTML" the data is the less reusable it will be. /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)
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)
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
On Aug 26, 2005, at 3:03 AM, Daniel Krech wrote: On Aug 25, 2005, at 3:10 PM, Michel Pelletier wrote: On Thu, 2005-08-25 at 14:32 -0400, Gary Poster wrote: see what he thinks. I wonder how "lite" the component kernel can go. The only thing I have in mind is the interface package, which is what Twisted uses. That's all we would need. zope.component needs zope.interface, zope.testing, and zope.exceptions, according to its DEPENDENCIES.cfg. Right. Well in this case we would provide just a very simple interface facade that had no effect when run in an environment with no zope.interface (ie, catch the ImportError, null-out the facade) or hook into zope.interface if it is available. This way rdflib can be still be used with or without zope.interface. Sounds good. OK, cool. In the mean time the adapters can live inside Zemantic, which is an rdflib to zope bridge anyway. Let me know if you want to send patches, otherwise I'll probably get around to adding functionality like this soon. I'm actually interested in trying to hook this up, but have very limited time. I might play with it just within RDFLib alone during some hobby time tonight, but otherwise may need to toss this off to you if you'll catch it. I also kind of want to hear Dan's reaction before I spend too much time. #redfoot on freenode is a good place to catch him, and me. Yep, feel free to stop by anytime. OK, cool, I plan to again. :-) I thought I read that an RDF triad was itself something that could be a node in another RDF triad, but I can't find that anywhere now. Can you confirm or deny? :-) Yes, it's called reification, making a statement about a statement. http://www.w3.org/TR/rdf-primer/#reification http://en.wikipedia.org/wiki/ Resource_Description_Framework#Statement_reification_and_context http://www.w3.org/TR/rdf-mt/#Reif Reification is probably best avoided. I'd recommend seeing if you can make use of a context or quoted graph instead. I have read that 'context' actually is still a word looking for a firm definition in RDF, but I like the interpretation that it is the source of the assertion. That's not a general answer for the sorts of things that reification can provide, though. The quoted graph does seem interesting: I said before that it seems very similar to reification, and it does, but I guess it subsumes the data structure that reification can provide...I also said that I wonder about efficient indexing, and I still do. On the plus side for context, you've implemented it. ;-) I'm interested in contemplating RDF as a full catalog solution for Zope, at least as a thought experiment. The SPARQL work seems interesting, in regards to some of the recent discussion on the Zope 3 list; and the ability to seamlessly and simultaneously query both relationship information between objects and more traditional catalog data seems compelling. It seems to me that allowing a back end to index particular relationships--and joins, particularly through blank nodes--would be a big step in letting RDF actually be a front end to a full catalog. Another step would be having a front end that honored rdfs range and domain constraints. I plan to get on IRC and bother you all again as soon as I have time to do so. :-) 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)
Dear Gary and Stephan, Would you please have a look at my messages with the subject "[Zope3-dev] problems with " I'm also having problems with CustomWidgetFactory, but in an other usecase. -- Best regards, Adam mailto:[EMAIL PROTECTED] -- Quote of the day: We desire most what we ought not to have - Publilius Syrus __ Nyaralás 50,000 Ft alatt: http://ad.advert.hu/url.php?u=226 Nyaralás Horvátországban: http://ad.advert.hu/url.php?u=227 További akciós utazási ajánlatok: http://utazas.swi.hu ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com