Hi Hussayn
Many thanks for your feedback.
On 10 Sep 2008, at 08:37, hussayn wrote:
Jeremy Quinn wrote:
1) Loading Dojo from Google CDN is the default.
dojo-rsrc.jar only contains a few static files required to support
Dojo in XD mode (a few K).
If a user wants to load Dojo locally, they dl their own copy and
use the provided build scripts to make a replacement dojo-
rsrc.jar
2) Loading Dojo from Google CDN is the default, but we provide the
full dojo-rsrc.jar in the dist (4.7Meg).
If a user wants to load Dojo locally, they add
<map:parameter name="dojo-use-cdn" value="false"/> to
their sitemap
3) Loading Dojo locally is the default
We provide the full dojo-rsrc.jar in the dist (4.7Meg).
If a user wants Dojo to load from CDN, they add
<map:parameter name="dojo-use-cdn" value="true"/> to
their sitemap
I personally think that (1) has distinct advantages.
Less code in our dist, very effective caching and serving of Dojo,
etc.
Hi;
From a commercial system integrators point of view i would not at
all like
the idea to keep part of the application outside of my companie's
firewall.
Yes, I understand.
So i guess, there will be huge demand to keep all content locally.
Hence
my favorite scenario would be szenario 3 plus a good documentation of
howto make different configurations.
But as you mention below, in a production environment, no one in their
right mind (whoops :) would serve static assets like Dojo from within
a jar file, via Cocoon readers ..... much more sensible to serve it
via Apache HTTPd.
So IMHO, the primary use of the dojo-for-cocoon dist, is to be able to
run the CForms Samples and do dev work.
So we either have the mega-build (full locale support etc.) currently
weighing in at 6.5Meg, making it by far the biggest jar in Cocoon!
Or we go for my new nano-build (and a default to use Google CDN, which
works extremely well BTW) weighing in at 12K !!!!!
BTW: Isn't it an option to use maven2 capabilities ?
Please keep in mind that I am working on a solution which will be for
both 2.1.x and 2.1.
If the maintainers of the maven dist so wish, they could distribute
dojo-for-cocoon as either the build for using a CDN /and/ as a build
to serve everything yourself.
But in the end, the only thing I think the mega-build is useful for is
development offline. As making your own build is so easy (there will
be an Ant build script in src/blocls/ajax/dojo) to me, it negates any
need to add this extra 6.5Meg to Cocoon's distribution.
Also keep in mind, that I hope it will become popular (and easy) to
build a layer file specific to a single form or application
(everything needed to support that form, packed into a single file).
Again, this has the same production-deployment issues as serving Dojo
itself.
You may be looking at
this
thread here:
http://www.nabble.com/Howto-use-Dojo-%22standalone%22-with-cocoon---%28does-that-make-sense-at-all-%29-to19040317.html
I experimented with this block and first i was quite satisfied. I
just was
asking myself, if maven
could be used to grab dojo from an external repository via
dependencies,
instead of keeping a
dojo-copy right within the block sources...
Anyways, i realised at some time of my experiments, that we got some
performance issues in our production environment. So we eventually
abandonned the above mentioned dojo-block and placed
the plain vanilla dojo-distribution directly on our apache-frontend,
so that
the dojo-files are now directly served from the web-server as static
files
(and we can simply upgrade to newer dojo-versions without modifying a
cocoon-block...)
A very normal approach.
well, this scenario might not fit into what you are doing since the
solution
we tried above, was not just a simple "give me the dojo"-block. It
sounds,
you are making a full integration into cocoon-forms.
YES :)
So, are you interested in learning CForms yet? ;-)
Just my 2 cents here.
Many thanks for your feedback.
Sorry I did not agree with everything you said, but I hope you
understand my PoV now.
I am obviously happy to discuss this further :)
regards Jeremy
