Great timing. Drew asked me to work on it this week. The original implementation did #1; figured out that there were no changes from defaults and just used the precompiled version. That was removed with an intent to add a background thread to pre-compile as needed but that wasn't implemented yet. I might go back to that approach, though I might add some form of toggle instead maybe as a portlet preference (have to think about it more). I'm also thinking of implementing that background thread idea.
I agree with having the friendlier message. Drew had suggested I add that to the admin interface. I agree though it would be nice to have something for the non-admin also since there could always be a situation where the user may have to wait, though I think we could make it fairly rare. I'd love to have time to find out if there is a better way to compile the less. Jeff tells me it takes something like a second with his tool set (not launching the javascript compilation via java). The slowness of the java approach slows down every build which is already too slow. It would be nice if we could just ship the less to the browser but I'm not sure it is quite there yet as you noted. Overall the feature should be better after this week's changes. James Wennmacher - Unicon 480.558.2420 On 04/08/2014 03:05 PM, Andrew Petro wrote: > So, dynamic skin as implemented in Jasig/master respondr. > > After initportal: > > It feels kind of clunky to hang with a white screen with a gear > waiting for the skin to compile. > > (Screenshot: http://cl.ly/image/2W2P3S2U093M ). > > Are any of these feasible as improvement for dynamic skin? > > 1. uPortal build builds and places the skin that the portlet would > like to compile, so that the portlet doesn't have to compile anything > until and unless an administrator changes the skin and the portlet > actually detects that this static skin is suitable and chooses to use it. > > 2. Display a more usable message about what the user is waiting for. > > Rather than a white screen with a blue gear, perhaps a message > "Compiling skin, please wait...". Maybe even a different message > administrator-facing ("Compiling skin, please wait... Never modify > your skin live in production? Consider switching to a static > pre-compiled skin and avoiding this wait at runtime...") vs > end-user-facing ("The portal is loading. Thanks for your patience...") > > Perhaps some kind of progress indicator or at least pendingness > indicator, ala > > http://fortawesome.github.io/Font-Awesome/examples/#spinning ? > > 3. Make dynamic skin opt-in rather than opt-out so the typical adopter > enjoys a static compiled skin rather than waiting on the dynamic skin > compiler. > > My-UW is currently going this route locally in our respondr-using > predev environment. > > 4. Implement skin monkey-patching in some way that doesn't require > compiling anything server-side. My JavaScript and CSS acumen is poor, > I admit, but I imagine this is feasible given what I can do on sites > like this: > > a. Go here: http://lea.verou.me/css3patterns/#starry-night > b. replace the word "black" with "blue". > c. Have some thoughts about how long you didn't wait for anything to > recompile. > > This source code is implementing that: > https://github.com/LeaVerou/css3patterns > > Now, that isn't using LESS [0], and I get that our portal is vastly > more complicated than that website... but still. Waiting for Java to > compile and write some files server-side is starting to feel kind of > old-school in this all-JavaScript-all-the-time [1] modern world. > > Does anyone know how badly client-side LESS compilation would perform? > > http://lesscss.org/#client-side-usage > > and whether we could us that to move the last-bit-of-changes step to > client-side? If what is dynamic about skins is three colors, maybe > that can be monkey-patched into the skin client-side? > > > > Anyway. Would be good to improve this waiting-for-skin-compilation > experience a bit > > http://cl.ly/image/2W2P3S2U093M > > before dynamic skin respondr would become default for new adopters. > > Andrew > > > > [0]: Some discussion of using LESS in css3patterns: > https://github.com/LeaVerou/css3patterns/issues/6 > > [1]: Cf. Atwood's Law. > http://blog.codinghorror.com/the-principle-of-least-power/ > > > On 3/3/14, 12:07 PM, 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
