Jeremy Quinn pisze:
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.
Agreed.
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.
Jeremy, see Robin's suggestion about using Apache mod_proxy. Caching files served by Cocoon makes
much more sense to me than putting them into some directory where httpd will serve them from.
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 !!!!!
I don't know CDN service but for such a crucial component like Dojo I wouldn't be happy that we rely
on external, commercial entity that probably gives no guarantees on how reliable its going to be.
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.
It's good that you have mentioned working offline. I think it's important as there are many
developers willing to work offline. At least for me it's crucial that Cocoon is fully functional
without fast or any internet connection.
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.
Different JS files for different Forms? Isn't it a bit of overkill?
Also, keep in mind that in such case there is no chance for efficient caching when you have many
different forms.
Just to sum up: For me relying on CDN should be optional way and not primary one. The problem 6.5mb
added to distribution exhibits only weakness of 2.1 distribution system where you get "all-in-one"
package and you have no way to dynamically choose what you want to download.
As Hussayn already mentioned with Maven (and 2.2 obviously) this will be different because you state
your dependencies in pom.xml file and its Maven that downloads dependencies on the demand so its
possible that we'll have two different "implementations" of Dojo block.
The use of CDN would be another solution but as I said I'm happy with relying on external entity's
services. At least not by default.
--
Grzegorz Kossakowski
