Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> Also this is as bad as storing browser view related attributes in a >> content class - otherwise we are back to the Zope2 old days, where every >> possible attribute was stored on the objects themselves. > > > There are advantages in storing data on the object, if you can do it > in a controlled way. I understand and agree that you don't want the > implementation of portlets to know about (depend on) styles. Zope 3 > provides a mechanism, annotations, for storing data on an object > without affecting the object's implementation. > here is the use case: - the style of portlets located in slots is associated to the slot (not to the portlets). Why? because content creators focus on content not on CSS styles, when they add a portlet into a slot someone else has already designed the style for the portlet. - the same goes with widgets (the actual presentation of portlets) here is an animation that demonstrates the idea: http://www.z3lab.org/sections/front-page/design-features/slot-formats - the default behaviour for portlets is to inherit formats (styles, widgets, etc) from the slots. - it means that slots (not portlets) should in principle store the format information. - but if you do this (store the style information on slots), there is no way to override slot styles in some given context or perspective only. Maybe you want your end-users to be able to customize the color of the boxes? If you store the information in the slot, there is no way to display portlet boxes in a slightly different way (e.g. add min/max buttons on boxes) - so basically if you store some style information on some given content class (portlet, slot, ...) you will already have shot yourself in the foot, after the third use case only:-) This is why cpsskins uses the notion of "display", which is an object that stores all format information (style, widget presentation, visibility, ...) Different displays can be associated to a same slot or a same portlet. >> Then OK: if you store the style attribute on the portlet itself, I >> suppose that this information will be indexed and cataloged. In what way >> is it different from having a separate relation store that does not >> duplicate information? > > > Why would it be indexed? Why would I advocate one centralized storage > scheme over another? I don't like centralized data structures. They are > necessary sometimes. do you mean that all information is stored on objects and that you don't index the information in any catalog to get access to it fast? how many pages per second can you render? > >> Honestly, Zope3 makes some sort of schizofrenic separation between >> content and view, in a way that you sometimes cannot get access to the >> request object because you haven't adapted (context, request). > > > I don't really understand what you are objecting to. Requests are > necessary for user interaction. Why should anything but presentation > code have access to the request? We obtain presentation code > by adapting the request. Why would you want the request elsewhere? > How is this schizophrenic? This could be the subject of another thread, but basically I end up in some cases having to pass the request object to methods (as in Zope2) because the code is neither 100% presentation nor pure content. Maybe I'm doing things in the wrong way ... I need to implement a Read / Write containers (slots) that since that are Containers know nothing about requests, but also need to get some information stored in the request to decide how to store the information. .. >> the Zope3 philosophy has to be coherent: if you create a waterproof >> separation between components, then having a waterproof separation >> between content elements, i.e. portlets / widgets / styles / layout / >> visibility options / caching parameters is just as important. > > > Agreed. I'm slowly getting an inkling of what your architecture is and is > trying to achiev. As I learn more, I'm liking many aspects. > to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? >>> >>> >>> >>> Because to decide if I want to use it, I need to evaluate the >>> architecture: >>> >>> - I need to know if there are hidden costs that aren't apparent in >>> demos and small scale. >>> >>> Your solution requires a potentially large centralized indexing >>> structure. >>> I don't like large centralized indexing structures. They are >>> necessary >>> sometimes, but I don't want to use them if I can avoid it. >>> >> >> I don't know about yours, > > > We don't have anything that does exactly what your system does > (assuming that I know what your system does ;). But we've faced
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: ... - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. Then why not just store the style in the portlet? Again you are making the assumption that a portlet *has* a style. If the portlet is rendered in RSS it has no style ... You clarified this later in the earlier message. I should have moddified my question a bit. Also this is as bad as storing browser view related attributes in a content class - otherwise we are back to the Zope2 old days, where every possible attribute was stored on the objects themselves. There are advantages in storing data on the object, if you can do it in a controlled way. I understand and agree that you don't want the implementation of portlets to know about (depend on) styles. Zope 3 provides a mechanism, annotations, for storing data on an object without affecting the object's implementation. Then OK: if you store the style attribute on the portlet itself, I suppose that this information will be indexed and cataloged. In what way is it different from having a separate relation store that does not duplicate information? Why would it be indexed? Why would I advocate one centralized storage scheme over another? I don't like centralized data structures. They are necessary sometimes. Honestly, Zope3 makes some sort of schizofrenic separation between content and view, in a way that you sometimes cannot get access to the request object because you haven't adapted (context, request). I don't really understand what you are objecting to. Requests are necessary for user interaction. Why should anything but presentation code have access to the request? We obtain presentation code by adapting the request. Why would you want the request elsewhere? How is this schizophrenic? the Zope3 philosophy has to be coherent: if you create a waterproof separation between components, then having a waterproof separation between content elements, i.e. portlets / widgets / styles / layout / visibility options / caching parameters is just as important. Agreed. I'm slowly getting an inkling of what your architecture is and is trying to achiev. As I learn more, I'm liking many aspects. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? Because to decide if I want to use it, I need to evaluate the architecture: - I need to know if there are hidden costs that aren't apparent in demos and small scale. Your solution requires a potentially large centralized indexing structure. I don't like large centralized indexing structures. They are necessary sometimes, but I don't want to use them if I can avoid it. I don't know about yours, We don't have anything that does exactly what your system does (assuming that I know what your system does ;). But we've faced similar sorts of design decisions. > but I guess that you will store all the information in the portal catalog? what is the difference? I wasn't suggesting storing anything in the catalog. I was suggesting storing data on the objects. - Your system defines a framework that I'll need to understand if we want to use it. I need to understand if developers will find it easy to use the number one target audience is end-users, and application developers. These are two audiences. Are these number one and number two? I suggest you have a number of audiences: - site designers - application developers - content managers (who you call end users). The Zope2 version is already appealing to both users and developers. Cool. I'm a developer and after all this discussion, I have only a loose grasp on what you are trying to do. I think you've indicated that the system you're describing me has evolved from the Zope 3 version. > At the university we can't afford to create a product that only developers understand. Content creators, graphic designers don't think as developers, they see things differently and this is what I'm trying to integrate into cpsskins, i.e. *their* knowledge. Great. BTW I'm still unclear whether you are still trying to satisfy the use case of allowing portlet assignments by folder with aggregation along a folder path. I thought you said yes, but it sounded that was not done when you supported perspectives. Do you support by-folder and by-perspective portlet assignment at the same time? How have you addressed the confusion that arises when a user adds a portlet to a page in a folder and it appears on subfolder pages as well? if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. Why would you want to generate RSS in a portlet?
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >> - this portlet uses this widget > > > I'm confused. In the doctest you pointed out: > > https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt > > > the portlet and widget are wired up by hand, not by lookup AFAICT. > sorry this is a doctest that does not take into account relations. It only describes the way in which elements are rendered, i.e. moving from content -> view, from data to HTML. >> - this portlet uses this style >> >> not for a *class* of portlets, but for *instances* of classes. Adapters >> connect interfaces, not instances. > > > Then why not just store the style in the portlet? > Again you are making the assumption that a portlet *has* a style. If the portlet is rendered in RSS it has no style ... Also this is as bad as storing browser view related attributes in a content class - otherwise we are back to the Zope2 old days, where every possible attribute was stored on the objects themselves. Then OK: if you store the style attribute on the portlet itself, I suppose that this information will be indexed and cataloged. In what way is it different from having a separate relation store that does not duplicate information? Honestly, Zope3 makes some sort of schizofrenic separation between content and view, in a way that you sometimes cannot get access to the request object because you haven't adapted (context, request). the Zope3 philosophy has to be coherent: if you create a waterproof separation between components, then having a waterproof separation between content elements, i.e. portlets / widgets / styles / layout / visibility options / caching parameters is just as important. > >> to sum up: for exactly the same reason as why Zope2 moved to a >> component-based architecture, but for the content this time. I want to >> be able to connect content objects (portlets, styles, widgets, layouts) >> in a flexible way. >> >> and by the way it works, so why explain why you need something when it >> works as expected? > > > Because to decide if I want to use it, I need to evaluate the > architecture: > > - I need to know if there are hidden costs that aren't apparent in > demos and small scale. > > Your solution requires a potentially large centralized indexing > structure. > I don't like large centralized indexing structures. They are necessary > sometimes, but I don't want to use them if I can avoid it. > I don't know about yours, but I guess that you will store all the information in the portal catalog? what is the difference? > - Your system defines a framework that I'll need to understand if > we want to use it. I need to understand if developers will find it > easy to use > the number one target audience is end-users, and application developers. The Zope2 version is already appealing to both users and developers. At the university we can't afford to create a product that only developers understand. Content creators, graphic designers don't think as developers, they see things differently and this is what I'm trying to integrate into cpsskins, i.e. *their* knowledge. > if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. >>> >>> >>> >>> Why would you want to generate RSS in a portlet? >> >> >> the portlet data is used for syndication in RSS / ATOM too in a RSS >> rendering engine (the [RSS] orange button). > > > Is this a case where you are using a portlet as an application > component outside the context of a page? > yes, of course, content is often syndicated. Creating a syndication adapter that gathers data, extract data and renders it in RSS when you only need to create a filter and add /++engine++rss/ in the url is worth a lot. >>> >>> - We define layout types. These extend something like ISubPage (as >>> defined in >>> formlib). Alternatively, we use named adapters. >>> >> >> what is a layout type? > > > The thing you specify with the widget keyword argument to the Widget > contructor in the doctest you sent. > OK, this is not really important, this is only used by the vocabulary items to not propose a "box layout" to a user when it makes no sense to apply a "box layout" to an element. This is just a way of categorizing widgets / layouts. >>> - We adapt the applets with the request to the layout type: >>> >>> view = component.queryMultiAdapter((applet, request), >>> IDropDownList) >>> >>> or, with named adapters: >>> >>> view = component.queryMultiAdapter((applet, request), ISubPage, >>> 'dropdown_list') >>> >>> Would something like this work for you? >>> >>> Jim >>> >> >> >> I don't think so, because the relation portlet <-> widget <-> layout >> gets hardcoded in python. > > > In the example you asked me to look at, the portlet<->widget relation > seemed to be hardcoded in Python. > > In any case, adapter definitions are not hardcoded in Python.
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: this is more a design feature than an implementation feature. Could you explain *why* you need relations? yes, because adapters provide flexible relations between *components* (interfaces, classes), but not between *content* objects. I want to be able to say (or the user) - this portlet uses this widget I'm confused. In the doctest you pointed out: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt the portlet and widget are wired up by hand, not by lookup AFAICT. - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. Then why not just store the style in the portlet? to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? Because to decide if I want to use it, I need to evaluate the architecture: - I need to know if there are hidden costs that aren't apparent in demos and small scale. Your solution requires a potentially large centralized indexing structure. I don't like large centralized indexing structures. They are necessary sometimes, but I don't want to use them if I can avoid it. - Your system defines a framework that I'll need to understand if we want to use it. I need to understand if developers will find it easy to use if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. Why would you want to generate RSS in a portlet? the portlet data is used for syndication in RSS / ATOM too in a RSS rendering engine (the [RSS] orange button). Is this a case where you are using a portlet as an application component outside the context of a page? ... I guess the widget filter somehow decides how to generate HTML based on the widget and data. Similarly, it somehow chooses a style. It's unclear how this is working. the widget knows nothing about the style that is going to be applied afterwards. The portlet <-> style connection is a relation defined in the relation store. Can you say why you chose this division of labor? it is one example of a chain of filters that covers most of the use cases to create HTML pages. Since the engine definition is defined in a zcml file it can be changed easily. I could go into the details of the design, but since it works as expected ... I agree that, given a model where portlets only generate data, "pagelett" is not a good name. Perhaps "applet" would be a better name. IMO, the choice of the term "widget" is unfortunate, both because it clashes with the Zope 3 use of the term and because it clashes with common usage in GUIS, where widgets are responsible for UI generation, whereas here, AFAICT, widgets are responsible for UI specification in some fashion. Here's an alternate suggestion that follows Zope 3 style a bit more: - We have applets that provide application functionality. These are like your portlets. - We define layout types. These extend something like ISubPage (as defined in formlib). Alternatively, we use named adapters. what is a layout type? The thing you specify with the widget keyword argument to the Widget contructor in the doctest you sent. - We adapt the applets with the request to the layout type: view = component.queryMultiAdapter((applet, request), IDropDownList) or, with named adapters: view = component.queryMultiAdapter((applet, request), ISubPage, 'dropdown_list') Would something like this work for you? Jim I don't think so, because the relation portlet <-> widget <-> layout gets hardcoded in python. In the example you asked me to look at, the portlet<->widget relation seemed to be hardcoded in Python. In any case, adapter definitions are not hardcoded in Python. > I would mean that I would have to rewrite the AJAX theme editor. the difference with the rendering architecture that I have implemented is that new rendering engines can be created by reusing components. I think that your approach is not generic enough, it is too much tied with the webpage generation paradigm (it assumes that a portlet has a layout, or a style...) which are web-related concepts. I see your point about not wanting to store a web style with a portlet instance. I need to think about this. 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-
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> this is more a design feature than an implementation feature. > > > Could you explain *why* you need relations? > > yes, because adapters provide flexible relations between *components* (interfaces, classes), but not between *content* objects. I want to be able to say (or the user) - this portlet uses this widget - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? >> yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. >>> >>> >>> >>> I'd like to understand how this works. >>> >>> Jim >> >> >> >> >> A portlet / pagelet generates some data (a list of menu items, for >> instance) as a data structure in python. >> >> - the data goes through a widget filter that convert the data into HTML. >> Depending on what widget is being used, the same data is displayed >> differently (vertical list, horizontal list, drop-down list...). >> >> - a style filters add the style information (class="..."), >> >> the portlet can then be displayed in HTML >> >> if other combinations of filters are used (a RSS filter for instance), >> the same data is displayed in RSS instead of HTML. > > > Why would you want to generate RSS in a portlet? the portlet data is used for syndication in RSS / ATOM too in a RSS rendering engine (the [RSS] orange button). if the portlet already renders HTML, there is no way to convert HTML to RSS. > >> which is shown on the following diagram: >> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png >> >> >> and documented here: >> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt >> > > > So > > - You get a widget of a particular type. > > - You adapt the widget (with a request) to get a widget filter. > > - You call the portlet to get some data. > > - You call the widget filter with the data to get HTML markup. > this is just one example of a rendering engine (the HTML rendering engine) > I guess the widget filter somehow decides how to generate HTML based > on the widget and data. Similarly, it somehow chooses a style. > It's unclear how this is working. > the widget knows nothing about the style that is going to be applied afterwards. The portlet <-> style connection is a relation defined in the relation store. > Can you say why you chose this division of labor? > it is one example of a chain of filters that covers most of the use cases to create HTML pages. Since the engine definition is defined in a zcml file it can be changed easily. I could go into the details of the design, but since it works as expected ... > I agree that, given a model where portlets only generate data, "pagelett" > is not a good name. Perhaps "applet" would be a better name. > > IMO, the choice of the term "widget" is unfortunate, both because it > clashes > with the Zope 3 use of the term and because it clashes with common > usage in > GUIS, where widgets are responsible for UI generation, whereas here, > AFAICT, > widgets are responsible for UI specification in some fashion. > > Here's an alternate suggestion that follows Zope 3 style a bit more: > > - We have applets that provide application functionality. These are > like your portlets. > > - We define layout types. These extend something like ISubPage (as > defined in > formlib). Alternatively, we use named adapters. > what is a layout type? > - We adapt the applets with the request to the layout type: > > view = component.queryMultiAdapter((applet, request), IDropDownList) > > or, with named adapters: > > view = component.queryMultiAdapter((applet, request), ISubPage, > 'dropdown_list') > > Would something like this work for you? > > Jim > I don't think so, because the relation portlet <-> widget <-> layout gets hardcoded in python. I would mean that I would have to rewrite the AJAX theme editor. the difference with the rendering architecture that I have implemented is that new rendering engines can be created by reusing components. I think that your approach is not generic enough, it is too much tied with the webpage gene
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: basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. Cool. So we can define new slot-like things (for example, for JSR 168-style slots) and use your slots or not, as we wish. In particular, we can use CPS skins without being forced to install triad registries unless we want to use your slots. In that case it is possible to plug in other relation store backends (e.g RDF) that do not support genuine triadic predicates, which means that only "local folder" types of slots will be available, but some relation storage is required for the dyadic relations between elements and styles, widgets... because the relations between the elements are not stored on the elements themselves. Sigh. Is this documented anywhere? Currently the application adds relations into the relation store using a relation tool, there is not definite documented interface though, since not all the use cases are defined yet: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py The idea is to allow any relation store back-end (RDF, SQL, ..) to be plugged in. If the relation information was stored in the elements themselves (e.g. annotations, attributes, ...) this would make it very difficult to move the storage from the ZODB. this is more a design feature than an implementation feature. Could you explain *why* you need relations? yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. I'd like to understand how this works. Jim A portlet / pagelet generates some data (a list of menu items, for instance) as a data structure in python. - the data goes through a widget filter that convert the data into HTML. Depending on what widget is being used, the same data is displayed differently (vertical list, horizontal list, drop-down list...). - a style filters add the style information (class="..."), the portlet can then be displayed in HTML if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. Why would you want to generate RSS in a portlet? which is shown on the following diagram: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png and documented here: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt So - You get a widget of a particular type. - You adapt the widget (with a request) to get a widget filter. - You call the portlet to get some data. - You call the widget filter with the data to get HTML markup. I guess the widget filter somehow decides how to generate HTML based on the widget and data. Similarly, it somehow chooses a style. It's unclear how this is working. Can you say why you chose this division of labor? I agree that, given a model where portlets only generate data, "pagelett" is not a good name. Perhaps "applet" would be a better name. IMO, the choice of the term "widget" is unfortunate, both because it clashes with the Zope 3 use of the term and because it clashes with common usage in GUIS, where widgets are responsible for UI generation, whereas here, AFAICT, widgets are responsible for UI specification in some fashion. Here's an alternate suggestion that follows Zope 3 style a bit more: - We have applets that provide application functionality. These are like your portlets. - We define layout types. These extend something like ISubPage (as defined in formlib). Alternatively, we use named adapters. - We adapt the applets with the request to the layout type: view = component.queryMultiAdapter((applet, request), IDropDownList) or, with named adapters: view = component.queryMultiAdapter((applet, request), ISubPage, 'dropdown_list') Would something like this work for you? 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: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. >>> >>> >>> >>> Cool. So we can define new slot-like things (for example, >>> for JSR 168-style slots) and use your slots or not, as we wish. >>> >>> In particular, we can use CPS skins without being forced to >>> install triad registries unless we want to use your slots. >>> >> >> >> In that case it is possible to plug in other relation store backends >> (e.g RDF) that do not support genuine triadic predicates, which means >> that only "local folder" types of slots will be available, but some >> relation storage is required for the dyadic relations between elements >> and styles, widgets... because the relations between the elements are >> not stored on the elements themselves. > > > Sigh. Is this documented anywhere? Currently the application adds relations into the relation store using a relation tool, there is not definite documented interface though, since not all the use cases are defined yet: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py The idea is to allow any relation store back-end (RDF, SQL, ..) to be plugged in. If the relation information was stored in the elements themselves (e.g. annotations, attributes, ...) this would make it very difficult to move the storage from the ZODB. this is more a design feature than an implementation feature. >> >> yes, I re-read >> http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and >> while going through the different definitions I saw that not two >> implementations are done in the same way, which is fine. >> >> The important aspect is that "portlets" or "pagelets" as they are >> implemented in cpsskins separate model and view. >> They implement the "data model" part only, not the view itself, which >> is done later by widget, layout and style filters inside the rendering >> engine. > > > I'd like to understand how this works. > > Jim A portlet / pagelet generates some data (a list of menu items, for instance) as a data structure in python. - the data goes through a widget filter that convert the data into HTML. Depending on what widget is being used, the same data is displayed differently (vertical list, horizontal list, drop-down list...). - a style filters add the style information (class="..."), the portlet can then be displayed in HTML if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. which is shown on the following diagram: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png and documented here: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt /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: basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. Cool. So we can define new slot-like things (for example, for JSR 168-style slots) and use your slots or not, as we wish. In particular, we can use CPS skins without being forced to install triad registries unless we want to use your slots. In that case it is possible to plug in other relation store backends (e.g RDF) that do not support genuine triadic predicates, which means that only "local folder" types of slots will be available, but some relation storage is required for the dyadic relations between elements and styles, widgets... because the relations between the elements are not stored on the elements themselves. Sigh. Is this documented anywhere? - Use of the term "portlet" here leads to confusion with JSR 168 portlets, which are different. I would prefer to see a different term used for what CPS calls portlets. Absent that, we'll need to find some modifiers to disambiguate. Jim yes, any term, "boxes" are not OK, since they refer to the portlet's display (view) with the frame and the decorations but any term that is understood by users / developers is ok. Cool. "Pagelets"? Jim yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. I'd like to understand how this works. 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: [Z3lab] Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Tonico Strasser wrote:
> Hi!
>
> Jean-Marc Orliaguet schrieb:
>
>> Anyway, pagelets or portlets whatever they called and no matter what
>> data they produce (structured data or raw HTML) must be "pipe-able"
>> through the rendering engine, i.e. they must return some data, the more
>> "ready HTML" the data is the less reusable it will be.
>
>
> Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
> stuff in Python code that would be very nice. We would have a "page"
> object that can "pipe" page components together.
>
yes, this is what cpsskins does:
- the "define-slot" is just a "cpsskins:slot" with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.
- the "fill-slot" part has been the subject of the discussion the past
week in the "perspective" thread.
Currently the plan is to support the "perspective" way of filling slots
(1 perspective = 1 set of portlets) and the "local folder" way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.
here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png
starting from the top node in the theme tree:
A) is the node a leaf?
=> YES: then render the node according to B)
=> NO: get the list of child nodes in the correct order, for every
node go to A)
B) for every filter associated to the node:
- is the filter is the first in the chain?
=> YES: then get the data from the leaf (getDisplayData())
=> NO: use the output of the previous filter in the chain and feed
it into the current filter
- if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.
In this way, believe it or not, you can by changing a few lines in a
zcml file render a "theme editor" with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml
or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml
90% of all the components are reused, simply they are wired together
differently.
> A simple example with boxes (sorry, Zope 2 script, don't kill me):
>
> ##
> page = context.Page(template=container.ZPT_A)
>
> # aggregate macro-defs from other page template
> page.macros.update(container.ZPT_B.macros)
>
> # create list of Box instances (not rendered HTML)
> b1 = container.box_a('demo', 'Demo', condition=some_condition)
> # box 2 takes b1 as input
> b2 = container.box_b('foo', 'Foo', some_arg=b1)
>
> left_boxes = [b1, b2]
>
> # make boxes available in PTs as 'lboxes'
> page.lboxes = left_boxes
>
> # now we have aggregated all informations
> # ready to render
>
> # calls pt_render of ZPT_A with extra context
> return page.render()
>
> ##
>
> ZPT_A:
>
>
>
>
>
> ZPT_B:
>
>
>
>
>
>
> box_repeat macro:
>
> metal:define-macro="box_repeat"
> tal:repeat="box lboxes"
> tal:attributes="id box/id">
> tal:content="box/title"/>
> metal:use-macro="box/macros/body|default"/>
>
>
> Just for your inspiration.
>
> Tonico
>
>
yes, this is the ZPT way of doing it :-)
/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
Hi!
Jean-Marc Orliaguet schrieb:
Anyway, pagelets or portlets whatever they called and no matter what
data they produce (structured data or raw HTML) must be "pipe-able"
through the rendering engine, i.e. they must return some data, the more
"ready HTML" the data is the less reusable it will be.
Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
stuff in Python code that would be very nice. We would have a "page"
object that can "pipe" page components together.
A simple example with boxes (sorry, Zope 2 script, don't kill me):
##
page = context.Page(template=container.ZPT_A)
# aggregate macro-defs from other page template
page.macros.update(container.ZPT_B.macros)
# create list of Box instances (not rendered HTML)
b1 = container.box_a('demo', 'Demo', condition=some_condition)
# box 2 takes b1 as input
b2 = container.box_b('foo', 'Foo', some_arg=b1)
left_boxes = [b1, b2]
# make boxes available in PTs as 'lboxes'
page.lboxes = left_boxes
# now we have aggregated all informations
# ready to render
# calls pt_render of ZPT_A with extra context
return page.render()
##
ZPT_A:
ZPT_B:
box_repeat macro:
Just for your inspiration.
Tonico
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> basically if the "slot" that you're thinking about contains portlets >> then it's a sort of slot not a sort of portlet. > > > Cool. So we can define new slot-like things (for example, > for JSR 168-style slots) and use your slots or not, as we wish. > > In particular, we can use CPS skins without being forced to > install triad registries unless we want to use your slots. > In that case it is possible to plug in other relation store backends (e.g RDF) that do not support genuine triadic predicates, which means that only "local folder" types of slots will be available, but some relation storage is required for the dyadic relations between elements and styles, widgets... because the relations between the elements are not stored on the elements themselves. > >>> - Use of the term "portlet" here leads to confusion with JSR 168 >>> portlets, which are different. I would prefer to see a different >>> term used for what CPS calls portlets. Absent that, we'll need to >>> find some modifiers to disambiguate. >>> >>> Jim >>> >> >> >> yes, any term, "boxes" are not OK, since they refer to the portlet's >> display (view) with the frame and the decorations but any term that is >> understood by users / developers is ok. > > > Cool. "Pagelets"? > > Jim > yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. Of course it is possible for a "pagelet" to render HTML directly and consider the HTML produced as data (that's a question of semantic), but then other rendering engines (text-based, SVG, RSS, ATOM, etc.) won't be able to do anything with the HTML data that they get. Anyway, pagelets or portlets whatever they called and no matter what data they produce (structured data or raw HTML) must be "pipe-able" through the rendering engine, i.e. they must return some data, the more "ready HTML" the data is the less reusable it will be. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: Hi! Somehow related to the discussion on optimizing catalog queries, I have been thinking about how to best implement local portlets in cpsskins in terms of scalability, performance and functionality. The implementation is heavily dependent on being able to performance effective catalog queries (it is OK to wait 2 seconds in an ECMS to search 1 million documents, but it is not OK to have to wait 2 seconds to render a page containing portlets). Here is the proposal: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets It is built on the notion of "Perspective" (see the link) and on the idea of querying the catalog using triadic relations instead of joining sets of query results based on dyadic predicates (such as with RDF). Well, after our various discussions, I think I understand what this is about. I have the following suggestions: - I think the perspective idea has a lot of merit, however, I'd like it to be optional. In particular, I'd like to be able to use CPS Skins without having to use perspectives. that's possible, when you can more you can less (or differently) - You said that cells can be filled with portlets or with slots. Why not make a slot another kind of portlet? Then people could introduce new slot types and innovations without affecting the rest of CPS Skins. yes, this is a possible extension, it is also possible to create a new types of objects that fits your needs that are neither slots nor portlets but that are contained inside cells. why not create a portlet that does what you want? the main formal difference between slots and portlets is that slots are inner nodes (physically or virtually contain other objects) and that portlets are node leaves (must render some data). here is the actual base classes: http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/elements/__init__.py this is important for the theme editor. if the new type of object that you are thinking of work like an inner node, then it's a slot otherwise it's a portlet. basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. Cool. So we can define new slot-like things (for example, for JSR 168-style slots) and use your slots or not, as we wish. In particular, we can use CPS skins without being forced to install triad registries unless we want to use your slots. - Use of the term "portlet" here leads to confusion with JSR 168 portlets, which are different. I would prefer to see a different term used for what CPS calls portlets. Absent that, we'll need to find some modifiers to disambiguate. Jim yes, any term, "boxes" are not OK, since they refer to the portlet's display (view) with the frame and the decorations but any term that is understood by users / developers is ok. Cool. "Pagelets"? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: > > > ... > >>> - They introduce a need for some complex infrastructure. >>> >> >> what do you mean by "complex"? have you seen the prototype? for a user >> it does not seem too complex: >> >> - choose a perspective >> - add portlets to it >> - assign the perspective to some context > > > I meant to reply to this in my last note. > > I wasn't talking about the user experience, I was talking about the > underlying implementation. You require a centralize database of triads > with a scalable query engine. This seems rather complex to me. > > Jim > Yes, if you store portlets in local folders (this is what you were thinking about?) you won't have the same scalability problems unless you have to traverse 20 folders from the site root to the current folder. This is a trade-off. This is how it was implemented in CPSSkins (Zope2) inspired from the earlier implementation (CPSBoxes). The simplicity of the implementation in terms of storage has meant some very difficult issues to solves in terms of user interface. So now I'm willing to invest some time in finding a generic way of storing triadic relations in a storage. For me it is more important to allow users to place portlets anywhere in the site (on the front page, etc...), even if the site exists already or not, but I agree that it should be possible to use the local folder storage approach in the Zope3 version too. Technically speaking there is nothing that prevents the creation of varieties of slots that save portlets in local folders. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Hi! >> >> Somehow related to the discussion on optimizing catalog queries, I have >> been thinking about how to best implement local portlets in cpsskins in >> terms of scalability, performance and functionality. The implementation >> is heavily dependent on being able to performance effective catalog >> queries (it is OK to wait 2 seconds in an ECMS to search 1 million >> documents, but it is not OK to have to wait 2 seconds to render a page >> containing portlets). >> >> Here is the proposal: >> http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets >> >> >> It is built on the notion of "Perspective" (see the link) and on the >> idea of querying the catalog using triadic relations instead of joining >> sets of query results based on dyadic predicates (such as with RDF). > > > Well, after our various discussions, I think I understand what this > is about. > > I have the following suggestions: > > - I think the perspective idea has a lot of merit, however, I'd > like it to be optional. In particular, I'd like to be able to use > CPS Skins without having to use perspectives. > that's possible, when you can more you can less (or differently) > - You said that cells can be filled with portlets or with slots. > Why not make a slot another kind of portlet? Then people could > introduce new slot types and innovations without affecting the > rest of CPS Skins. > yes, this is a possible extension, it is also possible to create a new types of objects that fits your needs that are neither slots nor portlets but that are contained inside cells. why not create a portlet that does what you want? the main formal difference between slots and portlets is that slots are inner nodes (physically or virtually contain other objects) and that portlets are node leaves (must render some data). here is the actual base classes: http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/elements/__init__.py this is important for the theme editor. if the new type of object that you are thinking of work like an inner node, then it's a slot otherwise it's a portlet. basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. > - Use of the term "portlet" here leads to confusion with JSR 168 > portlets, which are different. I would prefer to see a different > term used for what CPS calls portlets. Absent that, we'll need to > find some modifiers to disambiguate. > > Jim > yes, any term, "boxes" are not OK, since they refer to the portlet's display (view) with the frame and the decorations but any term that is understood by users / developers is ok. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
>
>> Jim Fulton wrote:
>>
>>
>> I've read the article, it is clear to me that the main idea is to be
>> able to reuse components, not to create a collection of web pages just
>> to present an application from a slightly different perspective.
>
>
> OK, then we have very different perspectives on perspectives.
> I see eclipse perspectives as primarily a way to tailor the UI
> to the task at hand, which, BTW, I don't see as simply
> persenting an application from slightly different perspectives.
>
for me the Eclipse definition is a subset of what I mean. I took it as
an inspiration, the application of perspective needs not be restricted
to UI tasks. Again a perspective can be seen as a skin for portlets. It
is as if you'd claim that skins can only be used in some situations and
not in others..
>
> > With 3
>
>> master pages and a set of 5 perspectives you get 15 combinations. That
>> would be 15 pages in html to maintain.
>
>
> Perhaps, although it's not clear to me that separate perspectives
> would want to share the same master pages. To be honest, it's
> not clear to me that different applications would/should want to mess
> with the o-wrap in the first place.
>
Use case: you are looking at a site from some "external website"
perspective (cf. zope.org) you want to change the content of some
document. So you need to interact with an action box that is invisible
to anonymous users, and interact with a navigation portlet to find
documents. Are you going to create a new zope.org page for that? Or just
switch to the "web publisher" perspective?
>> The main idea is to define visibility in a coherent way,
>
>
> We're both in favor of that.
>
>
good, I think that it is about time we find areas of agreements ..
>> not with a
>> series of CSS hacks (hidden {display:none}), > tal:condition="not:first_login" >..., , scattered around 100 page
>> templates... or by using visibility conditions in the portlets own code.
>
>
> I wasn't suggesting that. I was suggesting a model where separate
> applications didn't share the same layout for parts that were
> application specific.
they don't have too, you can switch the page (theme page) just like you
switch perspectives ..
pages and perspectives are orthogonal, they have to be combined but the
combination is not determined in advance.
the combination of 2 orthogonal concepts is worth a lot in terms of
productivity. It is like the separation of form and content.
>
>> the assumption is that portlet visibility is not a propriety of
>> *individual* portlets, but this is something that is related to some
>> activity of the user, or some usage context.
>
>
> This implicit assignment of portlets to slots worries my, both from
> the point of implementation complexity and understandability.
For the user this could not be simpler in terms of UI. This is how
newspaper CMSs work already, cf Polopoly (www.polopoly.se) used in many
Swedish sites (cf. www.dn.se, www.svt.se) There are templates with slots
(equivalent of pages in cpsskins) and there are sets of portlets
assigned to slots. The perspective in Polopoly for each slot is even
written using URLs, you can change it directly in the URL. In the end,
and this is where I'm trying to get at: a site is a combination of pages
and perspectives (the two notions being 100% orthogonal)
when it comes to the implementation, I don't see how saving portlets in
folders is better. I still don't understand how you can have 1 users
add portlets inside a same slot and manage portlet order easily.
>
>> I think that Eric summarized this quite clearly in his blog:
>>
>> """
>> What for ?
>>
>> Imagine that when writing a new component, you also can easily define
>> perspective. Let's take an example : a blog application. Well you can
>> define a "Blog Perspective" that would be activated when accessing to a
>> blog and that would arrange the portal to offer a "blog view" putting
>> portlets in right places. WIth this and the whole CPSSkins machinery, it
>> would be very easy to define interfaces that can adapt to user's
>> activity.
>> The same approach would also work for webmail, calendar, collaborative
>> work, personal portal dashboard, etc. The application would then only
>> define portlets and perspectives (no more pages, view, whatever :-).
>>
>>> From the user point of view, it would really improve the usability and
>>
>> how it the portal can adapt itself to his need. The user would also be
>> albe to define its own perspectives (like it's dashboard) and switch
>> between them.
>>
>> It would be new approach in the design of web applications, that would
>> allow to think them as user-oriented applications and not as a chains of
>> html pages.
>>
>> """
>>
>> The idea is to move away from the website approach to designing web
>> applications, with the endless poliferation of templates and macros. I
>> fully agree though that this is a change from the page / vi
>
>
> You seem to al
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Hi! Somehow related to the discussion on optimizing catalog queries, I have been thinking about how to best implement local portlets in cpsskins in terms of scalability, performance and functionality. The implementation is heavily dependent on being able to performance effective catalog queries (it is OK to wait 2 seconds in an ECMS to search 1 million documents, but it is not OK to have to wait 2 seconds to render a page containing portlets). Here is the proposal: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets It is built on the notion of "Perspective" (see the link) and on the idea of querying the catalog using triadic relations instead of joining sets of query results based on dyadic predicates (such as with RDF). Well, after our various discussions, I think I understand what this is about. I have the following suggestions: - I think the perspective idea has a lot of merit, however, I'd like it to be optional. In particular, I'd like to be able to use CPS Skins without having to use perspectives. - You said that cells can be filled with portlets or with slots. Why not make a slot another kind of portlet? Then people could introduce new slot types and innovations without affecting the rest of CPS Skins. - Use of the term "portlet" here leads to confusion with JSR 168 portlets, which are different. I would prefer to see a different term used for what CPS calls portlets. Absent that, we'll need to find some modifiers to disambiguate. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: ... - They introduce a need for some complex infrastructure. what do you mean by "complex"? have you seen the prototype? for a user it does not seem too complex: - choose a perspective - add portlets to it - assign the perspective to some context I meant to reply to this in my last note. I wasn't talking about the user experience, I was talking about the underlying implementation. You require a centralize database of triads with a scalable query engine. This seems rather complex to me. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: Yes, I think that Rob mentionned that there was such a use case where you had customers who wanted to control the way portlets were disposed on the screen on an individual basis. This gets to a terminology problem. JSR 168 defines portlets to mean something quite different. In particular, JSR 168 specifies portlets that are used by end users, by which I mean the final users, as opposed to content managers, of a site to control what they personally see on a site. This is what Rob was refering to. (BTW, we would prefer that the term "portlet" be used to talk about portlets as defined by JSR 168.) Your local portlets are used by content managers to define content to appear in the o-wrap, based on site location. no, they are used by end-users as well -- this is already the case in the Zope2 version of cpsskins -- inside the perspective that they have permission to work in. I'm talking about end users who don't have permission to work on any part of the site. Further, when users's manipulate JSR 168 portlets, they only effect what *they* see, not what others see. The goals are very different. this is where I don't understand how you can with a view / adapter / page template paradigm get the JSR 168 portlets to fit in. Views, adapters are for programmers, not for end-users, not even for content creators. I don't know what you mean. You can implement a JSR 168 pertlet system in a variety of ways, including with adapters, views, ZPT etc. I wasn't talking about implementation strategy. I was talking about the kind of application -- the nature of the user interaction. ... it depends on what the content well looks likes, if the content well consists of 6 portlets, side by side or one below the other, then this is not a problem to let the cpsskins layout mechanism take care of that. I'm still not sure about what you put inside the content well, this is why. if the content well contains a document with some advanced layout and a lot of widgets then this is outside the scope of the cpsskins layout renderer. We have applications that layout the content well using a content-reuse paradigm. Here, users slot content and then specify how it should dispayed. The point is that the paradigm is very different from site layout. There are different users with different goals. what do you mean by "complex"? have you seen the prototype? for a user it does not seem too complex: - choose a perspective - add portlets to it - assign the perspective to some context - It's not clear what impact they have on URLs. If, for example, perspectives are set via cookies or session data, then both bookmarking and caching become more complicated. what about skins? ... - By introducing modes, I worry that they will make it harder to talk about and teach systems build with them. Jim what should we say about skins then? they introduce exactly the same "problems". However they exist in Zope3. a perspective is a skin but for the portlets in a page. If you think that perspectives are too complex then the skins mechanism should be reconsidered... Perspectives are used in exclipse muc the same way we use views in Zope 3. They are much more akin to Zope 3 views than to skins. People will change perspectives often, but they will rarely change skins. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> Yes, I think that Rob mentionned that there was such a use case where >> you had customers who wanted to control the way portlets were disposed >> on the screen on an individual basis. > > > This gets to a terminology problem. JSR 168 defines portlets to > mean something quite different. In particular, JSR 168 specifies > portlets that are used by end users, by which I mean the final users, > as opposed to content managers, of a site to control what they > personally see on a site. This is what Rob was refering to. > (BTW, we would prefer that the term "portlet" be used to talk > about portlets as defined by JSR 168.) > > Your local portlets are used by content managers to define > content to appear in the o-wrap, based on site location. no, they are used by end-users as well -- this is already the case in the Zope2 version of cpsskins -- inside the perspective that they have permission to work in. this is where I don't understand how you can with a view / adapter / page template paradigm get the JSR 168 portlets to fit in. Views, adapters are for programmers, not for end-users, not even for content creators. > >> Generally speaking, portlets are associated to slots but the ordering >> information is neither stored in the portlet itself nor in the slot, but >> in a "display element". There are as many display elements associated to >> a given slot as there are perspectives. > > > You still seem to have the desire have portlet assignment apply to a > a folder and to subfolders, with subfolders being able to add > portlet definitions. As you pointed out in another note, this makes > order control challenging. > > You introduce new term "display element", but you don't say enough > about what it does. I'm happy to let that pass. ;) this is the required element that makes portlets ordering not challenging anymore. But this is another issue.. > >> In this way visual ordering is not a problem, and it should also be >> possible to place the portlets inside the slot's display canvas on using >> (x, y) coordinates. I don't know about a use case for this unless maybe >> in the content well, I think you mentionned something about this in a >> previous mail? > > > I also mentioned that there are several distinct activities that I > think should remain distinct. In particular, and I think you agreed, > the system we are discussing here should not try to address the content > well. it depends on what the content well looks likes, if the content well consists of 6 portlets, side by side or one below the other, then this is not a problem to let the cpsskins layout mechanism take care of that. I'm still not sure about what you put inside the content well, this is why. if the content well contains a document with some advanced layout and a lot of widgets then this is outside the scope of the cpsskins layout renderer. > >> Bottom line: there is a very clear separation of roles. You can't do >> this today, because the roles are too intertwined. > > > I just don't see perspectives adding anything here. The application > designer can just as easily use different master pages for different > activities/tasks and assigne different portlets to different slots > in the different master pages. > this is what we do already.. but this is clumsy. Because it forces us to design a new page just for some portlets that should be hidden. Maintaining a page, with the styles, layouts, etc takes more time than maintaining a perspective that only consists of a list of portlets assigned to some slots. > I see some negatives with perspectives: > > - They introduce a need for some complex infrastructure. > what do you mean by "complex"? have you seen the prototype? for a user it does not seem too complex: - choose a perspective - add portlets to it - assign the perspective to some context > - It's not clear what impact they have on URLs. If, for > example, perspectives are set via cookies or session > data, then both bookmarking and caching become more complicated. > what about skins? > - By introducing modes, I worry that they will make it > harder to talk about and teach systems build with them. > > Jim > what should we say about skins then? they introduce exactly the same "problems". However they exist in Zope3. a perspective is a skin but for the portlets in a page. If you think that perspectives are too complex then the skins mechanism should be reconsidered... /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote:
Jim Fulton wrote:
Jean-Marc Orliaguet wrote:
...
This is what I meant with having a "unifying concept". And that sounds
very unifying to me already.
Perspectives, if I understand how you are describing them, and how
Eclipse describes them,
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
are simple separate applications. They are different ways of working
on content
based on tasks. They could be provided with perspectives, or, more
simply,
with different collections of web pages, using different styles. I
don't understand the benefit you think they provide nor do I see how
they unify anything.
I've read the article, it is clear to me that the main idea is to be
able to reuse components, not to create a collection of web pages just
to present an application from a slightly different perspective.
OK, then we have very different perspectives on perspectives.
I see eclipse perspectives as primarily a way to tailor the UI
to the task at hand, which, BTW, I don't see as simply
persenting an application from slightly different perspectives.
> With 3
master pages and a set of 5 perspectives you get 15 combinations. That
would be 15 pages in html to maintain.
Perhaps, although it's not clear to me that separate perspectives
would want to share the same master pages. To be honest, it's
not clear to me that different applications would/should want to mess
with the o-wrap in the first place.
The main idea is to define visibility in a coherent way,
We're both in favor of that.
not with a
series of CSS hacks (hidden {display:none}), ..., , scattered around 100 page
templates... or by using visibility conditions in the portlets own code.
I wasn't suggesting that. I was suggesting a model where separate
applications didn't share the same layout for parts that were
application specific.
the assumption is that portlet visibility is not a propriety of
*individual* portlets, but this is something that is related to some
activity of the user, or some usage context.
This implicit assignment of portlets to slots worries my, both from
the point of implementation complexity and understandability.
I think that Eric summarized this quite clearly in his blog:
"""
What for ?
Imagine that when writing a new component, you also can easily define
perspective. Let's take an example : a blog application. Well you can
define a "Blog Perspective" that would be activated when accessing to a
blog and that would arrange the portal to offer a "blog view" putting
portlets in right places. WIth this and the whole CPSSkins machinery, it
would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative
work, personal portal dashboard, etc. The application would then only
define portlets and perspectives (no more pages, view, whatever :-).
From the user point of view, it would really improve the usability and
how it the portal can adapt itself to his need. The user would also be
albe to define its own perspectives (like it's dashboard) and switch
between them.
It would be new approach in the design of web applications, that would
allow to think them as user-oriented applications and not as a chains of
html pages.
"""
The idea is to move away from the website approach to designing web
applications, with the endless poliferation of templates and macros. I
fully agree though that this is a change from the page / vi
You seem to allow only two choices: perspectives and very low-level
HTML/CSS/ZPT. We're all in favor of page composition that allows
pages to be assembles in various ways by various users. I'm having
a hard time buying the benefits of the approach you are suggesting
over other high-level approaches.
Here's what I think you are proposing:
- Different components should appear in the o-wrap of a page
depending on the task being performed.
- The control of the portlets displayed in the o-wrap
should be controlled by a mode called a "perspective".
I think this could be a good approach for some applications.
I'm not convinced that varying the o-wrap by task is a
good idea for all or even most sites. If I did want to do
that, I might prefer to do so by actually using different
o-wraps (master pages) for different tasks.
Don't get me wrong, I think the perspectives idea has a lot
of merit. I want it to be optional though.
I'll summarize my thoughts in a response to your original
posting.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: ... By using "perspectives" end-users can also use the portlet editor to move portlets on the canvas (as in the google news portal), By end-users, do you mean content managers? Or end-users of the content? Why do they need perspectives to do this? Do you envision them being able to control the order of the portlets? Yes, I think that Rob mentionned that there was such a use case where you had customers who wanted to control the way portlets were disposed on the screen on an individual basis. This gets to a terminology problem. JSR 168 defines portlets to mean something quite different. In particular, JSR 168 specifies portlets that are used by end users, by which I mean the final users, as opposed to content managers, of a site to control what they personally see on a site. This is what Rob was refering to. (BTW, we would prefer that the term "portlet" be used to talk about portlets as defined by JSR 168.) Your local portlets are used by content managers to define content to appear in the o-wrap, based on site location. Generally speaking, portlets are associated to slots but the ordering information is neither stored in the portlet itself nor in the slot, but in a "display element". There are as many display elements associated to a given slot as there are perspectives. You still seem to have the desire have portlet assignment apply to a a folder and to subfolders, with subfolders being able to add portlet definitions. As you pointed out in another note, this makes order control challenging. You introduce new term "display element", but you don't say enough about what it does. I'm happy to let that pass. ;) In this way visual ordering is not a problem, and it should also be possible to place the portlets inside the slot's display canvas on using (x, y) coordinates. I don't know about a use case for this unless maybe in the content well, I think you mentionned something about this in a previous mail? I also mentioned that there are several distinct activities that I think should remain distinct. In particular, and I think you agreed, the system we are discussing here should not try to address the content well. ... This is what I meant with having a "unifying concept". And that sounds very unifying to me already. Perspectives, if I understand how you are describing them, and how Eclipse describes them, http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html, are simple separate applications. They are different ways of working on content based on tasks. They could be provided with perspectives, or, more simply, with different collections of web pages, using different styles. I don't understand the benefit you think they provide nor do I see how they unify anything. I'm going to put a diagram online showing what they add in terms of separating responsability in the design of a web application, web sites, ... The idea is that the three roles: - theme designer (creates themes, styles, etc...) - programmer (creates portlets, special views for some object types, ...) - application / UI designer (puts all the pieces together) are completely orthogonal. With this you can ask a group of graphic designers to work on some graphic designer for an application, or a site. They'll be able to work on their own without interfering with programmers. They'll create a couple of master pages, they'll place slots inside the pages. This is where their responsibility ends. simultaneously you can ask a group of programmers to create portlets (page fragments) that define the functionality of the site / application. then the application designers, UI designers, website content creators are able to put everything together be creating perspectives. They'll be able to do this before the site with all its content (folder, etc...) even exists. Bottom line: there is a very clear separation of roles. You can't do this today, because the roles are too intertwined. I just don't see perspectives adding anything here. The application designer can just as easily use different master pages for different activities/tasks and assigne different portlets to different slots in the different master pages. I see some negatives with perspectives: - They introduce a need for some complex infrastructure. - It's not clear what impact they have on URLs. If, for example, perspectives are set via cookies or session data, then both bookmarking and caching become more complicated. - By introducing modes, I worry that they will make it harder to talk about and teach systems build with them. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: Jim Fulton wrote: ... So, .cps_portlets is a container with an item for each slot, which, is, itself a container? Then users add items to this container to add portlets? that's the Zope2 implementation of local portlets. It has advantages: - the role for managing portlets is the same as the role for managing content in a folder - portlets are visible starting from the folder in which they are stored physically. the drawbacks: - portlets get scattered all over the site, there is no unity. - it is not possible to create a portlet set without first creating the folder in which they'll reside - users must have permission to write in the container to add folders, hence they must have access to the folder Why is this a disadvantage? - difficult import / export I don't follow this. Do you mean that you'd like to export/import portlet assignments independent of everything else? - a traversal is needed from the current folder to the root of the site to determine which portlets will be displayed - portlet ordering is a pain since there is no unique set of portlet. It means that the user has to go into a given folder, add a portlet into a slot and the portlet will be visible starting from this folder. After a while there are 100 of portlets scattered around the entire site, some in /sections/A, some in /sections/A/B some in / ... there is no grouping of portlets. we find out that what users actually want to do is to define a set of portlets that will be shown in a given section of the site (eg. in 'education', in 'research', ...) and only there. Meaning not in subfolders? probably in subfolders too, depending on where the perspective will be used (most certainly starting from a given section of a site, until it is overridden by another perspective) -- this is a separate issue though, since a perspective is not tied to a given folder, object type when it is defined.. In that case, I don't understand why what you have now is inadequate. Now, users define a portlet in exactly one part of a site (and all subfolders). What am I missing? This is somehow done when portlets are stored in folders, but it is very difficult to group the portlets together, because there is no notion of "group of portlets" displayed in given context. I don't know what you mean by "grouping portlets", or why it is a good thing. I mean creating sets of portlets: the set of portlets used in a blog, in a calendar, in a section of a site and being able to treat them as a group. This is for the same reason that user folders have groups of users. You mean you want users to select different collections of portlets for different activities? If so, then why not just use different master pages and slots for the different activities? so basically the notion of perspective is just a way of grouping portlets together and give a name to that collection, so that a user can decide: when I'm in this section of the site, I want to show this set of portlets. This doesn't seem consistent with your current notion of perspectives. in what sense? again there are two separate notions: - the notion of perspective - the notion of applying a given perspective to a given context. Perspectives are about providing separate task-oriented UIs. A perspective is about performing a particular type of task on input. In many ways, it's like the Zope 3 view/adapter model, where we have different views selected by input and by type, where type expresses the kinds of tasks performed. It is not simply an arbitrary grouping of components. currently we manage the separation by using different themes (one for the external site, and one for the "back office"), the slots names are different, so the portlets in the backoffice on not visible on the external site. And how is this solution undersireable? these portlets are associated to different activities and they are usually meant to be seen by different target audiences. I don't understand your answer. 1. I don't know what you mean by "these portlets". Do you mean in the current (undesireable) solution or in the new solution. It seems the statement applies to both. 2) I don't understand why being associated with different activities or targeted to different target audiences is undersireable. Also we have problem when a same slot is present in many pages, the users think that they are add portlets only on a given page, while they end up also being visible in other pages. I'm not sure what you mean by page here. Do you mean theme/master pages or web pages? this is a minor problem actually and I've changed my mind on this issue since last week, I still don't know which pages you were talking about so I don't know what you changed your mind about. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
> ...
>
>> This is what I meant with having a "unifying concept". And that sounds
>> very unifying to me already.
>
>
> Perspectives, if I understand how you are describing them, and how
> Eclipse describes them,
> http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
>
> are simple separate applications. They are different ways of working
> on content
> based on tasks. They could be provided with perspectives, or, more
> simply,
> with different collections of web pages, using different styles. I
> don't understand the benefit you think they provide nor do I see how
> they unify anything.
I've read the article, it is clear to me that the main idea is to be
able to reuse components, not to create a collection of web pages just
to present an application from a slightly different perspective. With 3
master pages and a set of 5 perspectives you get 15 combinations. That
would be 15 pages in html to maintain.
The main idea is to define visibility in a coherent way, not with a
series of CSS hacks (hidden {display:none}), ..., , scattered around 100 page
templates... or by using visibility conditions in the portlets own code.
the assumption is that portlet visibility is not a propriety of
*individual* portlets, but this is something that is related to some
activity of the user, or some usage context.
I think that Eric summarized this quite clearly in his blog:
"""
What for ?
Imagine that when writing a new component, you also can easily define
perspective. Let's take an example : a blog application. Well you can
define a "Blog Perspective" that would be activated when accessing to a
blog and that would arrange the portal to offer a "blog view" putting
portlets in right places. WIth this and the whole CPSSkins machinery, it
would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative
work, personal portal dashboard, etc. The application would then only
define portlets and perspectives (no more pages, view, whatever :-).
>From the user point of view, it would really improve the usability and
how it the portal can adapt itself to his need. The user would also be
albe to define its own perspectives (like it's dashboard) and switch
between them.
It would be new approach in the design of web applications, that would
allow to think them as user-oriented applications and not as a chains of
html pages.
"""
The idea is to move away from the website approach to designing web
applications, with the endless poliferation of templates and macros. I
fully agree though that this is a change from the page / view approach.
/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> By using "perspectives" end-users can also use the portlet editor to >> move portlets on the canvas (as in the google news portal), > > > By end-users, do you mean content managers? Or end-users of the > content? > > Why do they need perspectives to do this? > > Do you envision them being able to control the order of > the portlets? Yes, I think that Rob mentionned that there was such a use case where you had customers who wanted to control the way portlets were disposed on the screen on an individual basis. Generally speaking, portlets are associated to slots but the ordering information is neither stored in the portlet itself nor in the slot, but in a "display element". There are as many display elements associated to a given slot as there are perspectives. In this way visual ordering is not a problem, and it should also be possible to place the portlets inside the slot's display canvas on using (x, y) coordinates. I don't know about a use case for this unless maybe in the content well, I think you mentionned something about this in a previous mail? > > > all that is > >> needed is a portal page with three slots in it > > > Why is the number of slots important? > > ... It's not --- it was an example, it is the number of slots used in google's news portal ... > >> This is what I meant with having a "unifying concept". And that sounds >> very unifying to me already. > > > Perspectives, if I understand how you are describing them, and how > Eclipse describes them, > http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html, > > are simple separate applications. They are different ways of working > on content > based on tasks. They could be provided with perspectives, or, more > simply, > with different collections of web pages, using different styles. I > don't understand the benefit you think they provide nor do I see how > they unify anything. I'm going to put a diagram online showing what they add in terms of separating responsability in the design of a web application, web sites, ... The idea is that the three roles: - theme designer (creates themes, styles, etc...) - programmer (creates portlets, special views for some object types, ...) - application / UI designer (puts all the pieces together) are completely orthogonal. With this you can ask a group of graphic designers to work on some graphic designer for an application, or a site. They'll be able to work on their own without interfering with programmers. They'll create a couple of master pages, they'll place slots inside the pages. This is where their responsibility ends. simultaneously you can ask a group of programmers to create portlets (page fragments) that define the functionality of the site / application. then the application designers, UI designers, website content creators are able to put everything together be creating perspectives. They'll be able to do this before the site with all its content (folder, etc...) even exists. Bottom line: there is a very clear separation of roles. You can't do this today, because the roles are too intertwined. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
> ...
>
>> What problem perspectives solves?
>> --
>
>
> I think I'm ready to respond to this now. I hope, with your current
> thinking that this is still relevent.
>
good :-)
>> local portlets are currently stored in local folders in a .cps_portlets
>> container with the name of the slot in which they are located.
>
>
> So, .cps_portlets is a container with an item for each slot, which, is,
> itself a container? Then users add items to this container to add
> portlets?
that's the Zope2 implementation of local portlets. It has advantages:
- the role for managing portlets is the same as the role for managing
content in a folder
- portlets are visible starting from the folder in which they are stored
physically.
the drawbacks:
- portlets get scattered all over the site, there is no unity.
- it is not possible to create a portlet set without first creating the
folder in which they'll reside
- users must have permission to write in the container to add folders,
hence they must have access to the folder
- difficult import / export
- a traversal is needed from the current folder to the root of the site
to determine which portlets will be displayed
- portlet ordering is a pain since there is no unique set of portlet.
>
>> It means that the user has to go into a given folder, add a portlet into
>> a slot and the portlet will be visible starting from this folder. After
>> a while there are 100 of portlets scattered around the entire site, some
>> in /sections/A, some in /sections/A/B some in / ...
>>
>> there is no grouping of portlets.
>>
>> we find out that what users actually want to do is to define a set of
>> portlets that will be shown in a given section of the site (eg. in
>> 'education', in 'research', ...) and only there.
>
>
> Meaning not in subfolders?
probably in subfolders too, depending on where the perspective will be
used (most certainly starting from a given section of a site, until it
is overridden by another perspective) -- this is a separate issue
though, since a perspective is not tied to a given folder, object type
when it is defined..
>
> > This is somehow done
>
>> when portlets are stored in folders, but it is very difficult to group
>> the portlets together, because there is no notion of "group of portlets"
>> displayed in given context.
>
>
> I don't know what you mean by "grouping portlets", or why it is a good
> thing.
>
I mean creating sets of portlets: the set of portlets used in a blog, in
a calendar, in a section of a site and being able to treat them as a
group. This is for the same reason that user folders have groups of users.
>> so basically the notion of perspective is just a way of grouping
>> portlets together and give a name to that collection, so that a user can
>> decide: when I'm in this section of the site, I want to show this set of
>> portlets.
>
>
> This doesn't seem consistent with your current notion of perspectives.
in what sense? again there are two separate notions:
- the notion of perspective
- the notion of applying a given perspective to a given context.
>
>> In an application, this makes it possible to keep the portlets used by
>> the application (action portlets, navigation portlets) separate from
>> decoration portlets.
>
>
> I'n not sure what you mean. By "application", do you mean the content
> management application, as opposed to the end-user content-delivery
> application?
>
I mean a webmail application, a calendar application, a web publishing
application.
Currently the portlets used in a CMF site for instance are of two kinds:
1) portlets that are used by the web publishing application (workflow
actions), login link...
2) portlets that show content (latest news, info text, ...)
the site visitors are usually not interested in 1)
>> currently we manage the separation by using different themes (one for
>> the external site, and one for the "back office"), the slots names are
>> different, so the portlets in the backoffice on not visible on the
>> external site.
>
>
> And how is this solution undersireable?
these portlets are associated to different activities and they are
usually meant to be seen by different target audiences.
>
>> Also we have problem when a same slot is present in many pages, the
>> users think that they are add portlets only on a given page, while they
>> end up also being visible in other pages.
>
>
> I'm not sure what you mean by page here. Do you mean theme/master pages
> or web pages?
>
> Jim
>
this is a minor problem actually and I've changed my mind on this issue
since last week, I think that slots should be identified by their name
that can be shared between slots located on different pages and not by
an id that is unique per slot, to make it possible for an application
designer to specify the slot in which portlets should be shown ('left',
'right', ...) as it is done with CMFDefault.
I have written a docte
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: ... Concerning unification: During the sprint in Göteborg in June according to what Tres mentionned it appeared to me said that the issue was to make portlets independent of any macro mechanism, and that the they should be treated as page fragments without any assumption about where on the page or inside which template they'll be displayed. I would agree that, generally, page fragment will/should generally be designed independently. We certainly have use cases for being able to explicitly assember page fragments to create pages. This is typically for the "content well". To be more accurate, we often compose pages by assembling views of content such that the views are designed to be page fragments. the idea was to chop the page into pieces and reuse the pieces. the rendering engine in cpsskins is designed to do layouting/styling of the "O wrap" area in the way that *web designers* are used to work with. Yup. By using "perspectives" end-users can also use the portlet editor to move portlets on the canvas (as in the google news portal), By end-users, do you mean content managers? Or end-users of the content? Why do they need perspectives to do this? Do you envision them being able to control the order of the portlets? > all that is needed is a portal page with three slots in it Why is the number of slots important? ... This is what I meant with having a "unifying concept". And that sounds very unifying to me already. Perspectives, if I understand how you are describing them, and how Eclipse describes them, http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html, are simple separate applications. They are different ways of working on content based on tasks. They could be provided with perspectives, or, more simply, with different collections of web pages, using different styles. I don't understand the benefit you think they provide nor do I see how they unify anything. But when it comes to the content well, I strongly think that the layouting is best delegated to other rendering engines, XForms, for instance (Julien could tell you more about it), iCal renderers, Flash plugins, etc.. Otherwise you will lose the generic aspect of cpsskins, and the layout engine will become extremely complicated to manage. I think that the content well should in that case be *one* portlet that knows how to do its own layouting and not be a mixture of portlets. I think we are in agreement here. :) rendering a weekly calendar view would otherwise be a real pain if the meetings booked were portlets... In CPSSkins for Zope2 for instance it is still CPSDocument that creates the layout of documents and it is best done that way I think. Yup. have a nice week-end! Thanks. I did. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: ... What problem perspectives solves? -- I think I'm ready to respond to this now. I hope, with your current thinking that this is still relevent. local portlets are currently stored in local folders in a .cps_portlets container with the name of the slot in which they are located. So, .cps_portlets is a container with an item for each slot, which, is, itself a container? Then users add items to this container to add portlets? It means that the user has to go into a given folder, add a portlet into a slot and the portlet will be visible starting from this folder. After a while there are 100 of portlets scattered around the entire site, some in /sections/A, some in /sections/A/B some in / ... there is no grouping of portlets. we find out that what users actually want to do is to define a set of portlets that will be shown in a given section of the site (eg. in 'education', in 'research', ...) and only there. Meaning not in subfolders? > This is somehow done when portlets are stored in folders, but it is very difficult to group the portlets together, because there is no notion of "group of portlets" displayed in given context. I don't know what you mean by "grouping portlets", or why it is a good thing. so basically the notion of perspective is just a way of grouping portlets together and give a name to that collection, so that a user can decide: when I'm in this section of the site, I want to show this set of portlets. This doesn't seem consistent with your current notion of perspectives. In an application, this makes it possible to keep the portlets used by the application (action portlets, navigation portlets) separate from decoration portlets. I'n not sure what you mean. By "application", do you mean the content management application, as opposed to the end-user content-delivery application? currently we manage the separation by using different themes (one for the external site, and one for the "back office"), the slots names are different, so the portlets in the backoffice on not visible on the external site. And how is this solution undersireable? Also we have problem when a same slot is present in many pages, the users think that they are add portlets only on a given page, while they end up also being visible in other pages. I'm not sure what you mean by page here. Do you mean theme/master pages or web pages? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
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] [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
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
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] [DRAFT] local portlets and perspectives
Hi! concerning perspectives, what would be the use cases? I talked with Eric, we came up with: activity-driven perspectives: --- - browsing perspective (going through folders, finding documents, ..) - dashboard perspective (tasks list, documents to review, etc..) - collaboration perspective (diffing content, svn, synchronising content, etc) - contributing perspective (document creation, publication, ..) - ... => it is the application / workflow that sets the perspective location-based perspectives: --- - when entering a given section of the site, a new set of portlets is displayed in some of the page's slots - the user's home folder/ perspective with the ability to rearrange portlets within some limits. => it is the site location that sets the perspective the roles would be divided in: - - theme / page designer (responsible for preserving the site's design, corporate profile, logotype, etc..). - content designer (responsible for adding portlet content to the site using images, text, putting ads on the front page, etc) - perspective / UI designer (responsible for visually placing activity portlets inside a given application, action portlets, navigation portlets) --- the configuration would be saved in zcml as part of the application. - user (wants to re-arrange portlets on the work space / create new portlets cf. google news portal) any comment / ideas? /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
Michel Pelletier wrote: >On Thu, 2005-08-25 at 04:10 +0200, Jean-Marc Orliaguet wrote: > > > >>You would need a quadruple store in that case (see the previous mail) - >> >> > >rdflib.Graph is actually a quadruple store. Many users still say >TripleStore because that was the old class name, but most RDF systems, >rdflib included, have grown a concept called "context" a quad-element >that lets you assign context to a triple, sparql calls this the >"source", and some people say that it is used to track the "provenance" >of a triple. Perhaps this is similar to the triadiac relations. > > > OK, but the idea is that you can choose the elements in the relation, if one them is set in advance, this is just an extra parameter that is stored. >>if you have (Subject, Predicate, Object) in RDF >> >>here you have: >>- monadic relation: (first, predicate) >>- dyadic relation: (first, second, predicate) >>- triadic relation: (first, second, third, predicate) >> >> > >Ok, so in RDF a dyadic relationship is (DocumentURI, dc:title, "Expense >Report"), what would a similar triadic relationship be? > > >-Michel > > (SellerURI, merchandiseURI, BuyerURI, "Sale Transaction") in a sale transaction a seller sells some merchandise to a buyer the relation involves three dyadic relations: - a relation between the seller and the buyer, - a relation between the seller and the merchandise - a relation between the merchandise and the buyer but the transaction involves all three elements taken together, not any two of the three taken separately. let's put it that way: you can store dyadic relations in you database and do queries to guess who the buyer is in a given transaction, who the seller is and what the sold item is, but this will never represent the transaction itself. everything that involves some sort of agreement, laws, regulations, general concepts is triadic. Remove the agreement and the dyadic relations will fall. one practical example is the one of a feeback loop. If you try to decompose it into dyadic relations the feedback loop will stops working because all three elements must be taken together (see the second part of the message in this thread too: http://suo.ieee.org/email/msg10941.html ) an adapter is involved in a triadic relation too, when you declare the adapter you have to specify the interface adapted, the interface implemented and the factory. remove any of the three elements and the "adapter" relation will make no sense. BTW adapter are stored in zcml as triadic predicates: regards /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
On Wed, 2005-08-24 at 22:25 -0400, [EMAIL PROTECTED] wrote: > Subject: Re: [Zope3-dev] [DRAFT] local portlets and perspectives > > 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 think that Michel uses a triple BTree store in zemantic to index all > three elements (subject, predicate, object), the idea here is the same > except that relations can be triadic, (which gives 4 elements to index) > this is why I index the relates with _indexRelates() and the predicate > with _indexPredicate(). I didn't do a thorough analysis of your code, but I'm beginning to suspect that the Peirce concept of "perspective" is identical to the RDF concept of "context" and that the two models are possibly isomorphic. I read into the philosophy paper a bit more and got that a triple is a statement of fact and not an actual realization without the fourth perspective element which defines the context with which to apply that fact. If this is correct then that is essentially exactly what RDF contexts are for. I don't mean to imply that it invalidates your experiments! Your code is interesting and it may indeed have some feature benefits over rdflib. I just mean that I suspect, with very little analysis on my part mind you, that they may be similar if not eventually identical models. > Also most importantly the elements of the relation are also indexed as > one unique tuple, which means that I do can a direct lookup in the > catalog if *all* the elements are specified during the query. ditto with rdflib, a context as well as a triple pattern can be passed to the add/remove/query methods of a graph, although this context information is optional. -Michel ___ 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
On Thu, 2005-08-25 at 04:10 +0200, Jean-Marc Orliaguet wrote: > You would need a quadruple store in that case (see the previous mail) - rdflib.Graph is actually a quadruple store. Many users still say TripleStore because that was the old class name, but most RDF systems, rdflib included, have grown a concept called "context" a quad-element that lets you assign context to a triple, sparql calls this the "source", and some people say that it is used to track the "provenance" of a triple. Perhaps this is similar to the triadiac relations. > if you have (Subject, Predicate, Object) in RDF > > here you have: > - monadic relation: (first, predicate) > - dyadic relation: (first, second, predicate) > - triadic relation: (first, second, third, predicate) Ok, so in RDF a dyadic relationship is (DocumentURI, dc:title, "Expense Report"), what would a similar triadic relationship be? -Michel ___ 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
Michel Pelletier wrote: >On Wed, 2005-08-24 at 15:28 -0400, [EMAIL PROTECTED] wrote: > > > >>Message: 5 >>Date: Wed, 24 Aug 2005 20:24:30 +0200 >>From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> >>Subject: [Zope3-dev] [DRAFT] local portlets and perspectives >> >> > > > > >>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've been looking for more info on Peirce relations since you mentioned >them to me in Paris, but I haven't found much. This is a good one I've >found so far: > >http://www.angelfire.com/md2/timewarp/peirce.html > >I like: > >"""According to Peirce, ‘meaning’ is a triadic relation between a sign, >an object, and an interpretant. This triadic relation is not reducible >to a set of dyadic relations between a sign and an object or between an >object and an interpretant (CP 1.345). Meaning is never reducible to >Firstness or Secondness, but can only be a ‘genuine’ Thirdness. A >general meaning can always be found in ‘genuine’ triadic relations, but >can never be found in ‘degenerate’ triadic relations which have lost >their Thirdness.""" > >Word. But it sounds to me from the description that follows that RDF is >a triadic relation, but I'm no semiotic phenomenologist. Do you know of >more references on this subject? > >Another thought, can a Peirce relation be meta-encoded in RDF? > >-Michel > > > Hi Michel! You would need a quadruple store in that case (see the previous mail) - a triple store is not enough, since in the triple store one place is already taken by the predicate. if you have (Subject, Predicate, Object) in RDF here you have: - monadic relation: (first, predicate) - dyadic relation: (first, second, predicate) - triadic relation: (first, second, third, predicate) then not necessary all triadic relations are genuine, but at least there are three elements in them and a unity which a combination of dyadic relations won't give you. see also: http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/doc/peirce-relations.txt /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
Gary Poster wrote: > > On Aug 24, 2005, at 2:24 PM, 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). > > Hi Gary! > I need to read more to have a more complete reply (though I'm hoping > Benji will do it for me, since he knows more about CPSSkins than I), > but here are a few responses, based on reading it and talking it over > with Benji. > > Your overall model is interesting to me because it goes a good way to > unifying the various portlet use cases. I know of six categories: > page designer wants to fill slots for a site; page designer wants to > fill slots for a section of a site; page designer wants to fill slots > for a page on a site; user wants to fill slots for a site; user wants > to fill slots for a section of a site; and user wants to fill slots > for a page on a site. The section and page use cases might be > collapsed technically, but have a different feel to a user, IMO, and > so should be separated. Combining these into a unified model is > impressive and cool. > > I worry that the description does not get into the possible UI > expectation differences between a page designer and a user, and > between working on a site or section versus a single page. These > seem like tricky UI bits to get right to me. I'd be interested in > seeing a discussion of your thoughts of the UI from this perspective, > especially in regards to showing a user, within an editing screen, > which portlets are being edited from a page perspective, from a per- > user perspective, from a section perspective, and so on. It seems > like it could cause information overload. > I'll get back to this part in a mail later since the answer is longer. But basically: - there is a separation between page designer (theme designer) space and user space. Page designers add portlets into cells and users add portlets to slots. A same theme can have several pages, and pages can be associates to sections of the site. A page is a page (not a perspective). Perspectives are only for portlets in slots. - the main idea with perspectives is that you can group contextual information into a few categories: 1) let us say for instance: the category of users that have just logged in for the first time. These users would see the site from "the first login perspective", maybe be presented with a "Welcome" portlet. 2) a "perspective designer" (in this case an application designer) would in a blog application create a "Blog perspective" for users, where they'd see the blog categories, the archived blogs, etc. Currently this is done in CPSBlog by creating local portlets for every user which is not very efficient in terms of scalability. 3) in a webmail application the "perspective designer" would set up an INBOX portlet, a toolbox portlet for sending mail, etc. as a result the end user would move from a "blog" perspective to a "webmail" perspective even maybe by staying in the same folder (which is not easy to implement with the notion portlets associated to sections of a site) This shows that the notion of sections of a site is not appropriate for local portlets, it is better to use a more general concept such as the one as Perspective. Also if there are many sections in a site, there are in comparison very few perspectives. In fact when it comes to the question of the visibility of portlets (visible in some folders of the site) this will be done by using a visibility filter (the infrastructure is already implemented cf. http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png) Hence for a given user there won't typically be more than 4 or 5 perspectives in the portal. I have prototype soon ready, that will become clearer with an animation. > The 'perspective' idea is a good concept for the discussion (and I > used the word above), but you claim that it is a single element in a > triadic relationship, then list several perspectives, each of which > could influence the lookup. This means to me that it is not triadic > but 'n-ary'. Moreover, it seems a lot more like a graph walk, for > which we don't need new code in CPSSkins, than a new n-ary data >
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
On Wed, 2005-08-24 at 15:28 -0400, [EMAIL PROTECTED] wrote: > Message: 5 > Date: Wed, 24 Aug 2005 20:24:30 +0200 > From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> > Subject: [Zope3-dev] [DRAFT] local portlets and perspectives > 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've been looking for more info on Peirce relations since you mentioned them to me in Paris, but I haven't found much. This is a good one I've found so far: http://www.angelfire.com/md2/timewarp/peirce.html I like: """According to Peirce, ‘meaning’ is a triadic relation between a sign, an object, and an interpretant. This triadic relation is not reducible to a set of dyadic relations between a sign and an object or between an object and an interpretant (CP 1.345). Meaning is never reducible to Firstness or Secondness, but can only be a ‘genuine’ Thirdness. A general meaning can always be found in ‘genuine’ triadic relations, but can never be found in ‘degenerate’ triadic relations which have lost their Thirdness.""" Word. But it sounds to me from the description that follows that RDF is a triadic relation, but I'm no semiotic phenomenologist. Do you know of more references on this subject? Another thought, can a Peirce relation be meta-encoded in RDF? -Michel ___ 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
On Aug 24, 2005, at 2:24 PM, 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 need to read more to have a more complete reply (though I'm hoping Benji will do it for me, since he knows more about CPSSkins than I), but here are a few responses, based on reading it and talking it over with Benji. Your overall model is interesting to me because it goes a good way to unifying the various portlet use cases. I know of six categories: page designer wants to fill slots for a site; page designer wants to fill slots for a section of a site; page designer wants to fill slots for a page on a site; user wants to fill slots for a site; user wants to fill slots for a section of a site; and user wants to fill slots for a page on a site. The section and page use cases might be collapsed technically, but have a different feel to a user, IMO, and so should be separated. Combining these into a unified model is impressive and cool. I worry that the description does not get into the possible UI expectation differences between a page designer and a user, and between working on a site or section versus a single page. These seem like tricky UI bits to get right to me. I'd be interested in seeing a discussion of your thoughts of the UI from this perspective, especially in regards to showing a user, within an editing screen, which portlets are being edited from a page perspective, from a per- user perspective, from a section perspective, and so on. It seems like it could cause information overload. The 'perspective' idea is a good concept for the discussion (and I used the word above), but you claim that it is a single element in a triadic relationship, then list several perspectives, each of which could influence the lookup. This means to me that it is not triadic but 'n-ary'. Moreover, it seems a lot more like a graph walk, for which we don't need new code in CPSSkins, than a new n-ary data index. RDFLib or any similar graph implementation with typed relationships would get the efficiency you want, as far as I can tell, with a lot less new code to maintain. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
