dev@woodstock.java.net

Re: Woodstock release 4.2 (- Build 4) and the "improved Javascript performance"

From: Dan Labrecque <Dan.Labrecque_at_Sun.COM>
Date: Mon, 17 Mar 2008 17:15:26 -0500

Benjamin Kersten wrote:
> Dear Woodstock team,
>
> I am developing custom JSF Components with the Woodstock-JSF-Framework
> and I've got a few questions for the current Woodstock release 4.2 (-
> Build 4) and the "improved Javascript performance". This performance
> gain is reached by lazy loading of JSON-, Prototype- and
> DynaFaces-Javascript-files. In your discussion forum you promote this
> as a reduced overall footprint of 614kb. I placed a required text
> field with autoValidation in my page and recognized a dynamic reload
> of about another 550kb (i.e. JSON, Prototype, DynaFaces) onBlur.
> Honestly, will there be any Woodstock JSF applications without AJAX?
> Hopefully not, so JS-lib-loading is just deferred, not reduced.

We get a lot of performance gain by lazily loading DynamicFaces,
Prototype, etc. And the JavaScript has been greatly reduced using gzip
and a custom Dojo build.

To see the greatest gain, the head tag's webuiAll and webuiJsf
attributes must be set to false. This will include only the most
commonly used resources. Most pages do not use Ajax features, so that is
where the 614 kb figure comes from.

That said, I'm not sure where you're getting the 550 kb figure from?
Including JSF Extensions, Prototype, and JSON only adds another 60kb.
Although, I've seen the Firebug plug-in add subsequent Ajax requests to
the total download (e.g., progress bar updates). Therefore, the Ajax
features used in your page could be clouding the real download size.

> The disadvantage of that "new feature" for my purposes is that I made
> use of Prototype functions and DynaFaces AJAX requests (with JSON as
> datainterchange format) in JS-parts of my custom JSF components and I
> did not appreciate to recognize that my components failed to work
> because of the missing JS libraries with the current release.
> There are several ways to handle this (as mentioned in the release notes):
>
> * Load Prototype via the <jsfx:scripts/> tag of jsf-extensions:
> o My customer (user of my custom JSF component) would have
> to include the jsfx-namespace and jsfx-script tag into the
> page, just to make my component working
> o he (or my custom component jar) would also have to include
> shale-remoting.jar, as jsfx:scripts makes use of
> "org/apache/shale/remoting/XhtmlHelper" and throws a
> ClassNotFoundException if not included (if I did not miss
> s.th. this is not even mentioned in the 4.2 Build 2
> release notes)
>

It is true that JSF Extensions uses Shale to load JavaScript, but you
could also use a script tag instead. I believe the release notes ask
that you please see the documentation below?

    https://jsf-extensions.dev.java.net

> * Direct use of the ScriptsComponent.class of jsf-extensions
> (included in my custom JSF component so that the end user does
> not have to insert additional tags)
> o works for inital page load
> o ScriptsComponent.class throws
> "java.lang.ClassCastException: [Ljava.lang.Object; cannot
> be cast to java.util.Map" in its restoreState method
> o => not working, did not debug yet
> * in addition to that JSON is still missing (when loading
> Prototype and DynaFaces via jsfx:scripts) and I considered
> another possibility:
>

I'm not certain which "JSON" is missing? The file that is no longer
included is the json.js file from json.org. We now embed this resource
in our own name space, which is automatically included whenever Ajax
features are used.

Were you using the json.js file to decode JSON strings? This was never
intended to be exposed as a public interface; although, it's still
available via the json2.jar file. Technically, you could still include
this file via a script tag, but prefer you get it from json.org.

> * I could force to load them using <webuijsf:script url="..."/> or
> via direct use of the Script.class in my custom component (which
> would cause additional overhead to check that the libraries are
> loaded only once if the component is used multiple times in the
> page). However, this is not the neat way AND... ( some off-topic
> my 1st question:)
> o 1) ...this way I would have to load the JS files via the
> /theme/...-path (ThemeServlet). Some time ago I already
> asked myself if this is a security flaw as I can read ALL
> files via /theme, including my WEB-INF-files (web.xml,
> faces-config.xml, ...) and I regocnized that accessing
> these files is not possible on productive Woodstock sites.
> Is there a common way to control access via the ThemeServlet?
>
>
> *Back to the missing JS files: Due to the points mentioned above my
> most important question:
> 2) **_How can I dynamically reload the three JS files (Prototype,
> JSON, DynaFaces) on my first AJAX request as you do it?_ Is there a
> JS-function to call in your bootstrap.js API? How can I do this...
> 2a) with DOJO
> 2b) without DOJO
> *In particular 2b) is important for me. Besides I don't like the DOJO
> approach of client side replacement/rendering of JS objects at all in
> general, I'm developing a component dealing with large data grids
> which performed bad when handling the grid with JS. Because of that, I
> don't use DOJO but the IMHO "typical way" of JSF, i.e. server side
> component rendering (of HTML).

The webuiJsf tag attribute of the Woodstock head tag will also include
DynaFaces and Prototype. However, if you're depending on either of these
resources, I strongly urge you to include these resources yourself. The
webuiJsf attribute may include more JavaScript functionality than
needed. We also cannot guarantee JSF Extensions will always use
Prototype -- that is a separate, open source project from Woodstock.

>
> 3) Why are these important functions (e.g. JS function to reload the
> three JS files) not clearly documented? I've already had problems to
> find information with respect to different issues several times... Is
> the documentation pretty incomplete or did I just miss some important
> web pages except for the woodstock project pages? Refering to the
> current problem the roadmap just announced a "custom dojo.jar", the
> lazy loading of DOJO, Prototype and DynaFaces was on short notice with
> the 4.2 Build 2 release in the release notes and "hidden" in a
> discussion forum thread called "Preformance". Furthermore and most
> important I could not find a single page describing the issue of my
> "question 2". When trying to get information by debugging I have to
> handle compressed/obfuscated one-line JS-files of Woodstock (as usual
> I must admit). Unfornately, these points combined make development
> with Woodstock costly in terms of time (and pretty ugly sometimes).

Simply put; JSF Extensions, Prototype, and JSON were never intended to
be exposed as public interfaces. Therefore, we have not documented its
usage. If you want to include these resources yourself, that's fine, but
we don't want to support 3rd party resources. In fact, we've added a
head tag attribute to prevent JSF Extensions from being loaded at all,
avoiding any potential conflicts with your version.

>
> 4) Where should I have posted / discussed these issues if not via
> email? Is there no public user forum like offered by different
> 3rd-party-JSF-libs? Although I have a java.net account, I may not post
> to the discussion forum but have to join projects to become an
> observer in the first stage?

The users_at_woodstock.dev.java.net alias is the best place for questions.
Although, if you have questions about JSF Extensions, please use the
users_at_jsf-extensions.dev.java.net alias.

Dan

>
> Thanks in advance for help...
> Kind regards
> -------------------------------------------------------------------------
> Benjamin Kersten
> University of Duisburg-Essen, ICB Phone: +49 (201) 183 - 4683
> Specification of Software Systems Fax: +49 (201) 183 - 4698
> Schützenbahn 70 Email: benjamin.kersten_at_s3.uni-due.de
> D-45117 Essen, Germany Web: http://www.s3.uni-due.de
> -------------------------------------------------------------------------
>