> >> 2) We probably need to come up with a strategy in which widgets can >> be > configured/re-configured easily at runtime, so we don't need to > centralize all of their configurations. > > I think this can be done already, using the WidgetSettings property > in config.js
That's correct, and is a very important tool in the widget toolbox. It will still be necessary to allow deployers to change this default configuration, preferably without having to do a new production build. Hope that helps, Nicolaas > -----Original Message----- > From: [email protected] > [mailto:[email protected] > ] On Behalf Of Nicolaas Matthijs > Sent: Friday, 27 April 2012 1:17 AM > To: Duffy Gillman > Cc: [email protected] Production; OAE Development > Subject: Re: [oae-production] [oae-dev] Dynamic Configuration - Code > Contribution > > Hi Duffy, > > Yes, there is interest in this! > > Decoupling configuration from code has been on our wish-list for a > long time, so this sounds like really valuable work, very much in line > with what we were planning to do. Having to do a rebuild is not a > great deployment solution for production deployment, and makes it > harder/unfeasible to just pass jars around and then configure on top > of that. De-coupling config_custom.js from the production build could > have a similar effect, but asking operations to maintain their > configurations in javascript/json files might not be ideal. I would > definitely be interested in seeing your solution in action, perhaps a > screencast could be really useful. > > In terms of the solution you describe, creating a rest-end point, as > well as making it possible to load a default configuration from 3akai- > ux make a lot of sense. A couple of quick initial questions/comments: > > 1) I'm assuming configuration changes can be made at runtime by doing > a POST to this service? Because these don't happen regularly, it could > be sufficient to give this URL a short caching lifetime (i.e. roughly > 1 session) > 2) We probably need to come up with a strategy in which widgets can be > configured/re-configured easily at runtime, so we don't need to > centralize all of their configurations. We'd also have to make sure > that it's easy for widget developers (students, lecturers, etc.) to be > able to add config options to their widgets. This is currently done in > the widget config file (default configuration), and is then passed on > to the widget when loaded. We should probably make it possible to > adjust these configs at run-time as well. Have you given this any > thought? > 3) The fact that it's currently only possible to replace top level > properties is slightly annoying, but I think that should do initially > and can be solved further down the line. > > Hope that helps and thanks for sharing this. We should really try to > get this incorporated, as it has the potential of making deployment a > lot more straightforward. > > I'm CC'ing the oae-production list as they might have some useful > input this as well ... > > Kind regards, > Nicolaas > > > > On 26 Apr 2012, at 00:41, Duffy Gillman wrote: > >> Please forgive the long post. I've been working on new functionality >> and realize it needs some daylight. I hope this format is digestible >> and useful and that you will feel at liberty to ask questions to >> help clarify anything that is made murky below... >> >> I'm looking to open a discussion about making configuration of 3akai- >> ux more dynamic. I have done some work in this area and would like >> to render it useful to the community.. That will require review and >> discussion, and surely some revision to the work I've done. So let >> me start with an introduction to the problems I am hoping I have >> solved and a query to this list as to who needs to be involved in a >> review. >> >> The goal of my work is to move away from per-customization revisions >> to the 3akai-ux code base. If something truly is "configuration" it >> would be nice to be able to apply it without requiring a rebuild of >> 3akai-ux, without potentially rebuilding nakamura as well [1], and >> without requiring a redeployment of new artifacts. There are good >> reasons that configuration changes require a rebuild presently [2], >> but as a long term strategy it would be best to separate >> configuration from the build. Runtime configuration has additionally >> been an expressed goal of many folks on this list. My work starts >> down the path toward all of these goals. >> >> My work is comprised of a new nakamura bundle called dynamicconfig, >> and alterations to the core Sakai API Javascript libraries in 3akai- >> ux to take advantage of dynamicconfig. These modification are >> presently based upon the 1.1 release but are available for review >> publicly [3, 4]. I am willing to do the work to port this forward >> and to issue appropriate PRs if there is interest among you folks. >> The work presently functions and replaces config.js. I do have a >> short list of known issues/directions for improvement that I include >> in closing. >> >> Please share your thoughts and questions. I am eager for feedback >> and hope this can benefit the project. >> >> How it Works >> ------------------- >> >> Dynamicconfig creates a REST service that responds to requests at / >> system/dynamic-config/config.json. It produces JSON output that is >> digested by the UI code and is stitched into the Sakai API library. >> In this way no widget code needs to change. The Javascript object >> graph ends up looking precisely as it had before my dynamicconfig >> work. >> >> The backend relies on a DynamicConfigurationService API that can be >> implemented against whatever data store is suitable. I have made a >> simple reference implementation that produces the in the following >> manner: >> >> 1) A master configuration JSON file (path is configurable) is >> read >> from the file system and is used as the basis for configuration. >> 2) If the master configuration file is missing /dev/ >> configuration/ >> config.json is pulled from JCR and used. This allows a default >> configuration to live in the 3akai-ux project. >> 3) An overrides directory is processed. Any .json file in that >> directory is merged into the configuration. >> >> The reference implementation is the simplest implementation I could >> fathom that would meet the stated goals. There is plenty of room for >> improvement. Ideally configuration would live in sparse of JCR. But >> for now this is a usable implementation that I hope moves the bar >> forward. >> >> Caching is still handled on the browser. Configuration will not >> change frequently so it is desirable to let the browser use a cached >> copy until a change occurs. To accomplish this the REST service >> accepts GET requests for the configuration of the form: >> >> /system/dynamic-config/config.{hash value}.json >> >> No matter what the "hash value" is the result is the configuration >> JSON object. But the "hash value" is reported by the dynamicconfig >> service in response to a GET call, and it is guaranteed to stay >> constant until the configuration changes. In this way the >> configuration request can use the most recently reported "hash >> value" and can be guaranteed fresh configuration if anything has >> changed. The drawback is an additional GET with each page load. >> >> Additional methods have been stubbed out in the dynamicconfig >> service to accept POST calls. These presumably would cause changes >> to the configuration subject to authorization checks. At present >> these methods preform no work but are available for override should >> cycles be free to move beyond the reference implementation to a >> richer, runtime dynamic, configuration service. >> >> Limitations/Known Issues >> ----------------------------------- >> >> - [BUG] browser caching currently has zero net effect due to a >> failure to respond to HEAD requests appropriately. Instead of >> responding with header information HEAD requests presently return >> *the entire configuration*. The browser still uses the cached copy, >> but the data transmitted is equivalent to a full refresh of the >> configuration. This should be a simple fix and would be expected >> before issuing a PR to the community. >> >> - the reference implementation preforms a naive JSON merge which >> replaces only top-level keys. This is not a bug, its just annoying. >> This means override files may only presently replace top-level keys >> in the configuration JSON, and must replace them in their entirety. >> A better implementation would accept sparse paths to JSON keys deep >> in a JSON object and would only override those keys leaving all >> sibling data intact. This may be better undertaken as an improvement >> when a Sparse or JCR implementation is pursued. >> >> - permitting GET/POST to individual configuration paths deep in the >> configuration structure seems like an obvious extension to this work >> which might permit finer grained loading and/or access control for >> bits of configuration >> >> - review of the dynamicconfig work is needed to bring it into line >> with community style and testing guidelines >> >> >> * * * >> >> Thanks! I hope this is seen as a useful direction and I am pleased >> for any attention folks can give it. >> >> -Duffy >> >> >> [1] Technically one could get away without rebuilding nakamura, >> though if one is managing revisions one might expect to rebuild >> nakamura to ingest a new version of 3akai-ux. >> >> [2] Configuration currently requires a rebuild of 3akai-ux because >> it is currently embodied in Javascript files which must be present >> during the optimization and hashing phases of a release build. >> >> [3] >> https://github.com/rSmart/nakamura/commit/5a8252eb1521da18dba87dd14db314eb6e2208d5 >> >> [4] >> https://github.com/rSmart/3akai-ux/commit/6ffbbbb533a72f6b6bf325692cd338f308a20906 >> >> ------------------------------ >> Duffy Gillman >> Sr. Software Engineer >> The rSmart Group, Inc. >> >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > _______________________________________________ > oae-production mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-production > Charles Sturt University > > | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | > MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA | > > LEGAL NOTICE > This email (and any attachment) is confidential and is intended for > the use of the addressee(s) only. If you are not the intended > recipient of this email, you must not copy, distribute, take any > action in reliance on it or disclose it to anyone. Any > confidentiality is not waived or lost by reason of mistaken > delivery. Email should be checked for viruses and defects before > opening. Charles Sturt University (CSU) does not accept liability > for viruses or any consequence which arise as a result of this email > transmission. Email communications with CSU may be subject to > automated email filtering, which could result in the delay or > deletion of a legitimate email before it is read at CSU. The views > expressed in this email are not necessarily those of CSU. > > Charles Sturt University in Australia http://www.csu.edu.au The > Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 ABN: 83 > 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), > 02960B (ACT) > > Charles Sturt University in Ontario http://www.charlessturt.ca 860 > Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: > www.peqab.ca > > Consider the environment before printing this email. _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
