Oh, I didn't explain that part, huh? :-( Hey, it was a long post!
I mentioned the problem this way:
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.
I can see a solution that works if the Javascript files are identical:
just do a hash on the entire file before storing it in the set of files
to combine. This would not be hard to implement, but is brittle, for if
the files differ by a single linefeed or trailing space, they would be
seen as different.
I really wasn't proposing this, just musing aloud. It seem to me that
there is a fundamental disconnect between Wicket's component packaging
and the idea of resources that might be shared by components. I don't
see a good way around this, though.
-- Scott
Juergen Donnerstag wrote:
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
-------------------------------------------------------
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
