Vitaly Tsaplin schrieb:
-- personally i like to be able to simply include the datepicker and not
-- have to worry or research what javascript library it uses.
i´ve talked this over with some guys personally, and maybe this was
discussed before, but consider this:
what if components could express contributions by a dependency
descriptor (maybe new Dependency(KnownLibs.XY, 1, 2) for xy 1.2) and
provide wicket with a javascript integration project, where some
versions of XY and others will be packaged? the page could resolve this
dependency and actually contribute the header.
- first thing that comes to mind, is that if lib XY has init code, that
really should run once, and once only, the page has a chance of
including it only once, if two components request for it.
- second, assuming that later version are always compatible with earlier
[yes, i know :) ], the page could decide to resolve to a later version
if two components use two different versions of the same lib
up to here, the cost of mainting these third party libs is as high, as
packaging them with a version descriptor. i really think, that would be
doable.
- third (now really dreaming) if some version shift is known to break
compatibility, the page could ask an handler to resolve this situation
or (if unhandled) throw an exception.
this makes it possible to a) be aware of using two components that
depend on different version of teh same lib and b) to get the PAGE in
charge of handling this situation and decide, what to do, as the page is
the one thing, the application coder has control over (whereas the
components are not). this would of course mean, that the libs desriptor
needs to declare that compatibility break and (and here comes the tricky
part), those people adding it to the "KnownLibs"-project have to know
about it.
what do you think?
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
