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.
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.
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
