Iulian Costan schrieb:
> yap, well done, also maybe we can put together the effort and improve
> things.
yeah, right on wicket-contrib-gmap2 is the most constructive comment I
was able to give on wicket-contrib-gmap.
Do a diff -r wicket-contrib-gmap wicket-contrib-gmap2 and it'll
precisely show which parts of the code I thought needed to be changed.
Pick the parts you like and merge em. After all its all Apache Licensed.
Now back to serious:
Some things that looked odd to me in wcg:
There can be only one gmap on a page. Now this might look like a rather
picky argument but the code that's the reason for this, shows that it
might be a reason for other problems too.
Line 73 of GMapInitializer.java
StringBuffer buffer = new StringBuffer("var googleMap =
null;\n").append(
The name of the JavaScritp variable holding the GMap is hardcoded into a
String in the Java code, ergo only one GMap per page.
Looking further into the code one can see that a lot of JavaScript code
fragments are hardcoded Strings in the Java code.
This is done for a reason. The project ought to be able to generate the
definitions of the functions that set up the GMap, its Handlers and its
Overlays at runtime. So that when the state of the GMap changes the
needed function definitions are send over net and are triggered by
wicket-ajax onSuccessScript on the client browser.
When I first saw that, being an absolute JavaScript newbie, I thought
its a cool trick and gives one a lot of flexibility. It's not lazy
loading, it's lazy definition. The server can wait till the user clicks
before the function implementing the maps behaviour, has to be defined.
That's sort of neat.
The downside of this, is that all this JavaScript code has to be
transfered over the net. And if you look at it its a lot of redundant
looking code, when one Overlay is added the definitions of all the
others is send over the net too. When the server is on localhost this
might not hurt, but I fear that the generated traffic might be too much
for a dsl-line.
Now becoming a JavaScript freshman, I think all that is not needed. Even
though wicket allows to send JS-code around, I think a project shouldn't
rely on it heavily. Wicket as a framework has to provide an JS-API for a
problem domain it can't foresee, in most wicket projects the JS-problem
domain is well defined. In this case a JS-file containing all the needed
classes and function definitions should be provided. JS-function
definitions are not meant to be shoved around the net, but JS-function
calls are.
It's the odd things, that inspire,
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
