I want to bring this conversation public that Ed, Scott, and I have been having about assets for the upcoming simple widget, which will allow users to build a Cesium app with one line of code. I am, of course, really excited about this since this will significantly reduce the barrier to entry.
Ed said:
Basically, if you have an empty HTML page that includes “Build/Cesium.js” as the only external JavaScript, then an embedded script tag should be able to instantiate a widget with one line of code (such as on the simple-widget branch). This means the Cesium.js file needs to know the location of what is now “Source/Assets” (and Source/Widget/Images, which should be included in Assets). But, the point of Build/Cesium.js is to not need the Source/* tree at all.
Scott has proposed adding a build step to copy “Source/Assets” to “Build/Assets”. We could also then have either a global (CESIUM_BASE_URL) or a script-tag attribute (data-cesium-base) that lets Cesium.js find “Build/Assets” and the worker scripts.
With this addition, I think the simple-widget branch could be brought up to date and readied for pull-requesting.
With Scott’s proposal, can we provide a default for the Cesium url attribute (I’d call it “assets” not “cesium-base”) that assumes the most common case, perhaps that assets is a directory at the same level as Cesium.js? However, Cesium knowing a directory structure like assets doesn’t feel right to me. Are more fine-grained urls, again with good defaults, better? Maybe that is worse - seems messy.
Any other, perhaps completely different, ideas?
Regards,
Patrick
I’ll add that the main feature of the branch, “Viewer.js”, is intended to be an almost exact copy of Dojo/CesiumViewerWidget.js, minus the Dojo (and minus the UI, for now, but I’m planning to add the playback & timeline widgets once playback is in master, with a developer option to disable or enable them).
The smallest app in simple-widget is a new demo called “Small Demo” on the main menu now. The largest part of it is the part that tries to locate textures and widget images. That’s the part I want to simplify even further, for example with a data-attribute on the script tag that pulls in Cesium.js, so the whole app can just be the construction of the widget with no options.
–Ed.
To keep everyone in the loop, Ed and I discussed the needs here and came up with this more concrete plan for restructuring the output directory for clarity:
-
The conceptual “Cesium build output” has grown from what it has been since the project was started (a single standalone file “Cesium.js”) into a set of JS files (Cesium plus worker scripts), and now into a full-fledged directory structure (Cesium, worker scripts, default textures, widget CSS and icons). As such, we’ll move the “Cesium build output” into a Build/Cesium folder to represent the entire self-contained set of files that need to be deployed to use Cesium in the simplest applications. This will separate it from other build outputs such as documentation, and built example applications.
-
For ease of development, we want to keep the widget css/images close to the widget code that uses them, since they must work together. There’s nothing special about the Assets folder, rather, build artifacts can appear wherever in the source tree makes the most sense.
-
The Web Worker scripts (bootstrapper plus the layers containing the actual worker code) are conceptually build artifacts just like the assets and widget styling files, so for consistency they can move down a level in the output into a Workers folder, making the relative path to build artifacts the same as the path in the source.
I’ll be working on making these changes in Ed’s existing simple-widget branch.
Scott,
This is all good with me. I look forward to the day when web workers don’t have to be separate files - if that day ever comes.
Patrick