OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [wsrp][interfaces]: Portal Usage Scenario

Again,  I separate the portal's perspective from the portlet's perspective -- (for
the time being assuming the producer manages its own customization data).  From
the Portal's perspective the portlet instance is the element in its persistent
structure that maps logically to an entity represented by the portal service which
in conjunction with other information (the current user) can be joined into a key
that identifies a particular set of state (user customizations, etc) that
act/constrain the behavior/output of the service to present the proper effect.

Your use of portlet instance seems to come from the portlet point of view -- a
persistent representation of a users stock portfolio -- I am not (yet) trying to
have us define terms at the WSRP model level.  My portlet instance is more like
the Portal's knowledge that your "portlet view" can exist.  From this perspective
one thing a portal does to an portlet instance is to "view" it.

Thomas Schaeck wrote:

> I think the question is just whether with "portlet instance" you mean the a
> persistent entity that is displayed by "portlet view" or "active portlet
> instance" as Gil proposed
> or whether with "portlet instance" you mean the portlet view and you use
> another word for the persistent entity.
> In the first case, this would be an example:
> A portlet instance exists as a persistent entity in the database. In the
> case of a stocks portlet, it may contain a list of stock symbols of
> interest for a user.
> The portlet instance exists across requests and even when the user logs out
> from the portal.
> The "portlet view" or "active portlet instance" only exist when a page is
> being viewed.
> Best regards,
> Thomas
> Eilon Reshef <eilon.reshef@webcollage.com> on 04/15/2002 10:09:17 PM
> Please respond to Eilon Reshef <eilon.reshef@webcollage.com>
> To:    "'Michael Freedman'" <Michael.Freedman@oracle.com>
> cc:    "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Sasha Aickin'"
>        <AlexanderA@plumtree.com>, wsrp@lists.oasis-open.org
> Subject:    RE: [wsrp][interfaces]: Portal Usage Scenario
> Makes sense. My only personal  confusion: what would be a concrete scenario
> where - to Gil's first question -  no user is seeing a portal page and yet
> a portlet  instance exists?
> Eilon
> -----Original Message-----
> From: Michael Freedman  [mailto:Michael.Freedman@oracle.com]
> Sent: Monday, April 15, 2002  3:21 PM
> To: Eilon Reshef
> Cc: 'Gil Tayar'; 'Sasha Aickin';  wsrp@lists.oasis-open.org
> Subject: Re: [wsrp][interfaces]: Portal  Usage Scenario
> I wonder if some of the confusion comes  from point-of-view.  The terms I
> have set out to define are defined from  the perspective of the portal.  At
> this point there are no assumptions or  terms defined from the perspective
> of the portlet.  I.e. I have been  attempting to define how a portal
> interacts with a portlet through the  lifecycle of a bound service without
> discussing how this service models the  behaviors.  For example -- from a
> portal perspective a portlet instance  is element in the portal the
> structure -- its likely that from a portlet  modeling perspective the API
> will represent the portals operations on the  instance as a runtime (only)
> thing.  I.e. in the end the portal talks to  a portlet service for all
> operations (there aren't multiple  objects/services).  Operations are
> defined not only by the method of the  service itself but by the (form of)
> data passed to the method.
> As for whether we should define/discuss the design time -- First my goal
> was to capture the portals perspective so we could discuss what WSRP should
> concern itself with.  In our concall last week, including portlet
> templates (design-time) was discussed.  A number of portal vendors
> indicated they will need to define this behavior anyway -- and would prefer
> a  standard for it.  We decided however to tackle the portlet instance case
> first as it seemed more basic -- and once this level of the API was in good
> shape to come back and look at portlet templates.
>       -Mike-
> Eilon Reshef wrote:   See my answers below.  As Thomas noted, I think it's
> mainly a terminology question, but I think  it's important that eventually
> we all sync  up.My line of thought is that design-time is a pretty complex
> thing,  that we may or may not need to standardize, and there's a
> portal-specific or  portlet-specific workflow that results in possibly
> portlet templates,  all of which are persistent (so there could be an
> administrator portlet  template, then a superuser portlet template, then a
> portlet for an  individual user).Whenever an individual  views the page,
> then a portlet instance is created, to  generate the view.Eilon
> -----Original Message-----
> From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
> Sent: Sunday, April 14, 2002  2:11 AM
> To:  'Sasha Aickin'; Michael Freedman
> Cc: wsrp@lists.oasis-open.org
> Subject: RE: [wsrp][interfaces]: Portal  Usage Scenario
> Mike,The definition for portlet instance as a "a  portlet in the portal
> layout structure" is still confusing. Let me ask a  question which will
> maybe make things clearer between us - if no user is  seeing a portal page,
> does a portlet instance  exist?If the answer is  yes, then a portlet
> instance is not (only?) a runtime  manifestation. Moreover, we do not have
> a name for the runtime  manifestation, and I feel we should.If the answer
> is no, then what is the  word for the design time manifestation? Is it the
> "portlet  template"?My feeling is that  there should be concensus on the
> answer to this question, so that we will  be on common ground on this very
> important term - portlet  instance.So, let me re-ask  the question (and I
> would really appreciate if all WSRP members  could answer), and make them
> more answerable  : 1. If no user is  seeing no portal page at a certain
> point in time, does a portlet instance  exist at that time?Answers:( ) Yes
> (  X ) No  The portlet  instance is a run-time object  only. ( ) Other:
> ____________________________________________________________________2. If a
> user is  seeing a portal page at a certain point in time, is it the portlet
> instance which is rendering the  portlet?Answers:(  X ) Yes  Yes, the
> portlet instance generates the markup in  run-time ( ) No( ) Other:
> ____________________________________________________________________Cheers,Gil
> -----Original Message-----
> From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
> Sent: Friday, April 12, 2002  07:10
> To:  Michael Freedman; Gil Tayar
> Cc: wsrp@lists.oasis-open.org
> Subject: RE: [wsrp][interfaces]: Portal  Usage Scenario
> Mike,I'd like to offer a slight  clarification, if I could:  I think that
> WSRP/portlets care about a  clone only if the service maintains its
> personalization data AND the  portlet service has to maintain information
> about each portlet instance  on each page.  I feel like, as I think Yossi
> said earlier, that the  portal could implement clone by simply including
> the same instance on  two pages.  That way, WSRP would not need to know
> about cloning  even if the portlet service maintained personalization
> data.Cheers,Sasha.
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Wednesday, April 10,  2002 2:24 PM
> To: Gil Tayar
> Cc: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp][interfaces]:  Portal Usage Scenario
> I believe that is  how we have defined things:
>     portlet  instance: a portlet on a page; or more generically a portlet
> in  the portal layout structure.  From a portal's perspective, the  portlet
> instance is the  realization of the portlet in the  runtime layout
> structure.  A portlet instance is derived from a  portlet template.  e.g.
> when adding a portlet to a page,  the  user chooses a portlet template
> (from the toolbox).   The template is used to "type" the instance being
> created.
>    personalization data: a set of customized data  settings for a portlet
> instance. There is an 1 to N relationship  between personalization data and
> portlet instances.  1 set of  personalizations may be shared between
> multiple instances.
> What is/was a little confusing was Yossi statement that "the same  portlet
> instance appears in different places in the portal  structure".  That is
> not what I had indicated in my reply to him  -- rather I said was
> "personalization [data] can be shared between  multiple portlet instances
> of the same type."  I.e. portlet  instances ARE your runtime manifestations
> on a page.  There is a  special case where two of these happen to share the
> same  personalization data.  This tends to come into existence  via some
> kind of clone operation.  WSRP/portlets care about this  in the situation
> the service maintains its personalization data.
> I hope this helps.
>      -Mike-
> Gil Tayar wrote:  I second #1,  as I outlined in my previous email. I
> submit that what is confusing  is the term "portlet instance". I would
> prefer "portlet instance  data" or "portlet customization data" and leave
> "portlet instance"  to the runtime manifestation on the page, e.g. only
> when the user  views it.
> -----Original Message-----
> From: Tamari, Yossi [mailto:yossi.tamari@sapportals.com]
> Sent: Tuesday, April  09, 2002 11:28
> To: wsrp@lists.oasis-open.org
> Subject: RE:  [wsrp][interfaces]: Portal Usage Scenario
> Thanks for the answers, but I'm still  not satisfied on 1 and 2...1.  What
> bothers me here is that the fact the same portlet instance  appears in
> different places in the portal structure is completely  handled by the
> portal. The producer does not know/care where this  instance is in the
> portal pages. Hence while the feature is  logical in the portal framework,
> I don't see its relevance to  WSRP.2. I see your point, I'm just worried
> about performance. We should give this some more thought. Maybe  the
> metadata could either give a URL\title or say that it is  dynamic.
> Yossi.
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Tuesday, April  09, 2002 12:06 AM
> To: Tamari, Yossi
> Cc:  wsrp@lists.oasis-open.org
> Subject: Re:  [wsrp][interfaces]: Portal Usage  Scenario
> Good questions.
> 1. What I meant when I said that personalization data can be  shared
> between multiple instances is that the personalization  can be shared
> between multiple portlet instances of the same  type.  For example I can
> have two instances of a Stock  portlet that share the same personalization
> data.  In this  case both instances display the same result.  When either
> is customized, the changes are reflected in both as the  personalization
> data is shared.  This generalization allows  a consumer to expose the same
> portlet (result) from different  levels in its structure.  Remember, a
> portlet instance is  defined as a particular reference in the structure
> (portlet on a  page).  If you want the same content in two locations in
> the structure you need the function defined here.  One use  of this is in a
> portal that supports access from multiple  devices.  One can envision the
> need to allow portal  designers/users to maintain different portal
> structures between  the device (types).  However, in such a world the end
> user  still wants access to the same content.  Cloning is an  operation
> that can be used create a second portlet instance with  the characteristics
> that its personalization data is  shared.  So a cloned instance is one that
> has the  characteristics described above.
> 2.   Yes, requesting a portlet instance to render a  link reference to
> itself does mean you ask the portlet to render  an URL that returns its
> content as markup.  I agree that  this operation can often be defined by
> meta-data.  However  it may not always be static.  In both this case and
> the  case we need to render a title bar for the portlet we must allow  a
> way for the portal (consumer) to acquire the portlet's  (producers) title.
> This is because the title is commonly  personalizable -- hence dynamic.
> Further discussions will  resolve whether this occurs during a render
> operation (get  "Link") or is merely a getTitle API that returns a string.
> Done in the former the portlet gets an opportunity to  define/override the
> standard getContent URL -- hence I included  it in the list.
> 3.  Whether changes to a portlet template's settings  should affect
> existing instances is a good question.  We  should discuss this in the next
> phase.  I will add it to  the questions list in this area.  I will also
> remove the  statement from the document (so it can be added once
> answered).  I agree there are basic configuration settings  that should be
> propagated.  An example would be a news feed  portlet that requires the URL
> of the source be entered to wire  the portlet to a particular news feed.
> If this URL changes  there needs to be a way for the update to alter
> existing  instances.  On the flip side, one can also envision some
> template settings being the initial personalization for an end  user.  Its
> not as clear if these values should be  propogated particularly if there is
> support for > 1 level of  personalization in the instance.
> Hope this helps.
>     -Mike-
> "Tamari, Yossi" wrote:  Hi  Mike,I need some  clarifications:1.
> personalization data - What does it mean that it  can be shared between
> multiple instances? do you mean  instances of the same portlet? if so, why
> is that a different  instances, i.e. why should the consumer request the
> exact same  data twice? And how is that different from a cloned
> instance?2. "You can  request a portlet instance render a link reference to
> itself" - Does that mean you ask the portlet for a URL that  returns its
> content as markup? I think this should be part of  the meta-data, as it
> does not need to be truly  dynamic.3. Why should  changes to the portlet
> template's settings not affect  existing instances? If the name of my
> company was change, I  want the new name rendered in ALL the instances.
> Yossi.
> -----Original  Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Saturday,  April 06, 2002 9:53 PM
> To: WSRP
> Subject:  [wsrp][interfaces]: Portal Usage  Scenario
> I have attached a short document  describing a portal's possible usage
> pattern for portlets  using the terms we discussed last week.  Please
> comment/annotate with new operations or suggested operations  to remove.
> Please don't annotate with questions  intended to clarify the behavior of
> the operation, send  these separately. The goal for this Thursday's meeting
> is to  see if we can agree on a preliminary usage pattern and  collection
> of operations. Hopefully we can then move into  enumerating the questions
> we need to answer.  In our  discussion on Thursday, I expect we will need
> to classify at  least the operational aspects of the usage scenario along
> two axes:
> Axis 1:  Is this a valid Portal operation?
>    Yes, we all agree this a valid operation
>    No, we all agree this is not a valid operation
>    Maybe, there is debate whether this is a valid  operation.
>    Don't know, we need more information and discussion to  understand the
>    operation before classifying it.
> Axis 2: Should this operation be covered/enabled by  our spec?
>    Yes, we all agree.
>    Yes, but it should be addressed in a later revision.
>    No, we all agree.
>    Maybe, there is debate whether we should address this.
>    Don't know, we need more information to decide.
> It might be useful if each of you did your own  classification (assuming of
> course the usage scenario isn't  grossly controversial).
>     -Mike-
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC