Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> in that case, using a portlet to display the poll results might not be the best solution, >>> >>> >>> >>> Right, but then what if, when displaying the poll results, I wanted to >>> use some >>> other portlet. Perhaps I have a portlet that lists the top 10 polls >>> and I want to display that within the content well (inside the >>> o wrap) when I display my results. >>> >> >> If it's just a matter of visual layout, you only need to add a slot >> inside your theme just below or above the main-macroslot where you can >> put the poll portlet (main top, and main bottom slot) as you'd find in >> any zpt-based template. > > > But then, I have to much with the theme just to get my page to > come out the way I want. > > But, maybe it's not a good idea to use the same mechanisms > for the o wrap and the content well. More on this later. > > >> >>> Limiting portlets to master pages (o wrap) seems to me to be a needless >>> and complicating limitation. >> > > Or maybe a good idea ... > >>> ... >>> >>> then the actual question is: why should a page in a zope3 application only display one view of an object at a time? i.e. the main view? when I read my mail I have 4 different views of my mailbox, not just the text contained in the mail ... >>> >>> >>> >>> Exactly. So, perhaps I have a mailbox. The main view for the mailbox >>> uses 3 portlets: >>> >>> - a mailbox listing portlet >>> >>> - a portlet that lists all my mailboxes >>> >>> - a portlet that displays a selected message >>> >>> Why can't I specify these three portlets in the definition of my >>> mailbox view? Why should I have to tease them into the master page? >>> >>> I'd like to be able to design my individual application pages >>> and the master page independently. If I can only display portlets >>> in master pages, then either: >>> >>> 1. I can't use them when designing individual application pages, or >>> >>> 2. I have to sneak the contents of my applications into the master >>> pages, >>> which seems to be a far more complicated model, conceptually, let >>> alone >>> computationally. >>> >>> Jim >>> >> >> all you need to know when you design your application is the name of the >> slot in which the portlet will be displayed (right slot, left slot, >> etc.) This was already the case CMF's main_template.pt where slot names >> where hardcoded. >> >> then in a zcml declaration of the perspective you can specify the slot >> in which the portlet will be displayed. >> >> in some way you'll have to tell *where* the portlets will be located on >> the page, this is what you do with the "fill-slot" use-macro attribute > > > But I want to control where the portlet will go in the content well, not > in the o wrap. > > It could be argued that different mechanisms should be used for the > o-wrap, > content well, and end-user portlets (ala JSR 168). This gets back to > Gary's point the other day that there are different actors and use cases > that *could* be unified, but that maybe it's not a good idea to, from > a UI > perspective. > > Site designers define the o-wrap (possibly many). When they design > the o wraps, > they define the position of the content well and other portlets, and > they can > also define slots where content managers can place additional portlets. > (I suppose an o wrap could define 0 or more content wells). > > Page designers (for specific applications) design pages that go in the > content well (or maybe content wells). When designing the contents of > the content well, they too might want a system that lets then combine > page or content components (ala the email interface). > > Content managers have some UI for arranging portlets within slots. > > End users might have portlets that they can arrange within slots as > well (ala JSR 168). (BTW, we find the use of the word portlets > for JSR 168 portlets and for the things that site designers, > page designers and content managers drag around to be pretty > confusing.) > > Anyway, at this point, I think I understand the basics of > CPSSkins, hopefully enough to think about your arguments for > perspectives. > I'll do that thinking and get back to you Monday. > > Have a good weekend. > > Jim > I'm going to set up a prototype to demo the concept of perspectives, the idea is generic enough I think and independent of the actual implementation I think. 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. 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"
Re: [Zope3-dev] Re: RDFLib and Zope 3
On Aug 26, 2005, at 2:56 AM, Daniel Krech wrote: On Aug 25, 2005, at 2:32 PM, Gary Poster wrote: On Aug 24, 2005, at 9:13 PM, Michel Pelletier wrote: On Wed, 2005-08-24 at 12:39 -0400, Gary Poster wrote: ... Since Dan is already using Twisted in his app server, maybe he'd be willing to let RDFLib drink the Zope interface Kool-Aid along with us and Twisted. I'm up for the zope.interface Kool-Aid if we can do it and fall back to the current functionality when zope.interface is not installed. Also, what's the latest on the likelyhood of zope.interface making it into Python2.5? Or timeframe on Python2.5 for that matter ;) Guido said in his blog that he's now pro-interface... http://www.artima.com/weblogs/viewpost.jsp?thread=92662 ...but no timeframe to my knowledge (nor happy concensus in his blog's comments :-). I asked Jim Fulton and he knew of no direct plans. I know he's looked at it, and previously he used zope.server before twisted. I think he might be out for a couple of days, so we'll wait to see what he thinks. I wonder how "lite" the component kernel can go. I was out for a few days... am back now and catching up. Sorry for the delay in responding. No problem. Thanks for replying. 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. 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. It might be easier to implement some of these things in Zemantic and push them down once we get a better idea of the impact Understood. I may still concentrate on RDFLib first, at least for my own drafts; we'll see. 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. Did you get a chance to give it a go? Sorry again for not getting back to you sooner. That's ok. No, I wanted to get a feel for your take on this, and I had other work that needed to be done. I also kind of want to hear Dan's reaction before I spend too much time. 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? :-) RDF does not support nested or quoted graphs. N3 and cwm[1] do though and I'm interested in implementing support for nested graphs to narrow the gap between rdflib and cwm[1] to help us converge on some interfaces. [1] http://www.w3.org/2000/10/swap/doc/cwm That's the formulae stuff? It seems pretty similar in effect to the reification approach, but a prettier spelling. Efficient generic indexing for either is probably a solved problem but not immediately evident to me. You also suggest moving away from reification in the following email; I'll respond to that separately, sometime this weekend hopefully. 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: Jim Fulton wrote: Jean-Marc Orliaguet wrote: in that case, using a portlet to display the poll results might not be the best solution, Right, but then what if, when displaying the poll results, I wanted to use some other portlet. Perhaps I have a portlet that lists the top 10 polls and I want to display that within the content well (inside the o wrap) when I display my results. If it's just a matter of visual layout, you only need to add a slot inside your theme just below or above the main-macroslot where you can put the poll portlet (main top, and main bottom slot) as you'd find in any zpt-based template. But then, I have to much with the theme just to get my page to come out the way I want. But, maybe it's not a good idea to use the same mechanisms for the o wrap and the content well. More on this later. Limiting portlets to master pages (o wrap) seems to me to be a needless and complicating limitation. Or maybe a good idea ... ... then the actual question is: why should a page in a zope3 application only display one view of an object at a time? i.e. the main view? when I read my mail I have 4 different views of my mailbox, not just the text contained in the mail ... Exactly. So, perhaps I have a mailbox. The main view for the mailbox uses 3 portlets: - a mailbox listing portlet - a portlet that lists all my mailboxes - a portlet that displays a selected message Why can't I specify these three portlets in the definition of my mailbox view? Why should I have to tease them into the master page? I'd like to be able to design my individual application pages and the master page independently. If I can only display portlets in master pages, then either: 1. I can't use them when designing individual application pages, or 2. I have to sneak the contents of my applications into the master pages, which seems to be a far more complicated model, conceptually, let alone computationally. Jim all you need to know when you design your application is the name of the slot in which the portlet will be displayed (right slot, left slot, etc.) This was already the case CMF's main_template.pt where slot names where hardcoded. then in a zcml declaration of the perspective you can specify the slot in which the portlet will be displayed. in some way you'll have to tell *where* the portlets will be located on the page, this is what you do with the "fill-slot" use-macro attribute But I want to control where the portlet will go in the content well, not in the o wrap. It could be argued that different mechanisms should be used for the o-wrap, content well, and end-user portlets (ala JSR 168). This gets back to Gary's point the other day that there are different actors and use cases that *could* be unified, but that maybe it's not a good idea to, from a UI perspective. Site designers define the o-wrap (possibly many). When they design the o wraps, they define the position of the content well and other portlets, and they can also define slots where content managers can place additional portlets. (I suppose an o wrap could define 0 or more content wells). Page designers (for specific applications) design pages that go in the content well (or maybe content wells). When designing the contents of the content well, they too might want a system that lets then combine page or content components (ala the email interface). Content managers have some UI for arranging portlets within slots. End users might have portlets that they can arrange within slots as well (ala JSR 168). (BTW, we find the use of the word portlets for JSR 168 portlets and for the things that site designers, page designers and content managers drag around to be pretty confusing.) Anyway, at this point, I think I understand the basics of CPSSkins, hopefully enough to think about your arguments for perspectives. I'll do that thinking and get back to you Monday. Have a good weekend. 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: > >> >> >> in that case, using a portlet to display the poll results might not be >> the best solution, > > > Right, but then what if, when displaying the poll results, I wanted to > use some > other portlet. Perhaps I have a portlet that lists the top 10 polls > and I want to display that within the content well (inside the > o wrap) when I display my results. > If it's just a matter of visual layout, you only need to add a slot inside your theme just below or above the main-macroslot where you can put the poll portlet (main top, and main bottom slot) as you'd find in any zpt-based template. not everything needs to be placed in the main O > Limiting portlets to master pages (o wrap) seems to me to be a needless > and complicating limitation. > > ... > >> then the actual question is: why should a page in a zope3 application >> only display one view of an object at a time? i.e. the main view? when I >> read my mail I have 4 different views of my mailbox, not just the text >> contained in the mail ... > > > Exactly. So, perhaps I have a mailbox. The main view for the mailbox > uses 3 portlets: > > - a mailbox listing portlet > > - a portlet that lists all my mailboxes > > - a portlet that displays a selected message > > Why can't I specify these three portlets in the definition of my > mailbox view? Why should I have to tease them into the master page? > > I'd like to be able to design my individual application pages > and the master page independently. If I can only display portlets > in master pages, then either: > > 1. I can't use them when designing individual application pages, or > > 2. I have to sneak the contents of my applications into the master pages, >which seems to be a far more complicated model, conceptually, let > alone >computationally. > > Jim > all you need to know when you design your application is the name of the slot in which the portlet will be displayed (right slot, left slot, etc.) This was already the case CMF's main_template.pt where slot names where hardcoded. then in a zcml declaration of the perspective you can specify the slot in which the portlet will be displayed. in some way you'll have to tell *where* the portlets will be located on the page, this is what you do with the "fill-slot" use-macro attribute independently of how the application is written, I don't see how to skip that part and if it's done in zcml then it's better than having it hardcoded in the page templates by all means... /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
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. I don't understand this. Does the application page use a theme page to render it's output, which then gets inserted into the o-wrap produced by another theme page? Or does it use a different o-wrap theme-page which includes the portlets it wants to be displayed? Or, put another way, which of the following strategies are used: Option 1. We render the master page (o wrap), which calls the view. The view then finds another theme page that has portlets it wants. The view renders this theme page and returns the result to the calling master page, which then renders the whole page. or Option 2: When we display the view, we select a different master page than the usual one. This special master page has portlets that the view wants to be displayed. or none of the above? :) Jim an application designer would have two choices: I guess these are both in the "none of the above" catagory. :) or both, given that they annihilate one another : -) 1) provide views just like any zope3 does already, and use cpsskins to decorate the page with portlets around the main view, very much like the current ZMI interface, with breadcrumbs, some navigation, some actions, with the difference that there is no need to write CSS since there is already a style editor that takes care of that. also the portlets can be moved on the canvas without touching any main_template.pt or zpt. But this doesn't let me use portlets in the main view. What if I wanted my results page in the poll example to use a particular portlet. Is there a way to do that? yes, but with: - a "poll results" portlet - some information that says when to show the portlet (cf perspectives) you'd need a "poll" perspective to control which portlets to display. the fact that the main area is taken by the macro-slot portlet with the risk that it will render the original template view is not a problem since you can place it inside a slot and turn it into a local portlet. from the "poll" perspective you'd decide not to display the main-macro portlet, since another portlet is taking care of displaying the results. 2) write portlets instead of views, that will be placed on a page as any portlet would. One could write an XForm rendering portlet (Julien is working on something like this), or a document portlet that renders some document, etc.. but then we get back to the original subject of the discussion: once you have application specific portlets, you need to introduce the notion of perspective (or contextual usage) otherwise you won't be able to know when to display them. for instance it is OK to display an action portlet on every screen of a portal because there will always be an action to show and action items are highly contextual, but for some portlets or groups of portlets that are too specifically tied to a given activity in the application, this won't do. remember that unlike the objects in no portlets is associated to object types, portlets are associated to cells (global portlets) or to slots (local portlets) So the idea behind perspectives (as in Eclipse SDK) is to create a sort of contextual usage but for local portlets that can be used by the application to update the interface according to the current activity of the user. So, my results page, instead of being a normal view is a portlet. Suppose that my original goal in my results page was to display the results along with some other portlet. Now, I split my results page into a portlet that I wanted to display and the original portlet that I wanted to display. Now, I have to somehow, through perspectives or some rule-based approach arrange to have my to portlets displayed in the two desired places on the page. This sounds like a very round-about way to just display a page with a portlet. Jim in that case, using a portlet to display the poll results might not be the best solution, Right, but then what if, when displaying the poll results, I wanted to use some other portlet. Perhaps I have a portlet that lists the top 10 polls and I want to display that within the content well (inside the o wrap) when I display my results. Limiting portlets to master pages (o wrap) seems to me to be a needless and complicating limitation. ... then the actual question is: why should a page in a zope3 application only display one view of an object at a time? i.e. the main view? when I read my mail I have 4 different views of my mailbox, not just the text contained in the mail ... Exa
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. >>> >>> >>> >>> I don't understand this. Does the application page use a theme page >>> to render it's output, which then gets inserted into the o-wrap >>> produced >>> by another theme page? Or does it use a different o-wrap theme-page >>> which includes the portlets it wants to be displayed? >>> >>> Or, put another way, which of the following strategies are used: >>> >>> Option 1. >>> >>> We render the master page (o wrap), which calls the view. The view >>> then >>> finds another theme page that has portlets it wants. The view renders >>> this theme page and returns the result to the calling master page, >>> which then >>> renders the whole page. >>> >>> or >>> >>> Option 2: >>> >>> When we display the view, we select a different master page than the >>> usual >>> one. This special master page has portlets that the view wants to >>> be displayed. >>> >>> or none of the above? :) >>> >>> Jim >>> >> >> >> an application designer would have two choices: > > > I guess these are both in the "none of the above" catagory. :) > > or both, given that they annihilate one another : -) >> 1) provide views just like any zope3 does already, and use cpsskins to >> decorate the page with portlets around the main view, very much like the >> current ZMI interface, with breadcrumbs, some navigation, some actions, >> with the difference that there is no need to write CSS since there is >> already a style editor that takes care of that. >> also the portlets can be moved on the canvas without touching any >> main_template.pt or zpt. > > > But this doesn't let me use portlets in the main view. What if I > wanted my results page in the poll example to use a particular portlet. > Is there a way to do that? yes, but with: - a "poll results" portlet - some information that says when to show the portlet (cf perspectives) you'd need a "poll" perspective to control which portlets to display. the fact that the main area is taken by the macro-slot portlet with the risk that it will render the original template view is not a problem since you can place it inside a slot and turn it into a local portlet. from the "poll" perspective you'd decide not to display the main-macro portlet, since another portlet is taking care of displaying the results. > >> 2) write portlets instead of views, that will be placed on a page as any >> portlet would. One could write an XForm rendering portlet (Julien is >> working on something like this), or a document portlet that renders some >> document, etc.. >> >> but then we get back to the original subject of the discussion: once >> you have application specific portlets, you need to introduce the notion >> of perspective (or contextual usage) otherwise you won't be able to know >> when to display them. >> >> for instance it is OK to display an action portlet on every screen of a >> portal because there will always be an action to show and action items >> are highly contextual, but for some portlets or groups of portlets that >> are too specifically tied to a given activity in the application, this >> won't do. >> >> remember that unlike the objects in no portlets is >> associated to object types, portlets are associated to cells (global >> portlets) or to slots (local portlets) >> >> So the idea behind perspectives (as in Eclipse SDK) is to create a sort >> of contextual usage but for local portlets that can be used by the >> application to update the interface according to the current activity of >> the user. > > > So, my results page, instead of being a normal view is a portlet. > Suppose > that my original goal in my results page was to display the results along > with some other portlet. Now, I split my results page into a portlet > that I wanted to display and the original portlet that I wanted to > display. > Now, I have to somehow, through perspectives or some rule-based approach > arrange to have my to portlets displayed in the two desired places on > the page. > This sounds like a very round-about way to just display a page with a > portlet. > > Jim > in that case, using a portlet to display the poll results might not be the best solution, but in case you'd want to display the poll result on the front page of your site, you'd have no choice but to use a portlet. then the actual question is: why should a page in a zope3 application only display one view of an object at a time? i.e. the main view? when I read my mail I have 4 different views of my mailbox, no
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: it would not be concerned with index.html / report.html / edit.html AT ALL. you would just place a "Main Content Portlet" in the middle of the page and let the application underneath take care of rendering the poll screens. cf http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py the portlet renders the current view that gets inserted it into the theme at the location of the portlet. Let me try to rephrase this: The portlet renders the current view. It renders it into the location of the portlet within the theme-defined page. :) yes Where does it get the current view? Is it normally passed in? By whom? from the original theme renderer's template.pt (associated to the cpsskins skin). It gets propagated all the way from the view to the portlet, through the page, cells, etc. as a keyword parameter that the renderer can use at any time. the orginal context is also propagated. cf. in http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/skin/template.pt There are some details here I don't understand, but I'll skip those for now yes, inside the theme you leave a "window area" to display views from the application you're designing a theme for. You can use the zwiki application under cpsskins already, although cpsskins knows nothing about wiki pages. OK, I get it. So this this is all about defining what Tres likes to call the "O wrap". The stuff that is drawn around the application generated markuo and that, through CSS styles, images, etc, has some influence on how the markup is displayed. yes, CPSSkins was created from the beginning as a simple replacement of main_template before all the theme / page distinctions were introduced. the breakthrough difference in the zope3 version is that the main content area (inside the O wrap) can be rendered directly in python. So, what if I wanted to use portlets within one of my application views? Does CPSSkins let me do that too? Jim yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. I don't understand this. Does the application page use a theme page to render it's output, which then gets inserted into the o-wrap produced by another theme page? Or does it use a different o-wrap theme-page which includes the portlets it wants to be displayed? Or, put another way, which of the following strategies are used: Option 1. We render the master page (o wrap), which calls the view. The view then finds another theme page that has portlets it wants. The view renders this theme page and returns the result to the calling master page, which then renders the whole page. or Option 2: When we display the view, we select a different master page than the usual one. This special master page has portlets that the view wants to be displayed. or none of the above? :) 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: Jim Fulton wrote: Jean-Marc Orliaguet wrote: yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. I don't understand this. Does the application page use a theme page to render it's output, which then gets inserted into the o-wrap produced by another theme page? Or does it use a different o-wrap theme-page which includes the portlets it wants to be displayed? Or, put another way, which of the following strategies are used: Option 1. We render the master page (o wrap), which calls the view. The view then finds another theme page that has portlets it wants. The view renders this theme page and returns the result to the calling master page, which then renders the whole page. or Option 2: When we display the view, we select a different master page than the usual one. This special master page has portlets that the view wants to be displayed. or none of the above? :) Jim an application designer would have two choices: I guess these are both in the "none of the above" catagory. :) 1) provide views just like any zope3 does already, and use cpsskins to decorate the page with portlets around the main view, very much like the current ZMI interface, with breadcrumbs, some navigation, some actions, with the difference that there is no need to write CSS since there is already a style editor that takes care of that. also the portlets can be moved on the canvas without touching any main_template.pt or zpt. But this doesn't let me use portlets in the main view. What if I wanted my results page in the poll example to use a particular portlet. Is there a way to do that? 2) write portlets instead of views, that will be placed on a page as any portlet would. One could write an XForm rendering portlet (Julien is working on something like this), or a document portlet that renders some document, etc.. but then we get back to the original subject of the discussion: once you have application specific portlets, you need to introduce the notion of perspective (or contextual usage) otherwise you won't be able to know when to display them. for instance it is OK to display an action portlet on every screen of a portal because there will always be an action to show and action items are highly contextual, but for some portlets or groups of portlets that are too specifically tied to a given activity in the application, this won't do. remember that unlike the objects in no portlets is associated to object types, portlets are associated to cells (global portlets) or to slots (local portlets) So the idea behind perspectives (as in Eclipse SDK) is to create a sort of contextual usage but for local portlets that can be used by the application to update the interface according to the current activity of the user. So, my results page, instead of being a normal view is a portlet. Suppose that my original goal in my results page was to display the results along with some other portlet. Now, I split my results page into a portlet that I wanted to display and the original portlet that I wanted to display. Now, I have to somehow, through perspectives or some rule-based approach arrange to have my to portlets displayed in the two desired places on the page. This sounds like a very round-about way to just display a page with a portlet. 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, these would be application-specific portlets, as the ones used in a >> calendar application for instance showing a monthly agenda. The portlet >> gets access to the current view object, to the current page location >> (renamed from 'context_obj' to 'location'). So as soon as you can >> produce some data from that you have a portlet that can be put inside a >> theme page. > > > I don't understand this. Does the application page use a theme page > to render it's output, which then gets inserted into the o-wrap produced > by another theme page? Or does it use a different o-wrap theme-page > which includes the portlets it wants to be displayed? > > Or, put another way, which of the following strategies are used: > > Option 1. > > We render the master page (o wrap), which calls the view. The view > then > finds another theme page that has portlets it wants. The view renders > this theme page and returns the result to the calling master page, > which then > renders the whole page. > > or > > Option 2: > > When we display the view, we select a different master page than the > usual > one. This special master page has portlets that the view wants to > be displayed. > > or none of the above? :) > > Jim > an application designer would have two choices: 1) provide views just like any zope3 does already, and use cpsskins to decorate the page with portlets around the main view, very much like the current ZMI interface, with breadcrumbs, some navigation, some actions, with the difference that there is no need to write CSS since there is already a style editor that takes care of that. also the portlets can be moved on the canvas without touching any main_template.pt or zpt. 2) write portlets instead of views, that will be placed on a page as any portlet would. One could write an XForm rendering portlet (Julien is working on something like this), or a document portlet that renders some document, etc.. but then we get back to the original subject of the discussion: once you have application specific portlets, you need to introduce the notion of perspective (or contextual usage) otherwise you won't be able to know when to display them. for instance it is OK to display an action portlet on every screen of a portal because there will always be an action to show and action items are highly contextual, but for some portlets or groups of portlets that are too specifically tied to a given activity in the application, this won't do. remember that unlike the objects in no portlets is associated to object types, portlets are associated to cells (global portlets) or to slots (local portlets) So the idea behind perspectives (as in Eclipse SDK) is to create a sort of contextual usage but for local portlets that can be used by the application to update the interface according to the current activity of the user. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Catalog improvements
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. -- Dieter ___ 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: > >> >> it would not be concerned with index.html / report.html / edit.html >> AT ALL. >> >> you would just place a "Main Content Portlet" in the middle of the page >> and let the application underneath take care of rendering the poll >> screens. >> >> cf >> http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py >> >> the portlet renders the current view that gets inserted it into the >> theme at the location of the portlet. > > > Let me try to rephrase this: The portlet renders the current view. > It renders it into the location of the portlet within the theme-defined > page. :) > yes > Where does it get the current view? Is it normally passed in? By whom? from the original theme renderer's template.pt (associated to the cpsskins skin). It gets propagated all the way from the view to the portlet, through the page, cells, etc. as a keyword parameter that the renderer can use at any time. the orginal context is also propagated. cf. in http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/skin/template.pt >> >> yes, inside the theme you leave a "window area" to display views from >> the application you're designing a theme for. You can use the zwiki >> application under cpsskins already, although cpsskins knows nothing >> about wiki pages. > > > OK, I get it. So this this is all about defining what Tres likes to > call the "O wrap". The stuff that is drawn around the application > generated markuo and that, through CSS styles, images, etc, has > some influence on how the markup is displayed. > yes, CPSSkins was created from the beginning as a simple replacement of main_template before all the theme / page distinctions were introduced. the breakthrough difference in the zope3 version is that the main content area (inside the O wrap) can be rendered directly in python. > So, what if I wanted to use portlets within one of my application > views? Does CPSSkins let me do that too? > > Jim > yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. it is not recommended to render portlets directly in HTML though (except for the main content portlet), since cpsskins takes care of formatting and displaying the data using widgets. /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
Jean-Marc Orliaguet wrote: Jim Fulton wrote: ... Lets say I have a content object, say a poll. Now, I want that poll to have a number of pages: - index.html This page displays the poll question and collects input. If the user has already taken the poll, it indicates as much and initializes the input to their previous answer. If they submit input, it overrides their old input with their new input. - report.html shows poll results - edit.html allows the poll question to be edited. Now, How would I create these pages with CPSSkins? it would not be concerned with index.html / report.html / edit.html AT ALL. you would just place a "Main Content Portlet" in the middle of the page and let the application underneath take care of rendering the poll screens. cf http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py the portlet renders the current view that gets inserted it into the theme at the location of the portlet. Let me try to rephrase this: The portlet renders the current view. It renders it into the location of the portlet within the theme-defined page. :) Where does it get the current view? Is it normally passed in? By whom? cpsskins does not do form rendering, document editing, or such things that are already done with page templates. the rendering of such pages is delegated to the application for instance. Do I define each of these pages in a theme? you don't, you only put a single portlet in the middle of the theme page that will render them, as a main macro-slot would do. Or, perhaps, the theme pages are only used to provide a a master page with a space for rendering individual page content. Are theme pages used like page macros in Zope 3 or like Zope2's standard_template? Jim yes, inside the theme you leave a "window area" to display views from the application you're designing a theme for. You can use the zwiki application under cpsskins already, although cpsskins knows nothing about wiki pages. OK, I get it. So this this is all about defining what Tres likes to call the "O wrap". The stuff that is drawn around the application generated markuo and that, through CSS styles, images, etc, has some influence on how the markup is displayed. So, what if I wanted to use portlets within one of my application views? Does CPSSkins let me do that too? 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: > >> Jim Fulton wrote: >> > ... > >>> Not quite, AFAICT. browser:page actually defines a page (e.g. >>> "foo.html") >>> relative to an object type. >> >> >> >> >> yes, but the object type is independent of the URL too, just like a >> theme page says nothing about what it will be applied to... > > > But browser:page *does* specify the object type. When I use browser:page > to define foo.html for IContact objects, I am causing contacts to have > that > page and not impacting any non-contact objects. ok, if you mean that a page in cpsskins is not concerned about what object it will be associated with, then that's true. however the association will have to be done in some way, otherwise only the default page will always be displayed. So the difference is that cpsskins separates the declaration of the page from the context in which the page will be used. but the page will still have to be associated with some IContact, or with some part of the site, or with anything that can be associated with it otherwise it will never get a chance to be displayed. > >> >> >> it's not implemented yet in the Zope3 version (the only thing there is >> currently effective is the default page), I'd like this feature to be >> pluggable like the ISkin way of choosing a skin. >> >> in the zope2 version there are 5 or 6 ways of setting the page as >> described in: >> http://www.medic.chalmers.se/~jmo/CPS/CPSSkins-Book.pdf >> >> under the chapter: >> "USING SEVERAL THEMES INSIDE THE SAME PORTAL" >> >> in any case, there is no hardcoded link between pages and the content of >> the site. > > > I'm sorry, I still don't understand. > > Lets say I have a content object, say a poll. Now, I want that > poll to have a number of pages: > > - index.html > > This page displays the poll question and collects input. > If the user has already taken the poll, it indicates as much > and initializes the input to their previous answer. If they > submit input, it overrides their old input with their new input. > > - report.html shows poll results > > - edit.html allows the poll question to be edited. > > Now, How would I create these pages with CPSSkins? > it would not be concerned with index.html / report.html / edit.html AT ALL. you would just place a "Main Content Portlet" in the middle of the page and let the application underneath take care of rendering the poll screens. cf http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py the portlet renders the current view that gets inserted it into the theme at the location of the portlet. cpsskins does not do form rendering, document editing, or such things that are already done with page templates. the rendering of such pages is delegated to the application for instance. > Do I define each of these pages in a theme? > you don't, you only put a single portlet in the middle of the theme page that will render them, as a main macro-slot would do. > Or, perhaps, the theme pages are only used to provide a > a master page with a space for rendering individual page > content. Are theme pages used like page macros in Zope 3 > or like Zope2's standard_template? > > Jim yes, inside the theme you leave a "window area" to display views from the application you're designing a theme for. You can use the zwiki application under cpsskins already, although cpsskins knows nothing about wiki pages. /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
Jean-Marc Orliaguet wrote: Jim Fulton wrote: ... Not quite, AFAICT. browser:page actually defines a page (e.g. "foo.html") relative to an object type. yes, but the object type is independent of the URL too, just like a theme page says nothing about what it will be applied to... But browser:page *does* specify the object type. When I use browser:page to define foo.html for IContact objects, I am causing contacts to have that page and not impacting any non-contact objects. it is more like a browser page than a site's page in any case.. i.e. a page that you see in your browser, the same "page" as in "PageMaker", a canvas, a template, etc.. I don't understand this. By "browser page", do you mean it is like a page as defined by the zcml browser:page directive? Or like a page that is displayed in a browser? I mean, in the sense that the page applies to a whole class of things, not to a particular individual instanciated object in the site. I think this is a critival point. When I visit a URL on a section, say: .../mysection/foo.html what determines which theme page is used? there is a negociation, a default theme page to fall back to, but you can specify the page to use in many ways; through a URL parameter, ?page=frontpage, through a cookie, through a session variable, by adding a subscriber to IBeforeTraverse and set the page to a "calendar" page if you enter a part of the site that has to doing with calendaring application... Does the page ever depend on the thing being traversed? Is there a point where you'd say: "when traversing an IBar with the name foo.html, use the theme page named 'splat'"? it would be the application's responsibility to override the default page to use, as it is done with the default skin. I think that schoolbell calendar application does that when the user enters a calendar application site. it is very much like skin negociation, there is a page used by default, but it can be changed on-the-fly. I'm having a hard time understanding the relationship between objects, URLs and theme pages. Jim it's not implemented yet in the Zope3 version (the only thing there is currently effective is the default page), I'd like this feature to be pluggable like the ISkin way of choosing a skin. in the zope2 version there are 5 or 6 ways of setting the page as described in: http://www.medic.chalmers.se/~jmo/CPS/CPSSkins-Book.pdf under the chapter: "USING SEVERAL THEMES INSIDE THE SAME PORTAL" in any case, there is no hardcoded link between pages and the content of the site. I'm sorry, I still don't understand. Lets say I have a content object, say a poll. Now, I want that poll to have a number of pages: - index.html This page displays the poll question and collects input. If the user has already taken the poll, it indicates as much and initializes the input to their previous answer. If they submit input, it overrides their old input with their new input. - report.html shows poll results - edit.html allows the poll question to be edited. Now, How would I create these pages with CPSSkins? Do I define each of these pages in a theme? Or, perhaps, the theme pages are only used to provide a a master page with a space for rendering individual page content. Are theme pages used like page macros in Zope 3 or like Zope2's standard_template? 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: > >> >> a page has a "template" like a Zope Page Template, that would correspond >> to the idea of layout. > > > Sure, but It still seems that a "theme page" fills the same role as a > template, in that it is meant to be used for many different page. > > Let me put this another way. When you define a theme page, you aren't > saying anything about URLs. > exactly, the page <-> URL associating is done later on during page rendering. There could be a page <-> view association too, or a page <-> hour of the day association,.. >> >> it's as unfortunate as a name as the directive that is >> associated to a browser view, and a page template. But the idea is >> the same. > > > Not quite, AFAICT. browser:page actually defines a page (e.g. > "foo.html") > relative to an object type. yes, but the object type is independent of the URL too, just like a theme page says nothing about what it will be applied to... > >> it is more like a browser page than a site's page in any case.. i.e. a >> page that you see in your browser, the same "page" as in "PageMaker", a >> canvas, a template, etc.. > > > I don't understand this. By "browser page", do you mean it is like > a page as defined by the zcml browser:page directive? Or like a > page that is displayed in a browser? > I mean, in the sense that the page applies to a whole class of things, not to a particular individual instanciated object in the site. >> >>> I think this is a critival point. When I visit a URL on a section, >>> say: >>> >>> .../mysection/foo.html >>> >>> what determines which theme page is used? >>> >> >> >> there is a negociation, a default theme page to fall back to, but you >> can specify the page to use in many ways; through a URL parameter, >> ?page=frontpage, through a cookie, through a session variable, by adding >> a subscriber to IBeforeTraverse and set the page to a "calendar" page if >> you enter a part of the site that has to doing with calendaring >> application... > > > Does the page ever depend on the thing being traversed? Is there > a point where you'd say: > > "when traversing an IBar with the name foo.html, use the theme page >named 'splat'"? > it would be the application's responsibility to override the default page to use, as it is done with the default skin. I think that schoolbell calendar application does that when the user enters a calendar application site. it is very much like skin negociation, there is a page used by default, but it can be changed on-the-fly. > I'm having a hard time understanding the relationship between > objects, URLs and theme pages. > > Jim > it's not implemented yet in the Zope3 version (the only thing there is currently effective is the default page), I'd like this feature to be pluggable like the ISkin way of choosing a skin. in the zope2 version there are 5 or 6 ways of setting the page as described in: http://www.medic.chalmers.se/~jmo/CPS/CPSSkins-Book.pdf under the chapter: "USING SEVERAL THEMES INSIDE THE SAME PORTAL" in any case, there is no hardcoded link between pages and the content of the site. /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
Jean-Marc Orliaguet wrote: Jean-Marc Orliaguet wrote: a page has a "template" like a Zope Page Template, that would correspond to the idea of layout. it's as unfortunate as a name as the directive that is associated to a browser view, and a page template. But the idea is the same. it is more like a browser page than a site's page in any case.. i.e. a page that you see in your browser, the same "page" as in "PageMaker", a canvas, a template, etc.. exactly as it says on the PageMaker product website, actually """Quickly lay out publications by creating frames to hold text and graphics, applying master pages to apply different page designs within a single publication, and using layers to set up a single file for multiple versions of a publication.""" cf. http://www.adobe.com/products/pagemaker/overview.html the term "master page" is less ambiguous maybe. But it's definitely not a page in the sense of "the concrete page of a book", but instead the design, the form of a page of a book, that by extension became "the front page", the "chapter page". If you work with content it definitely means a different thing. OK, so a theme page is like a master page? 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: Jim Fulton wrote: Hi Jim, here are the concepts defined: It's too bad these aren't defined in a more perminent and referenceable location. - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you see that sites are using different themes. The includes, colors, styles, icons, etc. - Inside a same theme there are *pages*, pages use the styles defined in the theme, but the layout may be different (3 columns -> 2 columns) from one page to another. The rationale is that when you create a new page, you want to be able to reuse the same styles. typically there is: the front page, the section page, the login page ... A page, as defined here, seems to be a template, as opposed to a page with a particular URL. I take it all section index.html pages use the same theme pages. The use of the term "page" here seems unfortunate. If a section has a page for searching, would that also use the section page from the theme? Or would that use some other theme page? a page has a "template" like a Zope Page Template, that would correspond to the idea of layout. Sure, but It still seems that a "theme page" fills the same role as a template, in that it is meant to be used for many different page. Let me put this another way. When you define a theme page, you aren't saying anything about URLs. it's as unfortunate as a name as the directive that is associated to a browser view, and a page template. But the idea is the same. Not quite, AFAICT. browser:page actually defines a page (e.g. "foo.html") relative to an object type. it is more like a browser page than a site's page in any case.. i.e. a page that you see in your browser, the same "page" as in "PageMaker", a canvas, a template, etc.. I don't understand this. By "browser page", do you mean it is like a page as defined by the zcml browser:page directive? Or like a page that is displayed in a browser? I think this is a critival point. When I visit a URL on a section, say: .../mysection/foo.html what determines which theme page is used? there is a negociation, a default theme page to fall back to, but you can specify the page to use in many ways; through a URL parameter, ?page=frontpage, through a cookie, through a session variable, by adding a subscriber to IBeforeTraverse and set the page to a "calendar" page if you enter a part of the site that has to doing with calendaring application... Does the page ever depend on the thing being traversed? Is there a point where you'd say: "when traversing an IBar with the name foo.html, use the theme page named 'splat'"? I'm having a hard time understanding the relationship between objects, URLs and theme 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: > >a page has a "template" like a Zope Page Template, that would correspond >to the idea of layout. > >it's as unfortunate as a name as the directive that is >associated to a browser view, and a page template. But the idea is the same. > >it is more like a browser page than a site's page in any case.. i.e. a >page that you see in your browser, the same "page" as in "PageMaker", a >canvas, a template, etc.. > > > exactly as it says on the PageMaker product website, actually """Quickly lay out publications by creating frames to hold text and graphics, applying master pages to apply different page designs within a single publication, and using layers to set up a single file for multiple versions of a publication.""" cf. http://www.adobe.com/products/pagemaker/overview.html the term "master page" is less ambiguous maybe. But it's definitely not a page in the sense of "the concrete page of a book", but instead the design, the form of a page of a book, that by extension became "the front page", the "chapter page". If you work with content it definitely means a different thing. /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: >> >> Hi Jim, here are the concepts defined: > > > It's too bad these aren't defined in a more perminent and referenceable > location. > >> - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you >> see that sites are using different themes. The includes, colors, styles, >> icons, etc. > > > > >> - Inside a same theme there are *pages*, pages use the styles defined in >> the theme, but the layout may be different (3 columns -> 2 columns) from >> one page to another. The rationale is that when you create a new page, >> you want to be able to reuse the same styles. >> >>typically there is: the front page, the section page, the login >> page ... > > > A page, as defined here, seems to be a template, as opposed to a page > with > a particular URL. I take it all section index.html pages use the same > theme pages. The use of the term "page" here seems unfortunate. If a > section > has a page for searching, would that also use the section page from > the theme? > Or would that use some other theme page? > a page has a "template" like a Zope Page Template, that would correspond to the idea of layout. it's as unfortunate as a name as the directive that is associated to a browser view, and a page template. But the idea is the same. it is more like a browser page than a site's page in any case.. i.e. a page that you see in your browser, the same "page" as in "PageMaker", a canvas, a template, etc.. > I think this is a critival point. When I visit a URL on a section, say: > > .../mysection/foo.html > > what determines which theme page is used? > there is a negociation, a default theme page to fall back to, but you can specify the page to use in many ways; through a URL parameter, ?page=frontpage, through a cookie, through a session variable, by adding a subscriber to IBeforeTraverse and set the page to a "calendar" page if you enter a part of the site that has to doing with calendaring application... >> - a *section* of a site is not specific to cpsskins, it can be a folder, >> a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc. >> >> - *cells* are layout elements in a page that could be also called >> "columns", the left column can contain navigation portlets, the right >> column can contain ads, the main column usually the document being >> looked at. > > > So a single cell can contain multiple portlets? yes > I assume that they need not > be layed out soley in columns. > if the portlets are to be presented horizontally then it's the cell's layout that takes over. The notion of cell is about logical containment not about presentation, however cells have a layout. Cell elements need a view to be displayed that involves the cell's layout. with a text renderer the cell is the same, but the cell's rendering is different from the one of a web browser. >> - *global portlets* are part of a page, they are placed in cells. i.e. >> if a page is displayed and the portlet is in the page, then the portlet >> will be displayed. Typically global portlets are: the logotype, some >> navigation portlet. Only theme designers can manage global portlets. >> They make the theme's skeleton. > > > So a theme page has some cells that are each filed with 0 or more > global portlets? yes > >> - *slots* are placeholders that can contain portlets. A theme designer >> will add slots to a theme, but it's not up to him/her to define which >> portlets will be displayed in the slot. The theme design will decide >> what style the portlets inside the slots will have. > > > Is a slot a kind of portlet? from the cell's perspective yes, in the sense that it is contained in the cell like global portlets. but if you compare slots and portlets then no it's not a portlet, a slot refers to portlets, and a slot without portlets to refer to will not display anything. however the portlets inherit the format properties associated to slots. so you can see slots as a collection of portlets that share properties. > Does a slot go into a cell? yes, like global portlets > Do pages contain both slots and cells? Or do pages contain > cells, which can contain either slots or global portlets? pages contain cells, that contain global portlets, or that contain slots that refer to local portlets slots and global portlets can be found inside a same cell > >> - local portlets are placed in slots by the users themselves. > > > > >> here is an illustration: >> >> on the chalmers website here is the front page: >> - http://www.medic.chalmers.se/~jmo/Zope3/chalmers-1.png >> >> here is the same page with the slots, global portlets and local portlets >> shown: >> - http://www.medic.chalmers.se/~jmo/Zope3/chalmers.png >> >> - global portlets are represented in orange, no user that is not theme >> designer is allowed to modify them >> - the slots are represented by areas with a red border. >> - the local portlets are represented in violet. users who work with >> content can modify the
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). I'd like to make some substantive comments on the proposal. My initial reaction is that the solution proposed is very complex and I'm not at all clear about the problem it solves. :) I think I need to understand how themes work in CPS skins. In particular, I need to understand the relationships between themes, pages, sections, cells, global portlets and local portlets. Your proposal is based on but doesn't really describe most of these concepts. Can you recommnd some documentation? Jim Hi Jim, here are the concepts defined: It's too bad these aren't defined in a more perminent and referenceable location. - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you see that sites are using different themes. The includes, colors, styles, icons, etc. > - Inside a same theme there are *pages*, pages use the styles defined in the theme, but the layout may be different (3 columns -> 2 columns) from one page to another. The rationale is that when you create a new page, you want to be able to reuse the same styles. typically there is: the front page, the section page, the login page ... A page, as defined here, seems to be a template, as opposed to a page with a particular URL. I take it all section index.html pages use the same theme pages. The use of the term "page" here seems unfortunate. If a section has a page for searching, would that also use the section page from the theme? Or would that use some other theme page? I think this is a critival point. When I visit a URL on a section, say: .../mysection/foo.html what determines which theme page is used? - a *section* of a site is not specific to cpsskins, it can be a folder, a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc. - *cells* are layout elements in a page that could be also called "columns", the left column can contain navigation portlets, the right column can contain ads, the main column usually the document being looked at. So a single cell can contain multiple portlets? I assume that they need not be layed out soley in columns. - *global portlets* are part of a page, they are placed in cells. i.e. if a page is displayed and the portlet is in the page, then the portlet will be displayed. Typically global portlets are: the logotype, some navigation portlet. Only theme designers can manage global portlets. They make the theme's skeleton. So a theme page has some cells that are each filed with 0 or more global portlets? - *slots* are placeholders that can contain portlets. A theme designer will add slots to a theme, but it's not up to him/her to define which portlets will be displayed in the slot. The theme design will decide what style the portlets inside the slots will have. Is a slot a kind of portlet? Does a slot go into a cell? Do pages contain both slots and cells? Or do pages contain cells, which can contain either slots or global portlets? - local portlets are placed in slots by the users themselves. > here is an illustration: on the chalmers website here is the front page: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers-1.png here is the same page with the slots, global portlets and local portlets shown: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers.png - global portlets are represented in orange, no user that is not theme designer is allowed to modify them - the slots are represented by areas with a red border. - the local portlets are represented in violet. users who work with content can modify them and add new ones into the slots. here the template uses with Chalmers institutions: - http://www.medic.chalmers.se/~jmo/Zope3/tme.png content creators can only add content inside the predefined slots, which guarantees that the graphic profile is preserved. Ah, so the "users" you are refering to are the content managers, not the end users (site visitors) of the system? What problem perspectives solves? -- I'd respond to this section later once I'm sure I understand the basic concepts and terminology. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]
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). > > > I'd like to make some substantive comments on the proposal. My initial > reaction is that the solution proposed is very complex and I'm not at all > clear about the problem it solves. :) > > I think I need to understand how themes work in CPS skins. In > particular, > I need to understand the relationships between themes, pages, sections, > cells, global portlets and local portlets. Your proposal is based on > but doesn't really describe most of these concepts. Can you recommnd > some documentation? > > Jim > Hi Jim, here are the concepts defined: - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you see that sites are using different themes. The includes, colors, styles, icons, etc. - Inside a same theme there are *pages*, pages use the styles defined in the theme, but the layout may be different (3 columns -> 2 columns) from one page to another. The rationale is that when you create a new page, you want to be able to reuse the same styles. typically there is: the front page, the section page, the login page ... - a *section* of a site is not specific to cpsskins, it can be a folder, a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc. - *cells* are layout elements in a page that could be also called "columns", the left column can contain navigation portlets, the right column can contain ads, the main column usually the document being looked at. - *global portlets* are part of a page, they are placed in cells. i.e. if a page is displayed and the portlet is in the page, then the portlet will be displayed. Typically global portlets are: the logotype, some navigation portlet. Only theme designers can manage global portlets. They make the theme's skeleton. - *slots* are placeholders that can contain portlets. A theme designer will add slots to a theme, but it's not up to him/her to define which portlets will be displayed in the slot. The theme design will decide what style the portlets inside the slots will have. - local portlets are placed in slots by the users themselves. here is an illustration: on the chalmers website here is the front page: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers-1.png here is the same page with the slots, global portlets and local portlets shown: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers.png - global portlets are represented in orange, no user that is not theme designer is allowed to modify them - the slots are represented by areas with a red border. - the local portlets are represented in violet. users who work with content can modify them and add new ones into the slots. here the template uses with Chalmers institutions: - http://www.medic.chalmers.se/~jmo/Zope3/tme.png content creators can only add content inside the predefined slots, which guarantees that the graphic profile is preserved. What problem perspectives solves? -- local portlets are currently stored in local folders in a .cps_portlets container with the name of the slot in which they are located. 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. 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. 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. In an application, this makes it possible to keep the portlets used by the application (action portlets, navigation portlets) separate from deco
[Zope3-dev] security problems with database adapters (second edition)
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') 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. 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 ? Regards, Velko Ivanov ___ 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). I'd like to make some substantive comments on the proposal. My initial reaction is that the solution proposed is very complex and I'm not at all clear about the problem it solves. :) I think I need to understand how themes work in CPS skins. In particular, I need to understand the relationships between themes, pages, sections, cells, global portlets and local portlets. Your proposal is based on but doesn't really describe most of these concepts. Can you recommnd some documentation? 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] Re: Zope3-dev Digest, Vol 25, Issue 37
[Benji York] > ... > We're drifting fatally off topic here, but: Just as there are some > statements that cannot be expressed as dyadic predicates, are there also > those which cannot be expressed as triadic predicates? > > "John gives a book to Mary in exchange for 5 euros" > > If you store the relations "John gives a book to Mary" and "Mary gives 5 > euros to John" how will you know that the 5 euros were payment for the book? Worse, this happened on a Sunday, in Brussels, while winds were gusting from the south, and a nearby solicitor wearing a lime green bowler hat advised them that their transaction was exempt from VAT ;-) Even allowing relations of arbitrary arity, there are some kinds of knowledge that can't be expressed in full-blown first-order logic. For example, Google will find lots of (mostly tedious ) discussion of the Geach-Kaplan sentence: Some critics admire only one another. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] file objects and formlib
Fred Drake wrote: On 8/26/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: I just saw this being changed in the wiki (by Fred Drake): the new zope.formlib. - -- Reimplement file objects (for Zope 2 or Zope 3 to take advantage of the new 'zope.formlib' I just tweaked the wording a bit and added the missing ")"; someone else added the item (Jim?). Not 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: Re[2]: [Zope3-dev] problems with
Hi Adam > Behalf Of Adam Groszer > Sent: Friday, August 26, 2005 3:24 PM > To: Dominik Huber > Cc: zope3-dev > Subject: Re[2]: [Zope3-dev] problems with > > Dear Dominik, > > I implemeted what you told me, but I'm still out of luck. > (The szerep/szemely mistake as noticed by Dylan Reinhardt was mine, > but you got the real problem. > > class ISzemely(Interface): > ... > szerepek = List( > title=u"Hozzarendelt szerepek", > description=u"Hozzarendelt szerepek", > required=False, > value_type=Choice(vocabulary="szerep") > ) > ) > [snip] > > The exception is a little bit different, but the end result is the > same. > > ... > Module zope.interface.adapter, line 481, in queryMultiAdapter > return factory(*objects) > Module zope.app.form.browser.editview, line 64, in __init__ > self._setUpWidgets() > Module zope.app.form.browser.add, line 49, in _setUpWidgets > setUpWidgets(self, self.schema, IInputWidget, > names=self.fieldNames) > Module zope.app.form.utility, line 153, in setUpWidgets > context=context) > Module zope.app.form.utility, line 101, in setUpWidget > widget = widget(field.bind(context), view.request) > Module zope.app.form, line 97, in __call__ > instance = self._widget_factory(*args) > Module zope.app.form, line 97, in __call__ > instance = self._widget_factory(*args) > TypeError: __init__() takes exactly 4 arguments (3 given) > > As I checked the worldcookery example it does not use a factory either > and it is working fine. > > > Wednesday, August 24, 2005, 4:01:07 PM, you wrote: > > DH> Adam Groszer wrote: > > >>I'm having problems with using . > >> > >>I have an interface: > >>class ISzerep(Interface): > >>name = TextLine( > >>title=u"Szerep nev", > >>description=u"Szerep nev", > >>required=True > >>) > >>szemelyek = List( > >>title=u"Hozzarendelt szemelyek", > >>description=u"Hozzarendelt szemelyek", > >>required=False, > >>value_type=Choice(vocabulary="szemely") > >>) > >> > >>If I add a simple add (or edit) form: > >> >> schema="szscreen.interfaces.ISzemely" > >> content_factory="szscreen.app.Szemely" > >> label="Uj Szemely" > >> name="AddSzemely.html" > >> permission="zope.ManageContent" > >> set_before_add="name" > >> > > >> > >>everything goes well, an OrderedMultiSelectWidget is > displayed in the > >>browser by default for the *szemelyek* field. > >> > >>If I modify the addform configuration by adding the : > >> >> schema="szscreen.interfaces.ISzemely" > >> content_factory="szscreen.app.Szemely" > >> label="Uj Szemely" > >> name="AddSzemely.html" > >> permission="zope.ManageContent" > >> set_before_add="name" > >> > > >> >> class="zope.app.form.browser.OrderedMultiSelectWidget"/> > >> Just a quick note: If you use a List of Choice, I guess you need a "custom sequence widget factory" not a custom widget factory". I implemented such a base factory in zope.app.form.__init__.py "CustomSequenceWidgetFactory" There is also a test for this at: zope.app.form.browser.tests.test_sequencewidget.py btw; I'm not sure right now if this is really the problem since I didn't follow the tread at all. Regards Roger Ineichen ___ 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: Zope3-dev Digest, Vol 25, Issue 37
Benji York wrote: > Jean-Marc Orliaguet wrote: > >> Benji York wrote: >> >>> Can you give an example of one of these pieces of knowledge? >> >> >> "John gives a book to Mary" > > >> If you store the relations "John drops the book" and "Mary picks the >> book" how will you know if the book belongs to Mary and belonged to John >> before it was given to her? You could add "the book belongs to John" >> "the book belongs to Mary", add some date information, add the fact that >> the action is a gift (reification), ... all the pieces still have to be >> put together. This will need to be interpreted in a language (or a query >> language that does unions, intersections, ..) that knows how to put the >> pieces together. The model is very verbose is not explicit at all. > > > I assume you mean "no combination of dyadic predicates using only > John, the book, and Mary as subjects and objects". If so, I agree. > > We're drifting fatally off topic here, but: Just as there are some > statements that cannot be expressed as dyadic predicates, are there > also those which cannot be expressed as triadic predicates? > > "John gives a book to Mary in exchange for 5 euros" > > If you store the relations "John gives a book to Mary" and "Mary gives > 5 euros to John" how will you know that the 5 euros were payment for > the book? Now we'll really off-topic, but well: Actually there is a theorem (called the "reduction thesis", hinted by Peirce 100 years ago, and proved first in 1988) that says that even though no combination of dyadic relations can be used to build a genuine triadic relation, any relation of adicity > 3 can be built by combining triadic relations. Here is a quote that I found (CP. 6 is Collected Papers of C.S Peirce vol6): CP 6.323. A tetradic, pentadic, etc. relationship is of no higher nature than a triadic relationship; in the sense that it consists of triadic relationships and is constituted of them. But a triadic relationship is of an essentially higher nature than a dyadic relationship, in the sense that while it involves three dyadic relationships, it is not constituted by them. If A gives B to C, he, A, acts upon B, and acts upon C; and B acts upon C. Perhaps, for example, he lays down B, whereupon C takes B up, and is benefited by A. But these three acts might take place without that essentially intellectual operation of transferring the legal right of possession, which axiomatically cannot be brought about by any pure dyadic relationships whatsoever. Here is the example that you took, analysed into 6 triadic relations: --- START QUOTE --- Peirce: CP 7.537 There are no more Kainopythagorean categories than these three. For the first category is nonrelative experience, the second is experience of a dyadic relation, and the third is experience of a triadic relation. It is impossible to analyze a triadic relation, or fact about three objects, into dyadic relations; for the very idea of a compound supposes two parts, at least, and a whole, or three objects, at least, in all. On the other hand, every tetradic relation, or fact about four objects can be analyzed into a compound of triadic relations. This can be shown by an example. Suppose a seller, S, sells a thing, T, to a buyer, B, for a sum of money, M. This sale is a tetradic relation. But if we define precisely what it consists in, we shall find it to be a compound of six triadic relations, as follows: Peirce: CP 7.537 1st, S is the subject of a certain receipt of money, R, in return for the performance of a certain act As; Peirce: CP 7.537 2nd, This performance of the act As effects a certain delivery, D, according to a certain contract, or agreement, C; Peirce: CP 7.537 3rd, B is the subject of a certain acquisition of good, G, in return for the performance of a certain act, Ab; Peirce: CP 7.537 4th, This performance of the act Ab effects a certain payment, P, according to the aforesaid contract C; Peirce: CP 7.537 5th, The delivery, D, renders T the object of the acquisition of good G; Peirce: CP 7.537 6th, The payment, P, renders M the object of the receipt of money, R. Or we may define a sale as the execution of contract of sale. The contract of sale has two clauses. The first clause provides for a giving and a receiving. The giving is by the seller of the commodity; the receiving is by the buyer of the same commodity. The second clause provides for a giving and a receiving. The giving is by the buyer of the price; the receiving is by the seller of the same price. The execution is of the first clause and of the second, etc. But I do not think this latter definition as good as the other, since it introduces several unnecessary elements and also covertly brings in four pentadic relations, such as the relation of the buyer to the first and second clauses of the contract and to the separate executions of them. --- END QUOTE --- /JM ___ Zope3-dev m
Re: [Zope3-dev] file objects and formlib
On 8/26/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: > I just saw this being changed in the wiki (by Fred Drake): > >the new zope.formlib. - -- Reimplement file objects (for >Zope 2 or Zope 3 to take advantage of the new 'zope.formlib' I just tweaked the wording a bit and added the missing ")"; someone else added the item (Jim?). > I'm curious to hear what this is about. I've been dealing with file > widgets in particular a lot recently and have some input on it: This sounds completely separate. :-) You're referring to the widget, and the item above refers to the zope.app.file.File content object. I generally agree with you about file widgets; they're not in great shape. Roger Ineichen did some work on this on a branch, but I've not had time to review it. I don't recall whether he was attempting to address all of the issues you mention. > I've already solved the validation feedback form problem by storing > files in a session temporarily. This isn't efficient, but I *also* > developed something that will lick that problem and that I'll present in > a lightning talk at the Plone conference. I look forward to hearing about it, but won't be at the Plone conference myself. > I'll happily share all that I have, and this mail is just to prevent > work is inadvertently duplicated. Probably you meant to work on > something else, but I figured I'd make sure. Yes, the work sounds distinct from what's described in that item in the wiki, but that's not to say Zope 3 doesn't need what you're describing. Thanks for letting us all in on what you're up to! -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
Re[2]: [Zope3-dev] problems with
Dear Dominik, I implemeted what you told me, but I'm still out of luck. (The szerep/szemely mistake as noticed by Dylan Reinhardt was mine, but you got the real problem. class ISzemely(Interface): ... szerepek = List( title=u"Hozzarendelt szerepek", description=u"Hozzarendelt szerepek", required=False, value_type=Choice(vocabulary="szerep") ) ) helper.py: from zope.app.form import CustomWidgetFactory from zope.app.form.browser import OrderedMultiSelectWidget OrderedMultiSelectWidget_factory = CustomWidgetFactory(OrderedMultiSelectWidget) configure.zcml: ... ... The exception is a little bit different, but the end result is the same. ... Module zope.interface.adapter, line 481, in queryMultiAdapter return factory(*objects) Module zope.app.form.browser.editview, line 64, in __init__ self._setUpWidgets() Module zope.app.form.browser.add, line 49, in _setUpWidgets setUpWidgets(self, self.schema, IInputWidget, names=self.fieldNames) Module zope.app.form.utility, line 153, in setUpWidgets context=context) Module zope.app.form.utility, line 101, in setUpWidget widget = widget(field.bind(context), view.request) Module zope.app.form, line 97, in __call__ instance = self._widget_factory(*args) Module zope.app.form, line 97, in __call__ instance = self._widget_factory(*args) TypeError: __init__() takes exactly 4 arguments (3 given) As I checked the worldcookery example it does not use a factory either and it is working fine. Wednesday, August 24, 2005, 4:01:07 PM, you wrote: DH> Adam Groszer wrote: >>I'm having problems with using . >> >>I have an interface: >>class ISzerep(Interface): >>name = TextLine( >>title=u"Szerep nev", >>description=u"Szerep nev", >>required=True >>) >>szemelyek = List( >>title=u"Hozzarendelt szemelyek", >>description=u"Hozzarendelt szemelyek", >>required=False, >>value_type=Choice(vocabulary="szemely") >>) >> >>If I add a simple add (or edit) form: >> > schema="szscreen.interfaces.ISzemely" >> content_factory="szscreen.app.Szemely" >> label="Uj Szemely" >> name="AddSzemely.html" >> permission="zope.ManageContent" >> set_before_add="name" >> > >> >>everything goes well, an OrderedMultiSelectWidget is displayed in the >>browser by default for the *szemelyek* field. >> >>If I modify the addform configuration by adding the : >> > schema="szscreen.interfaces.ISzemely" >> content_factory="szscreen.app.Szemely" >> label="Uj Szemely" >> name="AddSzemely.html" >> permission="zope.ManageContent" >> set_before_add="name" >> > >> > class="zope.app.form.browser.OrderedMultiSelectWidget"/> >> >> >> DH> You cannot register the widget class directly, but you have to provide a DH> specific widget factory. DH> Example edit.py within your browser directory: DH> from zope.app.form import CustomWidgetFactory DH> from zope.app.form.browser import OrderedMultiSelectWidget DH> szerepek_widget_factory = DH> CustomWidgetFactory(OrderedMultiSelectWidget) DH> Example registration within the configure.zcml: DH> schema="szscreen.interfaces.ISzemely" DH> content_factory="szscreen.app.Szemely" DH> label="Uj Szemely" DH> name="AddSzemely.html" DH> permission="zope.ManageContent" DH> set_before_add="name" DH> > DH>class=".edit.szerepek_widget_factory"/> DH> DH> Regards, DH> Dominik -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: A certain amount of opposition is a great help to a man. Kites rise against, not with the wind. - John Neal ___ 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: Zope3-dev Digest, Vol 25, Issue 37
Jean-Marc Orliaguet wrote: Benji York wrote: Can you give an example of one of these pieces of knowledge? "John gives a book to Mary" If you store the relations "John drops the book" and "Mary picks the book" how will you know if the book belongs to Mary and belonged to John before it was given to her? You could add "the book belongs to John" "the book belongs to Mary", add some date information, add the fact that the action is a gift (reification), ... all the pieces still have to be put together. This will need to be interpreted in a language (or a query language that does unions, intersections, ..) that knows how to put the pieces together. The model is very verbose is not explicit at all. I assume you mean "no combination of dyadic predicates using only John, the book, and Mary as subjects and objects". If so, I agree. We're drifting fatally off topic here, but: Just as there are some statements that cannot be expressed as dyadic predicates, are there also those which cannot be expressed as triadic predicates? "John gives a book to Mary in exchange for 5 euros" If you store the relations "John gives a book to Mary" and "Mary gives 5 euros to John" how will you know that the 5 euros were payment for the book? -- Benji York Senior Software Engineer 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] file objects and formlib
Hi there, I just saw this being changed in the wiki (by Fred Drake): the new zope.formlib. - -- Reimplement file objects (for Zope 2 or Zope 3 to take advantage of the new 'zope.formlib' I'm curious to hear what this is about. I've been dealing with file widgets in particular a lot recently and have some input on it: File widgets as in Zope 3 don't behave like text widgets. Basically they don't behave like any other widgets at all; they're an odd duck out. This is bad, because: - for an add form, if something goes wrong and the form is redisplayed with some validation errors, the uploaded file information is lost. This is bad because for a required file field, it requires multiple uploads where one should suffice, and for a non-required file field, it's even worse, as a user would have no motivation to re-upload the same file after validation failure and redisplay of the form, resulting in no file being uploaded at all. - for an edit form, there is no resubmit of the same data as you'd see with a text widget where the data hasn't been changed by the user. Instead there's either no upload, or an upload of a new file. This behavior is again different than a text widget, which makes programming harder as the programmer will have to check 'is there a file already there?' manually in some cases. I've already solved the validation feedback form problem by storing files in a session temporarily. This isn't efficient, but I *also* developed something that will lick that problem and that I'll present in a lightning talk at the Plone conference. I'm working on solving the second problem, so that a file is *always* present in the validated form data no matter whether it only ever resided on the server in case of an edit form. Basically I emulate the behavior of the text widget, for the file widget. This way they become a lot easier to work with. I'll happily share all that I have, and this mail is just to prevent work is inadvertently duplicated. Probably you meant to work on something else, but I figured I'd make sure. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
