This is how we do JavaScript/ExtJS development at my work place, except with
a twist.


We actually have a javascript-only project for a our javascript "library".
We use the maven-javascript-tools plugins to create a javascript project
that relies on others (in our case, things like Simile Timeline and
ExtJS).   We then compile/minify the javascript into an 'artifact' that gets
used by our main webapp, where the alchim yui-compressor takes all the
CSS/Javascript and bundles as much of it as possible into a single huge JS
file.

The library project can make use of JSUnit tests (slow-to-run, recommend for
integration tests only), and has its own stubbed out controllers and jetty
for testing.

It's a very interesting setup, but I'm very happy with it.  We have very
modular JS code, and very very very very very very little JSP/HTML code (we
didn't select lift at work).  If I were to start using Lift for my backend
to ExtJS I would need support for a similar setup (i.e. expect little or no
HTML generated outside of the Javascript).


Also, the ability to cache dynamically created pages works great for our
product in production, however, we're only dynamically creating a javasript
file containing very static resources ("externalized string library" for use
when rendering in javascript.  This ensures our Javascript and Java
externalization works similarly.)  I highly recommend the approach if using
something like ExtJS,  however for lift's templates I'd agree that a
"page-unique-id" would be required for every synthetically created js file
so that caching works appropriately.  You can also force the browser to
check if something's "changed".  We have a development hack that checks
class-load time of the  synthetic-js-generator and ensures the cached copy
is up-to-date from that time.   This means jetty-reloads will reload the
class and ensure the next refresh pulls a new version.  It's a bit tricky to
get set up at first, but worked great!

Hopefully this input is helpful!

- Josh

On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat <c...@munat.com> wrote:

>
> I'm afraid I have to disagree. As a website developer, I've been putting
> all my JS into an external file (per page when necessary) for many years
> without any problems. Every good JS programmer I know does the same. It
> is considered *more* not less robust to put the JS in an external file
> and attach event handlers to the DOM from there.
>
> Page loading is in the eye of the beholder. Moving the JS to external
> scripts and the script tags to the bottom of the page actually makes the
> page appear more quickly, hence load faster in the mind of the user.
>
> Fragility is a non-issue. If the JS is all in the external file and the
> file does not load, then the page loads without JS. Put the event
> handlers in the HTML and the external file to which they refer doesn't
> load, same problem (except now you get a raft of JS errors).
>
> With best practices, the JS file can be cacheable, albeit per-page.
>
> Ideally, here's what I'd like. I add Lift tags to my page for each JS
> file I want included with the page. In each tag I designate whether that
> file is cacheable or dynamic and whether it is site-wide or specific to
> that page.
>
> Lift then takes all the site-wide cacheable pages, in the order I
> specified them, and gzips them up into a single file. Then it inserts a
> script tag for that file at the bottom of the page.
>
> Similarly, it takes all the page-specific cacheable pages, adds Lift's
> own page specific stuff at the end (the event handlers of which we
> speak), gzips it, gives it a name unique to that page, and adds another
> script tag for that file.
>
> Finally, it gzips up all dynamically-generated JS and gives it a
> timestamp for a filename so it won't be cached.
>
> This way I get jQuery, Ext JS, etc. all downloaded and cached in one big
> gzipped file. I get all page-specific but unchanging JS in another
> gzipped file for each page (cacheable, too). And I get my
> dynamically-generated, changing JS (if any) in a final gzipped file.
>
> My page is clean, all the scripts load in the proper order at the end,
> and everything is gzipped and, where applicable, cacheable for the best
> speed. We've just eliminated several points of failure, as I see it.
>
> Note also that since I use Ext JS, some of my JS files are very long and
> complex. I'm building a rich client, after all. I want to separate these
> scripts out into simple modules to make it easier to code them. But when
> they are served, I want them combined together in the proper order into
> one file. Another benefit of this system.
>
> On final option might be to indicate in the Lift tag whether the
> combined JS should be an external resource or inserted into the HTML
> page. Then you could insert the dynamic stuff into the page if you
> wanted to. (Of course, if nothing in the HTML changes, you've just
> prevented the caching of the HTML page, but it might be a useful option.)
>
> I wish I could offer to do this, but I'm desperately swamped at the
> moment (OK, forever). But this is what I would suggest as the best way
> to do things.
>
> Chas.
>
> Xavi Ramirez wrote:
> > If I understand everything correctly, the proposal is to dynamically
> > create a js file for each page request to add event handlers?
> >
> > If this is true, then I'm against the proposal for the following two
> reasons:
> >
> > 1. Every page will load slower
> >
> > Since the js file is dynamically create on each request, the js file
> > will be un-cacheable.  This means the browser be will forced to make
> > an addition HTTP request to the server to render each page.  This adds
> > roughly 150ms to the page load time (50ms to 200ms for network lag,
> > 50ms for download, 10ms for js execution).
> >
> > 2. Each page will be more fragile
> >
> > Requiring the synthetic js file will add another point of failure.
> > Even now-a-days with the ubiquity of broadband, connects still get
> > lost and files still get corrupted.
> >
> > It's true that most modern web pages already depend a number of
> > external JS and CSS files, but typically these files are static and
> > easily cached.
> >
> > Just adding my 2 cents.
> >
> > -Xavi
> >
> > On Sun, Sep 13, 2009 at 5:41 PM, marius d. <marius.dan...@gmail.com>
> wrote:
> >> I think so too. Does anyone have an opinion against this? I'll
> >> probably have some time this week or next weekend to work on it.
> >>
> >> Br's,
> >> Marius
> >>
> >> On Sep 13, 2:59 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> >>> A synthetic file sounds good to me and would probably be preferable.
> >>>
> >>> Cheers, Tim
> >>>
> >>> On 13 Sep 2009, at 20:31, marius d. wrote:
> >>>
> >>>> That looks a little cleaner but we'll have to look more into it if
> >>>> we'd want to go on this path. Perhaps accumulate those function into
> >>>> synthetic js file .. we'll see
> >
> > >
> >
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to