-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strategy for building user content #27
Comments
For mobile UIs, one can expect that designers will want to preview their creation directly on target devices. For example, if an author creates an iPhone UI, then might pull out their iPhone and open up the URL for their Maqetta-created HTML file from their iPhone. Without doing a build, the UIs are going to appear very slowly on the mobile device because of high latencies with mobile networks. This will likely cause lots of negative perceptions about Maqetta and web-based mobile UIs because it will be challenging to educate Maqetta users and their team members that (hand-waving) it will be faster once the development team goes into production and uses the Dojo build system. Something that seems achievable is have Maqetta do a little build magic for preview-in-browser and ZIP download. In both cases, the server could run build scripts on the content and deliver a built version of dojo.js. Easier said than done, of course. |
I don't know what the timeline is, but there are projects underway to do exactly this, generating dynamic builds on the fly. Zazl, requirejs, and Lotus all have efforts in this area. The other option is to include some layer as part of the Dojo we deploy. In fact, I think mobile.js (and the "base") should already be built. |
see #1586 |
leaving this ticket open to investigate using the dojo web builder as a web service, once it supports 1.7 |
depends on #1750 |
-> M7/High |
Builder (build.dojotoolkit.org) when downloading workspace
multiple html files into a single request
Content in the user space is unoptimized. Would it make sense to use something like zazl's optimizer to dynamically combine HTTP requests, concatenate responses for JS and CSS, reduce whitespace and symbols, etc.? This seems like it may be a good fit for preview, perhaps even for users to deploy their apps. An AMD-based solution may be more generic and not require any Dojo linkage.
For the Visual Editor, the set of resources is generally not known, as individual widgets can be chosen at will. However, for more complex widgets like dijit.Editor which itself comprises a few dozen HTTP hits, combining those requests may be a significant gain.
The text was updated successfully, but these errors were encountered: