Depending on how the faults are mapped to
exception classes it may allow an implementation to handle any registration
faults (using a common super type, for example to abort the end user rendering
of the faulty portlet) and then special case particular extensions of the base registration
fault behavior (e.g. request an admin to submit a modifyRegistration request if
that is the concrete fault). But if no one else sees value in expressing this
communality then I will drop my suggestion.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 13 December 2004 21:46
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp]
modifyRegistrationRequired fault
Since this is just a schema definition of what flows on
the wire, I don't see an advantage to introducing an intermediate definition as
it will never appear on the wire and does not factor out any structural
definitions.
Rich
|
Andre Kramer <andre.kramer@eu.citrix.com>
12/13/2004 09:27 AM
|
|
To
|
wsrp@lists.oasis-open.org
|
|
cc
|
|
|
Subject
|
RE: [wsrp] modifyRegistrationRequired fault
|
|
The case I was attempting to make is that the
modify registration fault is an "extension" of a registration fault
that can be recovered from. I understand that one can view
InvalidRegistrationFault more as commandment to never again use the
registration handle rather than a signal that a registration is, say,
temporarily unavailable (ctf InvalidHandle?). In this view both
ModifyRegistration and InvalidRegistrationFault could extend a base
RegistationFault.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 13 December 2004 14:10
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] modifyRegistrationRequired fault
I do not think the ModifyRegistrationRequired fault should extend
InvalidRegistration fault as their semantics are quire different (repair this
registration vs destroy this registration's artifacts). As to an expanded
description ... sounds like a good idea, I kept the initial pass concise as
this is in keeping with the other definitions in the table, but am open to
expansion of this or other fault descriptions. We should be careful about what
is prescribed behavior, though, as not all Consumers will be portals with
administrators ...
Rich
|
Andre Kramer
<andre.kramer@eu.citrix.com>
12/10/2004 04:55 AM
|
|
To
|
wsrp@lists.oasis-open.org
|
|
cc
|
|
|
Subject
|
[wsrp] modifyRegistrationRequired fault
|
|
The draft spec does not seem to give much guidance on how to handle the new
proposed
fault?
I
would expect consumer processing for an end-user to abort
on the
fault (affected portlets are not
rendered) and an admin to be notified to go and attempt a
modifyRegistration operation interaction with the faulting producer (correct me
if I'm wrong but Portal users may not even
see
the new modified registration until they log in
again). This leads me to two questions:
Should
example usage of the new fault be better described?
Should
the fault type be declared to extend the 1.0 InvalidRegistrationFault
(or a
common base type be inserted)?
E.g.
<complexType name="ModifyRegistrationRequiredFault">
<complexContent>
<extension base="types:InvalidRegistrationFault">
<sequence/>
</extension>
</complexContent>
</complexType>
<element name="ModifyRegistrationRequired"
type="types:ModifyRegistrationRequiredFault"/>
Regards,
Andre