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

2005-08-31 Thread Jim Fulton

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

2005-08-31 Thread Jean-Marc Orliaguet
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
 similar sorts of design decisions.


I'm really interesting in learning about your use cases, because it
could be that you have use cases that 

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

2005-08-30 Thread Tonico Strasser

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:

page
  body metal:use-macro=macros/body/
/page

ZPT_B:

body metal:define-macro=body
  !-- render boxes here --
  box metal:use-macro=macros/box_repeat/
/body

box_repeat macro:

div class=box
 metal:define-macro=box_repeat
 tal:repeat=box lboxes
 tal:attributes=id box/id
  h1 class=box-header
  tal:content=box/title/
  div class=box-body
   metal:use-macro=box/macros/body|default/
/div

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: [Z3lab] Re: [Zope3-dev] [DRAFT] local portlets and perspectives

2005-08-30 Thread Jean-Marc Orliaguet
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:

 page
   body metal:use-macro=macros/body/
 /page

 ZPT_B:

 body metal:define-macro=body
   !-- render boxes here --
   box metal:use-macro=macros/box_repeat/
 /body

 box_repeat macro:

 div class=box
  metal:define-macro=box_repeat
  tal:repeat=box lboxes
  tal:attributes=id box/id
   h1 class=box-header
   tal:content=box/title/
   div class=box-body
metal:use-macro=box/macros/body|default/
 /div

 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

2005-08-30 Thread Jim Fulton

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: [Zope3-dev] [DRAFT] local portlets and perspectives

2005-08-30 Thread Jean-Marc Orliaguet
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

2005-08-30 Thread Jim Fulton

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

2005-08-30 Thread Jim Fulton

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: 

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

2005-08-30 Thread Jean-Marc Orliaguet
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.

yes indeed, the doctest does not use relations, so the link is hardcoded
to avoid having to set up the relation stores.

generally speaking I have nothing against adapters, in the 

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

2005-08-29 Thread Jim Fulton

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

2005-08-29 Thread Jim Fulton

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

2005-08-29 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

 What problem perspectives solves?
 --


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

good :-)

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


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

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

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

the drawbacks:

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


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

 there is no grouping of portlets.

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


 Meaning not in subfolders?


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


  This is somehow done

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


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

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

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


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


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


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


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

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

the site visitors are usually not interested in 1)

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


 And how is this solution undersireable?


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


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


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

 Jim

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

I have written a doctest that explains this:

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

2005-08-29 Thread Jean-Marc Orliaguet
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

2005-08-29 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

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


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

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


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

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

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

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


What for ?

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

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



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

/JM


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



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

2005-08-29 Thread Jim Fulton

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:
...



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



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

Why do they need perspectives to do this?

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




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


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

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


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


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

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


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


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

...

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



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

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




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

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

are completely orthogonal.

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

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

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

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


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

I see some negatives with perspectives:

- They introduce a need for some complex infrastructure.

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

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

Jim

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

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

2005-08-29 Thread Jim Fulton

Jean-Marc Orliaguet wrote:

Jim Fulton wrote:



Jean-Marc Orliaguet wrote:
...



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



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

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




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


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


 With 3

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


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


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


We're both in favor of that.



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


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


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


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


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


What for ?

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

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

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

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



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


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

Here's what I think you are proposing:

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

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

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

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

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

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

Jim

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



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

2005-08-29 Thread Jean-Marc Orliaguet
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

2005-08-29 Thread Jim Fulton

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

2005-08-29 Thread Jim Fulton

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

2005-08-29 Thread Jim Fulton

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

2005-08-29 Thread Jean-Marc Orliaguet
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

2005-08-29 Thread Jean-Marc Orliaguet
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

2005-08-26 Thread Jean-Marc Orliaguet
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 browser:page / 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

2005-08-26 Thread Jim Fulton

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 browser:page / 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

2005-08-26 Thread Jim Fulton

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 browser:page / 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

2005-08-26 Thread Jean-Marc Orliaguet
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 browser:page / 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

2005-08-26 Thread Jim Fulton

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

2005-08-26 Thread Jim Fulton

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

2005-08-26 Thread Jean-Marc Orliaguet
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

body tal:content=structure python:pageview(
  tmutil=tmutil,
  context_obj=context,
  view=view,
  engine='default') /



 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

2005-08-26 Thread Jean-Marc Orliaguet
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 browser:page / 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

2005-08-26 Thread Jim Fulton

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 browser:page / 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

2005-08-26 Thread Jim Fulton

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

body tal:content=structure python:pageview(
  tmutil=tmutil,
  context_obj=context,
  view=view,
  engine='default') /


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

2005-08-26 Thread Jean-Marc Orliaguet
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 browser:page / 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, not just the text
contained in the mail ...

/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

2005-08-26 Thread Jim Fulton

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 browser:page / 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 

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

2005-08-26 Thread Jean-Marc Orliaguet
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

2005-08-26 Thread Jim Fulton

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

2005-08-26 Thread Jean-Marc Orliaguet
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 area in the way that *web designers* are used to work with.
By using perspectives end-users can also use the portlet editor to
move portlets on the canvas (as in the google news portal), all that is
needed is a portal page with three slots in it

If the application 

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

2005-08-25 Thread Jean-Marc Orliaguet
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:

  adapter
  for=.ISomeInterface
  factory=.SomeFactory
  provides=.ISomeOtherInterface
  /

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

2005-08-25 Thread Jean-Marc Orliaguet


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

2005-08-24 Thread Michel Pelletier
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

2005-08-24 Thread Jean-Marc Orliaguet
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

2005-08-24 Thread Michel Pelletier
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

2005-08-24 Thread Michel Pelletier
On Wed, 2005-08-24 at 22:25 -0400, [EMAIL PROTECTED] wrote:

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

JM
  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).

later said...
 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