Dojo build and simplified CommonJS wrapping

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Dojo build and simplified CommonJS wrapping

Scott Hunter
Does anyone know if there is any plan to support the alternate (much more readable) style of defining modules using inline require calls with the Dojo builder in the future?


This syntax works with the Dojo loader, but does not work with the build system, meaning that it's quite easy to build an app that works fine in development but is impossible to make a working build for without rewriting all the define statements (I've been burned by this).  I traced it down to an if (0) {} block and a TODO in depsScan that disables the scan for dependencies.

I tried to search for related bugs, but came up empty.  Anyone have more up-to-date info?

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

kitsonk
We should support the alternative syntaxes in the builder.  I am surprised we don't, but I see the code you are talking about and it looks like we haven't implemented it.

I would file a ticket at http://bugs.dojotoolkit.org/ with a working example. (I took a quick look and don't see anything related to it)

On 8 May 2012 10:45, Scott Hunter <[hidden email]> wrote:
Does anyone know if there is any plan to support the alternate (much more readable) style of defining modules using inline require calls with the Dojo builder in the future?


This syntax works with the Dojo loader, but does not work with the build system, meaning that it's quite easy to build an app that works fine in development but is impossible to make a working build for without rewriting all the define statements (I've been burned by this).  I traced it down to an if (0) {} block and a TODO in depsScan that disables the scan for dependencies.

I tried to search for related bugs, but came up empty.  Anyone have more up-to-date info?

________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest



________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

PaulChristopher
I didn't know, that there is - at least in my eyes - a much nicer, more readable way to require modules: "Simplified CommonJS wrapping". Thanks for this hint!

With the new AMD loader, I never liked the way to define/require modules because of the high risk of mismatching dependencies and their named function arguments. Moreover readablilty is poor and long dependency list look quite awkward and strange.

Aside the above mentioned build issue: Are there any other reason not to use this approach with Dojo?

Why is the "simplified CommonJS wrapping" approach not the default approach of Dojo?

Just look at _WidgetBase.js and its huge dependencies list. Most of my page-level application controllers have such huge depenency list, too. And at moment I think - without knowing too much about AMD standard approach vs. "simplified CommenJS wrapping" - code readability could significantly be improved by using the simplified CommonJS wrapping approach. Or am I wrong?
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

Kenneth G. Franqueiro
The "simplified CommonJS wrapping" approach is actually less
natural/efficient in terms of the loader implementation, because it
needs to pre-scan the content of your function for dependencies.  When
the dependency array is provided up-front, it has a much simpler job to do.

Also, from the AMD wiki:

In some situations module loaders may choose not to scan for
dependencies due to code size limitations or lack of toString support on
functions (Opera Mobile is known to lack toString support for functions).

--Ken

On 5/11/2012 7:29 AM, PaulChristopher wrote:

> I didn't know, that there is - at least in my eyes - a much nicer, more
> readable way to require modules: "Simplified CommonJS wrapping". Thanks for
> this hint!
>
> With the new AMD loader, I never liked the way to define/require modules
> because of the high risk of mismatching dependencies and their named
> function arguments. Moreover readablilty is poor and long dependency list
> look quite awkward and strange.
>
> Aside the above mentioned build issue: Are there any other reason not to use
> this approach with Dojo?
>
> Why is the "simplified CommonJS wrapping" approach not the default approach
> of Dojo?
>
> Just look at _WidgetBase.js and its huge dependencies list. Most of my
> page-level application controllers have such huge depenency list, too. And
> at moment I think - without knowing too much about AMD standard approach vs.
> "simplified CommenJS wrapping" - code readability could significantly be
> improved by using the simplified CommonJS wrapping approach. Or am I wrong?
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dojo-build-and-simplified-CommonJS-wrapping-tp3972049p3979663.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

Scott Hunter
If the builder tool was able to understand the convenience syntax, then you could have the best of both: the builder could do the work of pre-scanning functions at build time, when efficiency is not as important, and fill out the dependency arrays so the loader can do less work when loading built content.  This is precisely what the RequireJS optimizer does.

On Fri, May 11, 2012 at 8:21 AM, Kenneth G. Franqueiro <[hidden email]> wrote:
The "simplified CommonJS wrapping" approach is actually less
natural/efficient in terms of the loader implementation, because it
needs to pre-scan the content of your function for dependencies.  When
the dependency array is provided up-front, it has a much simpler job to do.

Also, from the AMD wiki:

In some situations module loaders may choose not to scan for
dependencies due to code size limitations or lack of toString support on
functions (Opera Mobile is known to lack toString support for functions).

--Ken

On 5/11/2012 7:29 AM, PaulChristopher wrote:
> I didn't know, that there is - at least in my eyes - a much nicer, more
> readable way to require modules: "Simplified CommonJS wrapping". Thanks for
> this hint!
>
> With the new AMD loader, I never liked the way to define/require modules
> because of the high risk of mismatching dependencies and their named
> function arguments. Moreover readablilty is poor and long dependency list
> look quite awkward and strange.
>
> Aside the above mentioned build issue: Are there any other reason not to use
> this approach with Dojo?
>
> Why is the "simplified CommonJS wrapping" approach not the default approach
> of Dojo?
>
> Just look at _WidgetBase.js and its huge dependencies list. Most of my
> page-level application controllers have such huge depenency list, too. And
> at moment I think - without knowing too much about AMD standard approach vs.
> "simplified CommenJS wrapping" - code readability could significantly be
> improved by using the simplified CommonJS wrapping approach. Or am I wrong?
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dojo-build-and-simplified-CommonJS-wrapping-tp3972049p3979663.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest


________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

allnamesrtaken
In reply to this post by Kenneth G. Franqueiro
And we dont get less dependencies to declare because we write them inside the function. Just line break after each dependency and things look nicer quick.

(and coffeescript it all and you dont have to worry about the commas while adding dependencies) :)
Reply | Threaded
Open this post in threaded view
|

Re: Dojo build and simplified CommonJS wrapping

PaulChristopher
I have already filed an enhacement request, see http://bugs.dojotoolkit.org/ticket/15350.

I'm really looking forward to seeing this implemented! At least my experience is: Most people are not overkeen on the new AMD loader syntax. Simplified CommonJS wrapping would be - from a coding point of view - a big improvment.