[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] New Import Export document
One case to keep in mind regarding
import/export and ccp hierarchies is the following:
The correct outcome is that Portlet B1 is
replaced with the newly imported portlet without losing the end user
customizations on Portlet B2 and B3. In other words, the relationships
must be maintained. Given our discussion this morning, it’s
probably too early to discuss the detail of this scenario at this point, but I
wanted to bring it up to keep it in mind. Scott From: Tamari,
Yossi [mailto:yossi.tamari@sap.com] Hi Mike, “Should we put the
burden on the producer to encode Portlet type information in the export data so
an offeredPortlet doesn't have to be identified? An issue to consider is
how a Producer can match to a current offeredPortlet if order/etc has
changed.” – I think we should. The producer might not need to know
the original POP, but just the name of a Java class, plus all the other
information in the CCP. This burden is much heavier for the consumer. This also
relates to another one of your questions: “Do we need to
discuss impact on import/export interface if we ever support producer managed
hierachies? I.e. if producer manages/knows about relationship between
portlets then do we need more semantic information passed from the consumer to
the producer on import to re-establish those relationships? I.e. I
import the a new site customization but not the user customizations and need
the producer to rewire the existing user to this new site because it knows and
manaegs the relationships. Or in a simpler vain what data needs to be
carried when the relationship is fully represented in the export -- i.e. both
parent and children aer being imported?” – I don’t think that
needs to be carried in the protocol. Since the producer is the one that manages
the hierarchy, it can export any hierarchy related info it needs along with the
other exportData. I do think the protocol
should differentiate between two use cases: 1. Export for
“immediate” import, as in your deploying case. In this case it
makes a lot of sense for the consumer to clone the portlet on export. 2. Export for
“archiving”. In this case the consumer may for example transfer the
exported CCP to multiple other consumers, so a clone needs to be created on
import. (This is useful when creating a content package containing ready-built
pages with related portlets, some of which may be WSRP based).
Yossi. From: Michael
Freedman [mailto:Michael.Freedman@oracle.com] I have rewritten the original strawman to define
specific import/export methods. It has been uploaded
to the Interfaces documents. If you want to refer to the old version
click on "Manage" to the far right of the document entry. This
takes you to a page where you can see the previous revision(s). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]