Re: [uportal-dev] Some updates on Import/Export and a question

[Eric Dalquist]

I'm with Andrew on modeling the fragment owner layouts differently, even if they are the same giving them different file extensions would be helpful. Then including the preferences fragments in the user's layout would be doable and I think make much more sense if one had to edit these files by hand.

-Eric

Andrew Petro wrote:

Drew,

> there seems to be a bit less pain associated
> with the .preferences approach.

I'm okay with either approach.





Andrew


Drew Wills wrote:

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.

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

*****

</preferences>
*****











Here's how I see it:


    - make the scripts larger and harder to understand









cheers everyone,

drew wills

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> 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. - (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 - (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.

smime.p7s
Description: S/MIME Cryptographic Signature