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