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.
> 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)
> * 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 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?
>
This is a known issue and must be handled by server and/or application
configuration.
There was an issue # for this, but I can't find it. It did show that by
configuring the server
and application you can control access.
Unfortunately I don't remember the steps necessary to do this. But you
need to read the
spec related to your server, ie. tomcat, glassfish, etc.
The ThemeServlet as far as I know does not do anything that any other
servlet can do.
It get's its classloader which is controlled by the container and calls
getResource.
> o
>
>
>
> *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...
> *
We have incorporated these technologies into our own js namespace
allowing us to reduce
the footprint required to build applications with the Woodstock components.
If you want Prototype or Dojo or JSON features then you can load those
javascript files
using "script" tags.
We do not expose these technologies via our namespace as public
interfaces. We do not
guarantee that these technologies will always be used by the Woodstock
widgets.
If you want to load javascript files on every page "automatically", this
can be accomplished by
utilizing theme interfaces. Please see
http://webdev2.sun.com/woodstock-theme-doc/index.html
for infomration on this. However this doc is slightly out of date but
the property that you need to know about is "Theme.javascript". The value
of this property is a list of files that must be loaded in every page.
> *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).
> 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).
I'm not sure exactly what the question is here, but if you are using the
"webuijsf:head" tag
you can set the "debug" attribute to true and this will cause the
uncompressed JS files to be loaded.
However they can be rather large files, as a result of our trying to
decrease the request count at runtime.
You can also use a query parameter "debug=true" in the URL in the
browser search bar to turn on
debugging and get the uncompressed files.
-rick
> 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?
>
> 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
>-------------------------------------------------------------------------
>
>