Hey folks,
I'm at Yale this week working with Jen Bourey on some enhancements to
Import/Export.
Jen has make some terrific progress on UP-1899:
http://www.ja-sig.org/issues/browse/UP-1899
I'm working on UP-1917 (support for portlet entity preferences):
http://www.ja-sig.org/issues/browse/UP-1917
I have a script that exports user-level portlet preferences to the
following format:
*****
<preferences
script="classpath://org/jasig/portal/io/import-preferences_v2-6.crn"
username="admin">
<entry entity="admin:/layout/root/tab[1]/column/channel[1]"
name="KEY">hoopajube</entry>
<entry entity="ent-lo:/layout/root/tab/column[2]/channel[1]"
name="KEY">monkey</entry>
</preferences>
*****
The question came up whether we'd be better off exporting this XML to a
document on its own (e.g. admin.preferences) or whether it makes more
sense to nest this XML in the existing layout documents (e.g. within
admin.layout).
It seems the latter solution (part of the layout) *would be* more
attractive if it weren't for one thing: portlet preferences can depend
on fragment layouts, so we would have to guarantee that all fragment
owner layouts were imported before "regular" layouts.
So instead of creating the .preferences file type containing preferences
info, we would have to create the .fragment-layout file type (or
something like) to distinguish layouts that describe DLM fragments. In
this case, we would import the .fragment-layout files before the .layout
files.
We were discussing some of these considerations on IRC earlier today and
we didn't feel that there was a clear answer for this issue. I
suggested I'd post to the list for community input, so please share your
thoughts.
I've been chewing on this question now and again throughout the day, and
at this point I think I'm more in favor of the separate document
approach: put preferences into a {username}.preferences file rather than
the layout file.
Here's how I see it:
- (1) If fragment owners' layouts go into .fragment-layout documents,
I'll have to do some magic on export to figure out which layouts belong
to fragment owners; this new magic isn't different in character from
the things that are already happening, but taking on these extra
responsibilities will...
- put more knowledge of the inner workings of DLM into the scripts,
making them more likely to need maintenance as DLM and uPortal evolve
- make the scripts larger and harder to understand
- (2) It's likely that a very small number of users will have portlet
entity preferences in many/most uPortal deployments (at least for now).
With the separate document approach, I'll only be creating XML for the
set of users who actually have preferences. In the other model, I'd
have to perform at least one DB operation per user to determine if there
are preferences, so the time it takes to export layouts would increase a
bit.
- (3) Although portlet preferences seem to belong logically to a
user's layout, this notion is only partially accurate. As discussed
above, some user-level portlet preferences refer to portlets that are
actually contained in fragment layouts -- meaning that the portlets they
target won't be in the layout document at all.
- (4) Existing layout documents for fragment owners -- those that
have been exported already -- don't have the .fragment-layout extension.
In other words, individual portal admins would have to be aware of
this change and hand-edit their data files to work with the new system.
I'm not sure any of these points is a slam dunk, but from my perspective
there seems to be a bit less pain associated with the .preferences approach.
cheers everyone,
drew wills
--
Andrew Wills
UNICON, Inc.
Office: (480) 558-2476
http://code.google.com/p/cernunnos/
--
Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The
Community Source Way!"
April 27th - 30th, 2008 in St. Paul, Minnesota USA
Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and
more!
Information/Registration at:
http://www.ja-sig.org/conferences/08spring/index.html
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
