Skip to content
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

Closed
peller opened this issue May 2, 2011 · 6 comments
Closed

Strategy for building user content #27

peller opened this issue May 2, 2011 · 6 comments

Comments

@peller
Copy link
Member

peller commented May 2, 2011

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.

@JonFerraiolo
Copy link
Member

@jhpedemonte, @childsb

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.

@peller
Copy link
Member Author

peller commented Jul 13, 2011

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.

@peller
Copy link
Member Author

peller commented Feb 20, 2012

see #1586

@ghost ghost assigned peller Feb 20, 2012
@peller
Copy link
Member Author

peller commented Mar 9, 2012

leaving this ticket open to investigate using the dojo web builder as a web service, once it supports 1.7

@peller
Copy link
Member Author

peller commented Mar 9, 2012

depends on #1750

@peller
Copy link
Member Author

peller commented May 15, 2012

-> M7/High

peller added a commit that referenced this issue Jun 7, 2012
Builder (build.dojotoolkit.org) when downloading workspace
peller added a commit that referenced this issue Jun 7, 2012
peller added a commit that referenced this issue Jun 9, 2012
@peller peller closed this as completed Jul 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants