Having a hard time getting started

[Bill]

Hi all,

I like what I've read about Jingo, but am having a hard time getting
started using it. Is there a reference application using Jingo that I
could study carefully?

Regards

--Bill

[se...@artisanlogic.com]

Hi Bill,

Thanks for your interest in Jingo.

John and I are actually working on a demo application for the 0.9.0-
beta release tonight, but in the mean time we'd be glad to answer any
questions you may have directly.

We're glad to help folks get rolling with Jingo and the process will
help us improve the GettingStarted(http://code.google.com/p/jingo/wiki/
GettingStarted) section of the Wiki.

Some background info regarding your platform and whether you are
running against the 0.8.2-beta release or building Jingo from source
will help us give the best answers.

Take care,

-Sean

[Bill French]

Thanks you, Sean, for the prompt reply.

I'm considering the Jingo 0.8.2-beta release for a web application
that makes heavy use of jQuery/jQuery UI/jQuery plugins. The web app
is Java based, runs in Tomcat (usually, but not always) on Windows. We
test pages in IE 6, 7 & 8, FF 2 & 3, Safari, and Chrome.

Not all pages in the application use the same pieces of functionality,
so it's necessary (without Jingo) to include our Javascript in order
of transitive dependency:

(1)
<script type="text/javascript" src="js/lib/jquery/jquery-1.2.6.min.js"></script>
<script type="text/javascript"
src="js/lib/jquery/jquery.bgiframe.min.js"></script>
<script type="text/javascript"
src="js/lib/jquery/jquery.scrollTo.min.js"></script>
<script type="text/javascript"
src="js/lib/jquery/jquery.ajaxmanager.min.js"></script>
<script type="text/javascript"
src="js/component-that-relies-on-some-stuff-above.js"></script>
<script type="text/javascript"
src="js/second-component-that-relies-on-some-other-stuff-above.js"></script>

It would be much nicer if I could just include the following code on every page:

(2)
<script type="text/javascript" src="defaultJavascript/loader.js"></script>

which would write the first code listing to the DOM on the fly. Enter
Jingo. I understand that much, but still don't understand what's
required to get all these pieces working in concert.

So I guess the first big question is whether or not I can use Jingo to
load jQuery and jQuery plugins. The filenames alone indicate that
they'd give Jingo trouble, since they contain periods. And if I could
use Jingo to load the jQuery framework, for example, what would that
look like in terms of declaring a module in Jingo?

Your input here is greatly appreciated. Thanks in advance for your
help, and for your great work.

Regards,

--Bill

[se...@artisanlogic.com]

Heya Bill,

Thanks for the background info.

This type of transitive dependency load order pain is exactly what
Jingo is meant to relieve. However Jingo can only reliably manage
transitive dependency loading of JavaScript modules that are contained
within a Jingo envelope and adhere to a Java/Python-like "package"
structure. The Jingo envelope is very thin and actually helps to
provide "executable documentation" of the module's dependencies as
well as providing other benefits outlined in the "Features" section of
the Wiki. The organization structure imposed by Jingo should be very
familiar to your team members due to their Java exposure. It promotes
a "everything has a place, everything in its place" level of
organization for your JavaScript modules which pays dividends beyond
transitive dependency management.

Jingo a great way to get control of your "in-house" JavaScript, but
when dealing with third party libraries one is left with a choice.
Maybe someday John Resig and the jQuery crew will flatter us by
managing jQuery module dependencies with Jingo, however the current
reality is that third-party JavaScript rarely if ever comes wrapped in
a Jingo envelope. The result of this is that a team must decide to
either manage third-party dependencies the old fashioned way or spend
the time to "Jingoize" them. Well written/encapsulated external
libraries (e.g., jQuery) turn out to be extremely easy to wrap with
the Jingo envelope and place in a Jingo package/namespace folder
structure. It really comes down to a cost-benefit analysis of whether
you'd like to incur the initial effort of "Jingoizing" your third
party libraries or the effort of managing your dependencies on them in
the old-fashioned way.

I gotta run for dinner, but I'll get back on shortly and try to show a
quick example of what "Jingoizing" jQuery.js and one of its plug-ins
might look like.

Take care,

-Sean

[se...@artisanlogic.com]

Hello again,

So here goes an example of "Jingoizing" jQuery and one of its plug-
ins:

Original jQuery.js:

/*!
* jQuery JavaScript Library v1.3.2
* http://jquery.com/
*
* Copyright (c) 2009 John Resig
* Dual licensed under the MIT and GPL licenses.
* http://docs.jquery.com/License
*
* Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009)
* Revision: 6246
*/
(function(){
/* ... jQuery source */
})();

Jingoized jQuery.js placed directly in the main script repository
directory (defaults to "scripts", see jingo.init docs on the getting
started page to find out how to override):

/*!
* jQuery JavaScript Library v1.3.2
* http://jquery.com/
*
* Copyright (c) 2009 John Resig
* Dual licensed under the MIT and GPL licenses.
* http://docs.jquery.com/License
*
* Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009)
* Revision: 6246
*/
jingo.declare({
name: 'jQuery',
as: function() {
/* ... jQuery source */

/*
it's safest for a module not to effect the global scope
other than under it's own namespace, therefore we
choose to disable the $ alias to the jQuery function
Note: this is optional
*/
jQuery.noConflict();
}
});

Now that jQuery is a full blown Jingo module we can Jingoize a
jQuery plugin that depends on it.

Original jquery.ajaxmanager.js:

/**
* @author alexander.farkas
*
* @version 2.1
*/
(function($){
/* ... jquery.ajaxmanager source */
})(jQuery);

Jingoized "ajaxmanager.js" placed in a "jquery" subdirectory of the
main script repository directory:

/**
* @author alexander.farkas
*
* @version 2.1
*/
jingo.declare({
require: [
'jQuery'
],
name: 'jquery.ajaxmanager',
as: function() {
var $ = jQuery;
/* ... jquery.ajaxmanager source */
}
});

From here its pretty simple to write an in-house module that depends
on jquery.ajaxmanager.

Internal Jingo module "module.js" in the "internal" subdirectory of
the main script repository directory:

jingo.declare({
require: [
'jquery.ajaxmanager'
],
name: 'internal.module',
as: function() {
/* ... some code that depends on jquery.ajaxmanager */
/*
This module does not have to list jQuery as a transitive
dependency, but if it uses jQuery directly it is good
practice to list it in the requires list since it is a
direct rather than transitive dependency at that point
*/
}
});

Now loading modules into our html, jsp, etc. becomes:

<html>
<head>
<title>Some Title</title>
<script src="scripts/jingo.js" type="text/javascript"
encoding="utf-8"></script>
<script type="text/javascript" encoding="utf-8">
jingo.anonymous({
require: [
'internal.module'
],
exec: function() {
/* some code that depends on internal.module */
}
});
</script>
</head>
<body>
<!-- ... page body content -->
</body>
</html>

As you can see "Jingoizing" a well written library or libraries is
fairly painless. A modularized system such as jQuery and its plug-ins
lends itself very well to becoming Jingo modules. However, it really
is up to the team to decide which approach to take for third-party
module dependencies ("jingoize" or "manual include").

I hope that helps. Let us know if there is anything we can clarify or
other questions we can answer.

It's also worth noting that there are some major features around the
corner in 0.9.0-beta release that help you run your javascript modules
optimized for debugging support while you are in development and
optimized for download performance when you go to production with zero
code changes. The current release of Jingo already does a great job
of optimizing the development experience. In 0.9.0-beta, with the
addition of static assembly (also referred to as concatenation) and
source code compaction (also called minification) projects that
leverage Jingo for dependency management can optimize for quick
response times in production. The static assembly process will be
packaged as an Ant task or Maven plugin for the Java folks and a
command line interface for folks on other platforms.

Take care,

P.S. As an aside I would also highly recommend JSLint (http://
www.jslint.com) as an invaluable tool to help find problems early and
avoid a whole lot of run-time JavaScript debugging marathons :)

-Sean

[Bill]

Hi Sean,

Thank you so much for the in depth reply. The work you're doing is
great and much needed.

We've got a lot of vested interest in using jQuery. As a lead UI
developer, I chose jQuery as our primary Javascript framework because
1) it's fairly easy to work with and 2) its large developer community
is continually adding to the pool of available functionality using
jQuery's plugin architecture. We have a professional services group
who do heavy customization of our product's UI; they'll be making
heavy use of jQuery's numerous extensions. While they're all
technically savvy, they "just want it to work." They'd rather not
explore the details of how Javascript source is loaded, and certainly
won't want to Jingo-ize every jQuery plugin they use.

Jingo looks great, but if it's unable to manage dependencies for all
Javascript (without modification, anyway), it will introduce new
problems while solving others. It seems that other potential Jingo
users will be facing the same issue. Was this something the developers
of Jingo considered? Is there any way that Jingo could load Javascript
modules that weren't contained within a Jingo envelope? What do Jingo
developers do when they're using third party Javascript modules?

Maybe I should just develop an Ant task that Jingoizes jQuery and
jQuery plugins.

Thanks again for all of your time.

Regards

--Bill

On May 14, 8:47 pm, s...@artisanlogic.com wrote:
> Hello again,
>
> So here goes an example of "Jingoizing" jQuery and one of its plug-
> ins:
>
> Original jQuery.js:
>
> /*!
>  * jQuery JavaScript Library v1.3.2

>  *http://jquery.com/

>  *
>  * Copyright (c) 2009 John Resig
>  * Dual licensed under the MIT and GPL licenses.

>  *http://docs.jquery.com/License

>  *
>  * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009)
>  * Revision: 6246
>  */
> (function(){
>   /* ... jQuery source */
>
> })();
>
> Jingoized jQuery.js placed directly in the main script repository
> directory (defaults to "scripts", see jingo.init docs on the getting
> started page to find out how to override):
>
> /*!
>  * jQuery JavaScript Library v1.3.2

>  *http://jquery.com/

>  *
>  * Copyright (c) 2009 John Resig
>  * Dual licensed under the MIT and GPL licenses.

>  *http://docs.jquery.com/License

> P.S.  As an aside I would also highly recommend JSLint (http://www.jslint.com) as an invaluable tool to help find problems early and

[se...@artisanlogic.com]

It's generally been our experience that the number of internal modules
outnumbers external modules by quite a large margin for projects that
are developed in a truly modular fashion. The case where someone is
heavily leveraging a truly modular third party systems such as jQuery
or Dojo may be one of the few exceptions. I won't say that the
transitive dependency problem isn't solvable without the envelope
approach, but we haven't found it to be very elegantly or consistently
solvable without it. Also remember that the envelope has benefits to
the developer as well as the dependency manager. Having each module
internally document its own dependencies makes the code much easier to
navigate.

There are other transitive dependency management options out there for
JavaScript. We outline some of them in our Jingo Presentation (http://
www.slideshare.net/bitbutcher/javascript-dependency-management-presentation/)
and discuss why we found the approaches to fall short. Taking a look
at this presentation will probably either help you understand why we
arrived at the enveloping approach or help you find another loader
implementation that fits your needs better.

With Jingo it's probably most common to load external modules manually
and internal modules via Jingo. Most larger systems have external
dependencies in the single digits where internal modules necessary for
a page to operate can often number well over 50 when a JavaScript
system is decomposed much like a Java or Python application would be.
This generally means that internal modules are the leading cause of
"script tag hell", and Jingo deals with internal modules quite nicely.

The Ant task you describe shouldn't be particularly hard to
implement. Particularly if your use of third party libraries is
limited to the jQuery community. They seem to consistently employ the
good practice of providing an anonymous function wrapper for their
modules.

Feel free to log a feature request to our google code issue tracker so
we can take the "Jingoizer" Ant task under consideration for a future
release.

Take care,

-Sean

> ...
>
> read more »