On 8/17/07, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > > hi igor, > > > you are assuming that each component will include the full version of > the js > > lib even though it only uses a small subset of it - probably not the > case. > > no, i'm talking about having a possibility to make a full included version > public available. if one doesn't want to include a full verion - that's > ok, but > that wouldn't get the common id. no more - no less.
look, im not arguing that we should not do this, simply pointing out a hole that can potentially lead to problems and getting you guys to concentrate on figuring out a way to patch it. one way we can work around it is to build out a jar with all these commonly used libs in core. that way if someone needs to use the lib they simply include a header contributor from our core project - that way we dont even need the extra id for filtering. of course what that means is that now in core we would have wicket-scriptaculous, wicket-prototype, wicket-dojo, wicket-foo which is a huge maintenance headache for us, and probably not the way to go. if anyone has any better solutions im all ears. the problem is that the components are encapsulated, so you can never count on any of them to include the full version of any lib they depend on. and today unfortunately these libs are so big that they come with multiple files - and on top of that have all these dynamic loaders. -igor --- jan. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
