Hi Roald,
comments inline.
On 16.10.2012 02:22, Roald de Wit wrote:
Hi devs,
I'm currently also in the process of migrating to ExtJS4/GeoExt2 and
looking forward to helping out by testing and reporting issues.
Cool. Would you mind taking some notes about the steps needed? That can
be a valuable resource for a help-document.
One thing that I'm dealing with is the situation where a map panel can
already be created (or even rendered) before the OL map object is
created (when the map configuration is loaded through an AJAX call
after application startup for example).
I've worked around this by overriding the gx_mappanel initComponent by
copying most of what's in there but not calling the parent yet, but
ideally, most of the code in initComponent would be in other methods
that get called by initComponent, hence reducing the need to duplicate
code.
I'm having a similar problem with the layer tree (and adube's layer
tree builder): it needs to have the layer store available on init,
where in my use case the layer tree can be there before the map (or
layer store) is available.
To work around the issues mentioned above I introduce a 'mapready'
event listener in my map panel and a 'layerstoreready' listener in my
layer tree builder (that extends adube's). The logic of loading the
map and making the panel's 'aware' is happening in my controller.
Yeah, why not? I'd gladly hav a look at the two pull requests.
Thanks,
Marc
Do others have similar requirements and is it worth making GeoExt2
capable of delaying rendering until a map object becomes available?
Regards, Roald
On 10/10/12 18:18, Marc Jansen wrote:
Hi all,
I personally feel that GeoExt2 is basically ready for prime time. We
used it successfully in some fairtly big applications and only found
minor bugs/annoyments we already fixed in the codebase. There is
still at least one fixed bug I am going to integrate into the
master-branch soon.
Nevertheless, I suggest to start the release process for the version
2 of GeoExt.
Do you share that opinion?
I think that there is still a lot of work, though:
* We should double check all classes and examples with regard to
o API compatibility with v. 1
o documentation
o tests
o and some sort of coding style
* Where will we be hosting the API docs? Are we going to change
geoext.org? Or shall we simply stick with gh-pages? Are we going
to integrate runnable examples inside of the documentation?
* We also need some prose docs / tutorials
o about migrating existing application
o building a single-file application
o getting the best out of MVC
o API-changes (If we have any)
* What is the release procedure? Are the steps outlined here
(http://trac.geoext.org/wiki/Release/Procedure) still relevant?
I suggest starting with an early beta version in the next few days,
so that we can make people aware of GeoExt2 and hopefully get
feedback about the library.
In case you agree with the starting of the release process, we also
need to decide who will be the release manager?
What other points / aspects did I miss?
Please tell me your opinions and about the next steps needed to get
to GeoExt 2.0-beta.
Best regards,
Marc
_______________________________________________
Dev mailing list
Dev@geoext.org
http://www.geoext.org/cgi-bin/mailman/listinfo/dev
_______________________________________________
Dev mailing list
Dev@geoext.org
http://www.geoext.org/cgi-bin/mailman/listinfo/dev
--
Dipl.-Geogr. Marc Jansen
--- Anwendungsentwickler ---
terrestris GmbH & Co. KG
Pützchens Chaussee 56
53227 Bonn
Tel: +49 (0)228 / 96 28 99 -53
Fax: +49 (0)228 / 96 28 99 -57
Email: jan...@terrestris.de
Web: http://www.terrestris.de
Amtsgericht Bonn, HRA 6835, Komplementärin: terrestris Verwaltungs-
gesellschaft mbH, vertreten durch: Hinrich Paulsen, Till Adams
_______________________________________________
Dev mailing list
Dev@geoext.org
http://www.geoext.org/cgi-bin/mailman/listinfo/dev
