Added https://issues.jasig.org/browse/UP-3990 for default vs. quickstart data population.
James Wennmacher - Unicon 480.558.2420 On 03/03/2014 11:07 AM, Andrew Petro wrote: > James, Drew, others, > > Thanks for the conference call just now. Here's some of what's in my > brain coming out of it: > > * Importance of the new dynamic skin features being optional, > traditional crafted skinning working, it being apparent and > straightforward how to drop the skin manager portlet from an > implementation and yet have skinning work properly. > > * Relatedly, opportunity in getting more careful about what goes in > "default" vs what goes in "quickstart" namespaced entity files, with a > goal of it being possible to init a portal with just the "required" > and "default" entities and thereby get that mythical "empty portal" on > which to build. "quickstart" as the thing you want to demo, want to > jump into to understand the potential, but zapping to zero the > contents of the quickstart directory as a plausible way to go about > building a for real uPortal implementation and, for upgrades, an > ability to focus on what changed in required and default and ignore > what's in quickstart except to the extent that you want the features > or have already adopted those features and need to understand how > they've then changed. > > * Opportunities in multi-tenant more generally, and value for > single-tenant adopters of some of the multi-tenant features in that > that single tenant might still be a tenant worth managing. Opportunity > in aligning ideas like this: > https://wiki.jasig.org/display/~levett/System+Feature+Configuration > with the scripted/templated tenant generation that Drew Wills et al. > have been exploring. > > * Tactical followup on the code details of the pending dynamic skins > pull request, with gratitude to Misagh Moayyed and others for review. > > Others on the call, or even not on the call, please add your thoughts > too, and then some of this needs tracking to completion... > > Andrew > > > > On 02/28/2014 02:03 PM, James Wennmacher wrote: >> I've really appreciated all the comments on the pull request and >> additional ideas. I'm excited to see the energy this feature >> enhancement is generating. >> >> I wrote up a brief overview of the big picture that drove the current >> design approach at >> https://wiki.jasig.org/display/UPC/Skin+Manager+and+Dynamic+Skins+for+Respondr. >> >> The intent is that this feature enhancement provide a base of a >> small, but helpful push toward a more dynamic skin management feature >> for both non-tenant and tenant scenarios, recognizing that there is >> much room for enhancement to the current feature needs. >> >> Andrew P I like the dream you outlined below. It is more along the >> lines of the dynamic capabilities of Drupal and other dynamic >> management systems. In writing up the big picture above I am >> rethinking the idea of storing the skin files on the file system vs. >> storing them in the database, or perhaps a hybrid approach might be >> better of compiling them once and storing them in the database, and >> hydrating them onto the file system as needed similar to the way >> attachments works. >> James Wennmacher - Unicon >> 480.558.2420 >> On 02/28/2014 10:00 AM, Andrew Petro wrote: >>> I had a dream about making uPortal skins more dynamic last night >>> [1], prompted by this feature branch and pull request. >>> >>> https://github.com/jameswennmacher/uPortal/tree/UP-3940 >>> >>> https://github.com/Jasig/uPortal/pull/239 >>> >>> >>> I'm eager to have a conversation about the big picture. >>> >>> So. Here's what I hope is the best next nudge I can give this: >>> >>> # A couple of motivating user stories: [2] >>> >>> ## 0. Many more skins >>> >>> As a portal service owner I would like to be able to offer and >>> manage hundreds of (slightly different) skins rather than just one >>> or a few. >>> >>> The bigger picture context here is supporting massively more >>> multi-tenant uPortal. That entails, among I imagine many other >>> considerations, supporting potentially hundreds of skins rather than >>> the one or a handful that are currently typical in uPortal adoptions. >>> >>> ## 1. Editing a skin live via admin UI in portal >>> >>> As a user with privileges over some skins, I would like to be able >>> to edit those skins live in the portal via a friendly UI rather than >>> having to edit raw source code (text editors?! Ew!) and run it >>> through a build process (Ant that invokes Maven that invokes a Ruby >>> gem? Ew!). I would like immediate visual feedback about what my >>> changed skin feels like. >>> >>> ## 2. Skin edited in live portal takes effect immediately >>> >>> As a portal service owner I would like the live edits to skins to >>> take effect immediately-ish. That doesn't necessarily mean having >>> to tickle active end-user uPortal sessions with changed skins, but >>> it does mean I don't want to have to restart the servlet container >>> to pick up a skin tweak. >>> >>> # Some background: >>> >>> uPortal has Skins. Users can pick among them in the Customize >>> Drawer in Universality and I imagine they'll be able to do so in >>> Respondr once the Customize Drawer shapes up. [3] There's currently >>> no concept, that I know of offhand, of mapping which skins ought to >>> be available to which users. A user's preference for which skin is >>> modeled as a stylesheet parameter ("Skin name") [4] and they can >>> select among all the skins registered in the skinList.xml manifest >>> applicable to the theme they are using. >>> >>> Skins live in /webapp/media/skins in the source tree, namespaced by >>> the theme they skin. There's a skinList.xml for each theme that >>> registers which skins apply to that theme with a wee bit of >>> metadata. Skin directories themselves can contain JavaScript, CSS, >>> things that get compiled into CSS namely SCSS and LESS, images used >>> in the skin, and a preview image of the skin useful for the end user >>> UI for selecting among skins. >>> >>> At build time the skin source is transformed (LESS is compiled to >>> CSS) and the resulting browser-ready user-facing files are included >>> in the resulting uPortal.war in the /media/skins/ directory of the >>> webapp, served directly to the browser by Tomcat, >>> >>> # Alternative implementation sketch >>> >>> I think these user stories amount to "I want uPortal skins to be >>> dynamic data rather than static, compiled artifacts. I want them to >>> be more like entities, more like layout content, amenable to live >>> editing because they're part of the uPortal object model and are >>> persisted and communicated amongst nodes via the database, and less >>> like Java classes that are compiled from source, deployed, shared >>> among uPortal nodes through the happenstance of carefully deploying >>> the same compiled static artifacts to all the nodes, and expect that >>> the Tomcat server will restart to make changes take effect." >>> >>> Which seems a fine enough set of wants. Dynamic, richer Java model, >>> and administration via portlets can enable some wonderful things. >>> >>> So I suggest inventing a richer model for skins in the Java layer, >>> modeling what is (Skins with name and description, preview image, >>> with LESS source, and JavaScript and image sources, and compiled >>> results from some of that) and eventually what could be (perhaps >>> some skins could be built from still simpler primitives such as the >>> select-three-colors-to-tweak-the-skin demonstrated in the pull >>> request above). >>> >>> Almost certainly invent a fronting SkinService too to incorporate a >>> more sophisticated model of how to figure out what skin goes with >>> what user in what context, who has permissions to do what to what >>> skins, etc. Skin selection stops being an incidental stylesheet >>> parameter and starts being something richer and separate. Maybe >>> skins end up being permissible entities. There's a fair amount of >>> routine richness to bake into the API in making this more >>> dynamic-and-serviced-in-the-portal-UI and less >>> implied-process-through-edit-at-source-code-time. >>> >>> The existing functionality would be a BoringFilesystemBackedSkinDao >>> implementation. Its behavior would be to read the compiled skin >>> from the filesystem. It would politely decline to support write >>> operations, perhaps, because folks interested in write operations would >>> >>> implement a new JpaSkinDao implementation that, rather than getting >>> the skin from the file system, would get the skin from the uPortal >>> database, share it among nodes via the database. >>> >>> Put not just metadata about the skins but the actual skin content, >>> the actual CSS content (and, eventually, images?) into the uPortal >>> database. >>> >>> Build out a skin administration portlet for administering, editing >>> these. I think it would always ought to support getting down to >>> brass tacks and uploading externally developed skins, I imagine, but >>> of course this also creates the opportunity to build out templating >>> for easily creating variations on existing skins setting a few >>> colors, swapping images for logos, etc. Skin creation / edit >>> wizards and workflows. >>> >>> Invent a SkinDeliveryController that serves up skin content to >>> browsers, and have browsers get the CSS, JavaScript, even images >>> from that controller rather than from paths that Tomcat serves >>> directly from the media directory. It would be backed by the >>> SkinService and somewhere in here there would be aggressive caching, >>> of course. >>> >>> All of which is a fair amount of work, but we'd come out the other >>> end with something pretty spiffy in modeling skins as data rather >>> than as compiled artifacts on the filesystem, and it feels a cleaner >>> approach than adding functionality that triggers writes down to the >>> filesystem to update skins in ways not reflected in the source code >>> from which they were compiled. >>> >>> I mean, we have this problem now, live action in the portal changing >>> things that are in source control, but we have it scoped to entity >>> files, and so I expect that importing entity files is importing into >>> the database and live edits to entities need to be reflected in >>> those source entity files if I want them retained on a fresh >>> import. I don't expect the portal to be generating skins down to >>> the filesystem on the fly? >>> >>> Andrew >>> >>> >>> [1]: To be honest, I didn't actually have a dream. I am an >>> intermittent insomniac and it was more a matter of laying awake >>> staring at the ceiling thinking about making uPortal skins more >>> dynamic. But summarizing this as a dream is oh so much more romantic. >>> >>> [2]: Just that, a couple of stories that seem central to what's >>> being pursued here, *not* a comprehensive set of requirements. Much >>> imagination (dreaming?) required. >>> >>> [3]: Looks like continued progress in making the customize drawer >>> shape up, incidentally: https://github.com/Jasig/uPortal/pull/245 . >>> https://github.com/Jasig/uPortal/pull/242 . >>> >>> [4]: User preference of which skin to use is stored in >>> UP_SS_USER_PREF_PARAM. It's declared as a parameter on the theme >>> stylesheet descriptor. >>> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/data/required_entities/stylesheet-descriptor/Respondr.stylesheet-descriptor.xml >>> >>> >>> >> >> -- >> >> You are currently subscribed [email protected] >> as:[email protected] >> To unsubscribe, change settings or access archives, >> seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- > > 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 -- 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
