Sven Meier wrote:
Is wicket-accordion using YUI's javascript? Then perhaps it could have
a dependency on wicket-yui.
Not directly, but the javascript behind are using it. So I could
probably depend on wicket-yui, I'll try it out if possible...
I agree that we should have common libs we can depend on. That's what
I'm trying to do with wicket-prototype.
I'm just arguing against utilizing the google loader or a single
project where we throw in all javascript files somebody might need.
I see your point. There are also a couple of libs that arent in the
google one..
Sven
Nino Saturnino Martinez Vazquez Wael schrieb:
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
