Susan Bramhall wrote:
I believe this is a question for Drew Wills.
Background: We are working on a small change to our portal that will
prevent a user "editing" a tab. The user will be able to add and move
portlets but will not be able to change column widths or the tab name.
Experimentation proves that a small change in the theme xsl can
accomplish these changes with the addition of an attribute to the tab of
the fragment owner. So we want to change the layout of the fragment
owner but...
We are having trouble with the export and import of the fragment. It
looks like there are entities known as a "fragment-layout"s. See
https://www.ja-sig.org/svn/uPortal/tags/rel-3-1-1-GA/uportal-impl/src/main/resources/properties/db/entities/fragment-layout/.
In the import-export portlet there is a type known as
*fragment-definition* which looks like it would correspond to the
fragment-layout entity. However, entering the layout-owner for the id
produces success but no file. If, on the other hand, I export a *layout
*and enter the fragment owner as a layout id then the export works fine.
Both .layout and .fragment-layout documents are created through the
Export Layout feature. The tool automatically determines whether a user
is a layout owner or not, and adds the appropriate suffix accordingly.
So if you run the following command...
>ant crn-export -Ddir=myDir -Dtype=all-layouts
you will get both .layout and .fragment-layout documents. Within the
myDir/ directory, these will be automatically organized into layout/ and
fragment-layout/ subdirectories.
And if you run this command...
>ant crn-export -Ddir=myDir -Dtype=layout -Dsysid=welcome-lo
the tool will recognize that the 'welcome-lo' user is a layout owner,
write the layout document to fragment-layout/, and add a
.fragment-layout suffix.
The Export Fragment-Definition operation generates a different sort of
document: .fragment-definition. This operation (and the corresponding
import & delete operations) are for DLM fragment definitions that are
managed in the database, instead of within dlm.xml.
The format for .fragment-definition documents is the same as for
dlm.xml. Here's an example:
<fragment-definition
xmlns:dlm="http://org.jasig.portal.layout.dlm.config";
script="classpath://org/jasig/portal/io/import-fragment-definition_v3-1.crn">
<dlm:fragment name="test" ownerID="test-lo" precedence="20">
<dlm:audience
evaluatorFactory="org.jasig.portal.layout.dlm.providers.PersonEvaluatorFactory">
<paren mode="OR">
<attribute name="eduPersonPrimaryAffiliation" mode="equals"
value="Staff"/>
<attribute name="eduPersonPrimaryAffiliation" mode="equals"
value="Student"/>
</paren>
</dlm:audience>
</dlm:fragment>
</fragment-definition>
The .fragment-definition documents only come into play for portals where
the option to store fragment definitions in the database has been
enabled. This option can be turned on by configuring the
'dlmConfigurationLoader' bean in layoutContext.xml as follows:
<bean id="dlmConfigurationLoader"
class="org.jasig.portal.layout.dlm.RDBMConfigurationLoader">
<property name="configurationFile"
value="classpath:/properties/dlm.xml" />
<property name="fragmentDao" ref="fragmentDefinitionDao" />
</bean>
You would also have to ensure that the 'fragmentDao' bean is properly
configured in the persistenceContex.xml file (there should be a
definition in there that's commented out).
Without this option, the Export Fragment-Definition operation will do
nothing, and attempting to import a .fragment-definition file will (I
suspect) give you an error.
That's not going to work either I believe because there is some special
processing in the import script that treats the layout specially when it
is a layout owner so I expect that just exporting and importing the
layout will not lead to correct results.
The special processing of .fragment-layout files on import is only this:
they are parsed & processed before "regular" .layout files, because
regular layouts may contain nodes that "refer" to nodes on fragment
layouts... and those layouts (the fragments) must be present in order to
resolve those references.
Otherwise, the processing is the same.
Can you tell us what the correct entities are to export and import so we
can change the attributes?
I would suggest exporting, editing, then re-importing the affected
layouts, but I fear it isn't just that simple.
The issue is that, although the XML documents don't represent
relationships between entities by using numeric identifiers generated at
runtime, the tables in the database do exactly that.
I'm not in a position to guarantee that a folder or channel in a
fragment layout will receive the same STRUCT_ID on re-import... so I'm
concerned about the possibility of breaking some existing user
customizations to DLM fragments.
But if you're in a position to export ALL your layouts, make your
changes, then re-import ALL your layouts, then this concern would not
apply. This approach should be safe, so long as you don't change the
number or order tabs/columns/channels that appear within fragment layouts.
drew wills
Thanks!
Susan
--
Susan Bramhall ([email protected] <mailto:[email protected]>)
Senior Developer, Technology & Planning Operations (T&P)
Yale University Information Technology Services (ITS)
25 Science Park, 150 Munson St, New Haven, CT 06520
Phone: 203 432 6697
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Andrew Wills
UNICON, Inc.
Office: (480) 558-2476
http://cernunnos.googlecode.com/
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
