Andrew, One part of the work James & I discussed for this week is this...
I think there should be a toggle (checkbox) in the CONFIG screen of the dynamic skin portlet to enable/disable the dynamic behavior in the first place. We can default it to 'disabled' -- which would clear up the white screen & wait (after a deploy) entirely, since it would be using the non-dynamic less that was compiled atbuild time.
Those who want the dynamic behavior can wait a few secs while their color choices compile.
We also talked about making the compilation "ajaxy" -- so that it will happen as the result of an actionUrl submitted by JS, with a spinner on the screen. Only when it completes and returns will we refresh the page.
These changes should hit soonish. drew On 04/08/2014 04:10 PM, James Wennmacher wrote:
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 [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
