On 8/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > you know damn well thats not what i meant! jackass. the current "global
> id"
> > idea is simply not enough to fix much of anything.
>
> :)
>
> I was merely seeing it as a starting point for thinking about a
> solution. I think it would
> you know damn well thats not what i meant! jackass. the current "global id"
> idea is simply not enough to fix much of anything.
:)
I was merely seeing it as a starting point for thinking about a
solution. I think it would be possible, though like I said, it would
very easily become over-engin
On 8/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > there are just too many holes in this idea for us to implement it
> properly
> > where it Hust Works. we can implement it half way and spend a lot of
> time
> > answering questions as to why something doesnt work sometimes based on
> what
On 8/17/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> obviously it can, and what happens if one component includes YUI_1_2_0 and
> the other YUI_1_0_0? will it even function if you include yahoo.js twice?
> will the component written for 1_0_0 work on 1_2_0 ?
You can already have multiple compone
obviously it can, and what happens if one component includes YUI_1_2_0 and
the other YUI_1_0_0? will it even function if you include yahoo.js twice?
will the component written for 1_0_0 work on 1_2_0 ?
there are just too many holes in this idea for us to implement it properly
where it Hust Works.
On 8/17/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> we are not even talking about different versions here
Versioning could be part of the id obviously.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comm
we are not even talking about different versions here
-igor
On 8/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > > If you would allow for multiple links to an id, Wicket could try until
> > > it finds one for every request that comes in.
> >
> > there wouldn't be multiple links to an
i just downloaded dojo 0.9beta
it runs in at 16mb
if all i want is to build a modal dialog using dojo i do not want to
distribute a 16mb jar. given that is uncompressed and can probably shrink
down to less then a third, still it is gigantic.
so if i can strip out all i do not use and shrink my j
> > If you would allow for multiple links to an id, Wicket could try until
> > it finds one for every request that comes in.
>
> there wouldn't be multiple links to an id - the later contributions to the
> same
> id on the pages would simply be dropped?!
I'm talking about registering a root per i
>> but why shouldn't libraries actually deliver the whole packages with them and
>> set a common id on it - and it's wicket to decide which location came first?
>> it's no problem of data-redundancy in the jars, but contributing more than
>> once
>> to the browser.
>
> If you would allow for mul
> but why shouldn't libraries actually deliver the whole packages with them and
> set a common id on it - and it's wicket to decide which location came first?
> it's no problem of data-redundancy in the jars, but contributing more than
> once
> to the browser.
If you would allow for multiple link
hi igor,
> 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
> 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
> incl
> right and this is where the problem is.
>
> lets say i have a yui modal window component. so i strip yui only to what
> that needs. then i contribute a yui loader with a common yui id
> ("YUI_1_2_1"); all i have to contribute is the loader, and then it loads the
> rest of the resources.
>
> then
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 incl
> while this might help one-file js libs like prototype how is it going to
> work for libs that load other files themselves?
>
> you can have the same dojo version in two different components, but they can
> include different modules...
>
> the problem is that those libs try to load their dependenc
On 8/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > i have plenty of usecases where for different components i used dojo and
> i
> > stripped it down to just the widgets the component needed.
> >
> > or take scriptaculous, sometimes you want effects, other times just drag
> and
> > drop.
>
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
> i have plenty of usecases where for different components i used dojo and i
> stripped it down to just the widgets the component needed.
>
> or take scriptaculous, sometimes you want effects, other times just drag and
> drop.
>
> you are assuming that each component will include the full version o
On 8/17/07, Jan Kriesten <[EMAIL PROTECTED]> wrote:
>
>
> hi igor,
>
> > while this might help one-file js libs like prototype how is it going to
> > work for libs that load other files themselves?
> > you can have the same dojo version in two different components, but they
> can
> > include differ
hi igor,
> while this might help one-file js libs like prototype how is it going to
> work for libs that load other files themselves?
> you can have the same dojo version in two different components, but they can
> include different modules...
yes - and? as long as all dojo-files are included, b
while this might help one-file js libs like prototype how is it going to
work for libs that load other files themselves?
you can have the same dojo version in two different components, but they can
include different modules...
the problem is that those libs try to load their dependencies themselv
there's already a jira issue about this topic:
https://issues.apache.org/jira/browse/WICKET-771
On 8/17/07, Jan Kriesten <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> should there be a common way to include css/libraries?
>
> Currently, every component dependend on e.g. PrototypeJS is adding it to
> t
Hi,
should there be a common way to include css/libraries?
Currently, every component dependend on e.g. PrototypeJS is adding it to the
Page. Different components do this and if being on the same page, in the end
there may be 2 or 3 inclusions of the same lib from different locations.
Maybe the
24 matches
Mail list logo
