Wrote answers below..
Martin Funk wrote:
> 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.
>
That's true, we could do something about that, so far I've only needed
one map, so didnt thought of us having a need for two maps.
> 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.
>
This has not caused any problems thinking of latency, there seem to be a
limit where adding markers on the fly seem to slow down, that's
somewhere around 400-500 markers. However I do agree that we have some
redundant code... My idea was to make the stuff work and then clean up
afterwards..
> 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.
>
>
However it seems a smart Idea you have about using functions instead,
i'll have to look into how you add markers that way...
> 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
>
>
>
-------------------------------------------------------------------------
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
