But it would be really nice to have common libs that we could all depend
on. One problem is the wicket accordion contrib, if you use that in
conjunction with YUI contrib it falls apart. But then again im not sure
it would bring too much infrastructure.
Sven Meier wrote:
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?
Because all the different projects load script differently. So you could
easyly run into problems. Would be much nicer if you could somehow set
loading up one place and say I want my libs loaded remotely or loaded
locally ect.
This idea seems to be valuable for some javascript on an html page,
but IMHO it's not a modular solution appropriate for Wicket.
Depends on what you use from the project I guess.
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.
True. And I see your point. If we go that way we should just make a
couple of container projects carrying libs, and handling loading
mechanism maybe a common one if possible? And then projects that do
stuff can then depend on that. That way we sort of decouple for example
accordion contrib or open layers from specific versions of javascript
libs, although the different releases might depend on a specific
version. WDYT?
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.
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
