I don't understand how your proposal solves the problem. How shall
Wicket ever know that two *.js files (may be with same name and size
but in different directories/jar because they belong to different
re-usable components) are the same and shall be downloaded just once?
Juergen
On 9/30/05, Scott Sauyet <[EMAIL PROTECTED]> wrote:
> And that leads to all sorts of dependency management issues that I don't
> know Wicket would want to address.
>
> Once upon a time, I wrote some PHP code which allowed me to use
>
> <.script src="js/js.php/lib1/lib2/lib3..." ...><./script>
>
> which returned all the Javascript in js/lib1.js, js/lib2.js, js/lib3.js,
> etc., as well as the (recursive) dependencies stored this way:
>
> file lib1.js:
>
> //~#depends on: lib3, lib5, lib7
> function myFunc() {
> ...
>
> I also implemented but never put into production two alternate
> dependency management definition formats, one which stored aliases to
> the Javascript files and their dependencies in an XML document, another
> which stored these same things in a relational DB.
>
> The advantage of these schemes is that when developing pages I needed to
> know only about my immediate Javascript dependencies, and not about
> anything those scripts required. It also meant that all my JS was
> downloaded in a single server hit. (The disadvantage was that since
> most pages had slightly different dependencies, there was little browser
> caching between pages. For me the advantages far outweighed this.)
>
> I can *almost* imagine how something like this could be implemented in
> Wicket. If the classes implementing <.wicket:head> gathered all the
> scripts together and then sent them in a single HTTP response, we might
> gain some of the advantages I discussed above, and avoid the problem
> which motivated this thread. The thorniest problem is that components
> package their JS dependencies in files stored in the component's
> directory. Something would have to be done to ensure that the same file
> is not included multiple times, preferably without trying to parse the
> actual Javascript.
>
> This same technique could be used for CSS, too, I believe.
>
> I don't know if there is something inherently un-Wickety about this,
> though. Any thoughts?
>
> -- Scott
>
> Eelco Hillenius wrote:
> > I see what you mean. So far we made sure that e.g. a DatePicker
> > doesn't contribute the same javascript includes for each instance. But
> > that's still too limited I guess. We additionally need some way to
> > globally (application level) register scripts, so that the header
> > contribition algoritm can detect whether a contribution was done yet.
> >
> > Juergen, in case you are reading with us, what do you think?
> >
> > Eelco
> >
> >
> > On 9/30/05, Scott Sauyet <[EMAIL PROTECTED]> wrote:
> >
> >>Hi Folks,
> >>
> >>It's been far too long since I asked a question on this list. One might
> >>think I was starting to "get it". :-)
> >>
> >>I'm planning on building my first reusable panel soon; and I'm pretty
> >>sure I understand what I need to in order to do this, but one thing is
> >>nagging at me. The panel will have associated Javascript. This is
> >>straightforward enough, but that Javascript file depends upon another
> >>Javascript library, Ben Nolan's excellent Behaviours
> >>(http://bennolan.com/behaviour/). I use that library for things other
> >>than this panel on some pages, but not on others. I'd rather not
> >>include it twice on a single page.
> >>
> >>I could simply include the Behaviour library on each page, needed or
> >>not, and have the panel assume that it will be in place. But I really
> >>don't like the idea that the panel can't be dropped into place. It's
> >>not meant as a reusable panel for anything off my current project, but
> >>it feels somehow... wrong. Perhaps I can add something to the Behaviour
> >>library that will only define things if they haven't already been
> >>defined, but that starts to bring back nightmares of old "#IFDEF" days;
> >>possible but not pleasing.
> >>
> >>So, I guess the question is, has anyone found an elegant solution to
> >>this problem? Am I missing something basic?
> >>
> >>Thanks for all the help this list has given.
> >>
> >> -- Scott
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by:
> >>Power Architecture Resource Center: Free content, downloads, discussions,
> >>and more. http://solutions.newsforge.com/ibmarch.tmpl
> >>_______________________________________________
> >>Wicket-user mailing list
> >>[email protected]
> >>https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
