[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified
Hi Andre,
I disagree here, this is yet another usage pattern for MarkupContext.
I think that MarkupContext should be handled in the same way, no matter
whether it was returned from getMarkup() or performBlockingInteraction().
Furthermore we have added MarkupContext to the UpdateResponse as an
optimization to save the additional getMarkup() call if markup can be
returned from pba() - that's one reason why MarkupContext should be handled
in the same way for both operations.
Why do you want to return a title in pba() and the let the Consumer call
getMarkup() right after this to obtain the markup? Why couldn't in this
case the title be returned in the getMarkup() response?
If you just want to change the title in pba() but remain the markup in the
portlet fragment this would implicitly mean that the consumer has to cache
the markup always - even if we don't call it caching here? Couldn't for
that purpose the usedCachedMarkup flag be set to true? (Consumer supporting
caching would adher to the pattern you want).
So again even if I stress it, here is my interpretation/usage pattern of
MarkupContext.
1. if pba() doesn't return MarkupContext in the UpdateResponse, i.e. it
doesn't occur on the wire (btw. it isn't nillable), then the Consumer
subsequently calls getMarkup() to obtain the markup.
2. if MarkupContext is returned within UpdateResponse, then the Consumer
handles it in the same way as if would have returned it from getMarkup()
and doesn't call getMarkup() any more.
3. if markupString and markupBinary is missing, then it is interpreted as
"there is no content to display in the portlet's fragment", i.e. the
consumer can choose to display "" for a better end user experience instead
of throwing faults. In this case also the mimeType is missing in
MarkupContext.
4. if either markupString or markupBinary is there, then it is interpreted
as "display exactly this markup". In this case the mimeType must be passed
with MarkupContext.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 07/18/2003 09:21 |
| | AM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-interop@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Rich, thanks for the clarifications.
However, I still have a problem with 3b. How can performBlockingInteraction
return a new peferredTitle and no markup?
In this case markupContext is not nill or missing and has:
(a)markupContext.peferredTitle = "some new title"
(b)markupContext.mimeType, markupContext.markupString and markupBinary are
all null.
Should (b) not be interpreted as "set title and call getMarkup", rather
than skipping getMarkup and displaying an "" to the user (the latter is
what I understood from the minutes)? I don't want to be forced to use the
early markup optimzation just to set a title.
And, in future CacheControl may be returned without markup from pbia, so we
should not be defining rules like "if these fields are null then this means
skip getMarkup" (or checking for (a and b) as a special case) as this can
not be expressed in wsdl. I would prefer to make (b) mean call getMarkup
for pbia. For getMarkup (b) can mean show a "" to the user just to make
consumers more robust.
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 17 July 2003 18:36
To: wsrp-interop@lists.oasis-open.org
Subject: RE: [wsrp-interop] Groups - WSRP Interop SC call modified
Sorry my notes weren't clearer.
1a) We thought it would be useful to have a convention for a value to
use in this common case. We preferred to take it from the wsrp
namespace, but a convention can not define new values for a
namespace. As a result we have an odd, but reasonable value for the
convention.
3b) Apparently I wasn't clear enough. As an optional element, the
MarkupContext can be missing. Some implementation may prefer to
actually send it as a nil element. In both cases, this will stimulate
the Consumer to invoke getMarkup. Returning a non-nil MarkupContext
will be taken as having provided the markup for this user
interaction.
4bi3) Yes, the Producer may throw an OperatioFailed fault. In no case
is it sensible for a Consumer to presume that the persistent state of
a POP may be written. Specifying this will likely return normally
when no persistent state change was attempted and return a fault
when a state change is attempted.
Rich Thompson
Andre Kramer
<andre.kramer@eu.citrix.com> To:
wsrp-interop@lists.oasis-open.org
cc:
07/17/2003 01:15 PM Subject: RE:
[wsrp-interop] Groups - WSRP Interop SC
call modified
Apologies for joining late on the the call.
1a - the convention of userContextKey="wsrp:minimal" is weird, but
it's just a convention, right? Some systems have a guest system group
that can be used as the basis for a real userContextKey.
I don't understand 3.b:
"The signal for getting getMarkup called is a nil MarkupContext or
missing." - or missing what? Could it be missing mimetype? I would
like to be able to return a new preferredTitle with and without
markup from pbia. Also, in future we may be passing back a
CacheControl without markup.
4 b(producer side) i(POP being accessed)
3(PortletStateChange=readWrite -> make no sense, throw
OperationFailed)
- in the general case this is just: "the producer may throw an
Operation failed".
i.e. only makes "no sense" for JSR portlet?
My question is: how does a non-JSR168 portlet know that POP readWrite
is not allowed? We don't expect it to catch OperationFailed and retry
with readOnly do we?
thanks,
Andre
-----Original Message-----
From: richt2@us.ibm.com [mailto:richt2@us.ibm.com]
Sent: 17 July 2003 17:35
To: wsrp-interop@lists.oasis-open.org
Subject: [wsrp-interop] Groups - WSRP Interop SC call modified
WSRP Interop SC call has been modified by Rich Thompson
(richt2@us.ibm.com).
Event description:
Shared timeslot with Conformance SC and biweekly TC call.
USA Toll Free Number: 877-718-0936
USA Toll Number: +1-712-923-6878
PARTICIPANT PASSCODE: 402957
Agenda:
Date: Thursday, 17 July 2003
Time: 11:00am - 01:00pm Eastern Time
This event is one in a list of recurring events.
Other upcoming dates include:
Thursday, 24 July 2003, 11:00am to 01:00pm Eastern Time
Thursday, 31 July 2003, 11:00am to 01:00pm Eastern Time
Thursday, 07 August 2003, 11:00am to 01:00pm Eastern Time
Thursday, 14 August 2003, 11:00am to 01:00pm Eastern Time
Thursday, 21 August 2003, 11:00am to 01:00pm Eastern Time
Thursday, 28 August 2003, 11:00am to 01:00pm Eastern Time
View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-interop/event.php?event_id=2503
PLEASE NOTE: If the above link does not work for you, your email
application may be breaking the link into two pieces. You may be
able to
copy and paste the entire link address into the address field of your
web
browser.
Referenced Items
Date Name Type
---- ---- ----
17 Jul 2003 20030717 WSRP Interoperabil... Minutes
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]