Drew,
> there seems to be a bit less pain associated
> with the .preferences approach.
I'm okay with either approach.
I think it may be more attractive to model fragment owner layout
documents separately from end user layout documents, in that they are
semantically different -- fragment owner layouts have more metadata
about what the end consumer is permitted to do, metadata that makes no
sense when outside the context of a fragment owner. It seems a sensible
requirement that fragment owner layouts be loaded before the layouts of
users who may have expressed preferences over the layouts of those
fragment owners. The ability to readily identify which files represent
fragment owner layouts in the exported artifacts seems a good thing.
Am am grateful to Yale in affording people to focus on these issues.
While I hope my drive-by comments are helpful, what's really going to
nail import/export functionality in uPortal is your and others' ability
to focus on this and get it done.
Andrew
Drew Wills wrote:
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
--
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
