As the initiator of the wicketstuff-prototype project I don't see much
value in utilizing the google loader:
Who want's to depend on google just to load other project's javascript
files?
I can't imagine anyone wanting to load javascript from a foreign URL
just to do some jqueries:
- you must be online
- what about reliability of service?
- NoScript will bark
Why put different javascript libraries into a single project?
This idea seems to be valuable for some javascript on an html page, but
IMHO it's not a modular solution appropriate for Wicket.
We already have wicketstuff projects for scriptaculous, dojo and gmap(2)
- they provide the required javascript files.
If someone needs it, we can setup wicketstuff-jquery or whatever similar
to wicketstuff-prototype.
For dependency management we already have a solution: maven.
My 2 cents
Sven
Jan Kriesten schrieb:
Hi Martijn,
So we could do a hybrid solution? Create a distribution that includes
all archived releases, and ships google loader (or create our own
wicket loader) that can run in either local or internet mode?
I don't know if the google loader accepts changed base urls - if yes,
that could be used.
I'd rather keep it out of extensions. I imagine this project have a
much higher release rate than the rest of the projects since it
depends on ~5 external libraries that have different release
schedules. So that would make it a better candidate for stuff I think.
That could be split IMHO - the internet-mode could be placed in
core/extensions. Projects needing to have local libraries have to add
the current stuff-lib containing the libraries.
Another problem that has already been discussed: what to do with
componenents requiring different libraries/library versions. Should
there be some policy so a developer is warned when mixing those
components on one page?
--- Jan.
