Re: Woodstock release 4.2 (- Build 4) and the "improved Javascript performance"
Jason Suplizio wrote:
> Excellent. So, woodstock has taken a portion of the dojo code and
> wrapped it in its own global namespace...so we won't have to worry
> about collisions with using various releases of dojo?
Right.
-rick
>
> autozoom, you will have to download prototype and reference the
> prototype.js file as you would in file in your web root (e.g.,
> http://localhost:8080/<yourContext>/web/scripts/prototype.js )
>
> Jason
>
> On Fri, Mar 14, 2008 at 12:38 PM, richard ratta <Richard.Ratta_at_sun.com
> <mailto:Richard.Ratta_at_sun.com>> wrote:
>
>
>
> autozoom wrote:
>
> >I have the same problem
> >When you suggest to load the prototype libraries by <script>
> tags, which one
> >is the url we need to refer to?
> >
> >
> Where ever you place the prototype library in your application.
>
> >Or do you mean to download and install prototype as an external
> library?
> >
> >
> I'm not sure what you mean by "download and install prototype as an
> external library".
> If you are referring to "netbeans" then, yes.
>
> >This would conflict with the woodstock one if and when it's loaded
> >
> >
> No. We have created a private namespace for the features that we use.
>
> -rick
>
> >
> >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 <http://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?
> >>
> >>
> >>*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).
> >>
> >>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).
> >>
> >>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 <http://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 <mailto:benjamin.kersten_at_s3.uni-due.de>
> >>D-45117 Essen, Germany Web: http://www.s3.uni-due.de
> >>-------------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
> <mailto:dev-unsubscribe_at_woodstock.dev.java.net>
> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
> <mailto:dev-help_at_woodstock.dev.java.net>
>
>