[fusion-dev] RFC 1: Use OpenLayers.Class and other prototypecapabilities

[Jason Birch]

I think you've chosen the right path with this, and think that tighter
integration with OpenLayers (such that both projects benefit from
shared work) would be a good idea.  OpenLayers seems to highly value
a stable API and generic functionality so, at least under its current
direction, I personally don't see any problem with tighter integration.

I guess it's a bit late for me to say I can't comment on the
technical aspects (which I can't), but the architectural decision
seems sound :)

Jason

-----Original Message-----
From: Paul Spencer [mailto:pspencer at dmsolutions.ca] 
Sent: Thursday, March 20, 2008 13:29
To: Jason Birch
Cc: fusion-dev at lists.osgeo.org
Subject: Re: [fusion-dev] RFC 1: Use OpenLayers.Class and other
prototypecapabilities

Jason,

that is correct.  In addition, it would make it much easier to  
consider moving to a different GUI framework such as ExtJS although  
that is not something that we are thinking of doing.

Based on my work with OpenLayers, much of the functionality that we  
would be relying on was originally copied from Prototype (or at least  
inspired by Prototype) when OpenLayers removed its own dependency on  
Prototype.  While I haven't done a lot outside of OpenLayers with that  
framework, it is working very well for OpenLayers and the API has not  
changed in a while.  There is some current work being done on the Ajax  
support in OpenLayers that will make it somewhat different from the  
existing Prototype API but I believe it will still work for our needs  
and may in fact improve it for us too :)

There is an alternative, which is to bring the essential parts of  
Prototype (or equivalent) into the Fusion namespace so that we are not  
dependent on anything (for that at least).  However, this would  
duplicate code and functionality and I am not keen on maintaining any  
more code in Fusion than necessary.  As time goes by, I am going to be  
proposing even tighter integration with OpenLayers (think  
Fusion.Widget = OpenLayers.Control for instance).

An argument against tighter integration may be that we may want to  
replace OpenLayers with another map management library at some point.   
However, I don't see anything on the block that is going to compete  
with OpenLayers at the moment and I don't feel that this is a bad move  
on our part.

Cheers

Paul


On 20-Mar-08, at 4:17 PM, Jason Birch wrote:
> So...
>
> This RFC is basically removing Fusion's explicit dependencies on
> Prototype, so that Jx is free to move to a different framework without
> disrupting Fusion?
>
> If so, sounds reasonable to me.
>
> Are these components in OpenLayers stable/enshrined enough that
> switching to that implementation will not incur the same risk of
> disruption?
>
> Jason
>
> -----Original Message-----
> From: fusion-dev-bounces at lists.osgeo.org
> [mailto:fusion-dev-bounces at lists.osgeo.org] On Behalf Of Paul Spencer
> Sent: Thursday, March 20, 2008 12:49
> To: fusion-dev at lists.osgeo.org
> Subject: [fusion-dev] RFC 1: Use OpenLayers.Class and other
> prototypecapabilities
>
> I realize that we don't have a PSC yet, however I would like to start
> working as if we did have one and use the current membership of the
> dev mailing list to discuss major changes to Fusion.  We will be
> working to formalize a PSC as we grow the community around Fusion.  In
> the mean time, I have a major change that I would like to get
> community consensus on.
>
> If you are interested, please see the following RFC and comment on
> this list.
>
> http://trac.osgeo.org/fusion/wiki/FusionRfc1
>
> Cheers
>
> Paul
> __________________________________________
>
>    Paul Spencer
>    Chief Technology Officer
>    DM Solutions Group Inc
>    http://www.dmsolutions.ca/
>
> _______________________________________________
> fusion-dev mailing list
> fusion-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fusion-dev


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/