Introduce HelperManager about ivory-google-map HOT 8 CLOSED

@ro0NL I don't understand your point here. Are you talking about the map itself or the map helper? Anyway, can you elaborate a bit plz? :)

from ivory-google-map.

Sorry i meant the MapHelper object, i.e..

public function __construct(
        CoordinateHelper $coordinateHelper = null,
        BoundHelper $boundHelper = null,
        PointHelper $pointHelper = null,
        SizeHelper $sizeHelper = null,
        MapTypeIdHelper $mapTypeIdHelper = null,
        MapTypeControlHelper $mapTypeControlHelper = null,
        OverviewMapControlHelper $overviewMapControlHelper = null,
        PanControlHelper $panControlHelper = null,
        RotateControlHelper $rotateControlHelper = null,
        ScaleControlHelper $scaleControlHelper = null,
        StreetViewControlHelper $streetViewControlHelper = null,
        ZoomControlHelper $zoomControlHelper = null,
        MarkerClusterHelperInterface $markerClusterHelper = null,
        MarkerImageHelper $markerImageHelper = null,
        MarkerShapeHelper $markerShapeHelper = null,
        InfoWindowHelper $infoWindowHelper = null,
        PolylineHelper $polylineHelper = null,
        EncodedPolylineHelper $encodedPolylineHelper = null,
        PolygonHelper $polygonHelper = null,
        RectangleHelper $rectangleHelper = null,
        CircleHelper $circleHelper = null,
        GroundOverlayHelper $groundOverlayHelper = null,
        KMLLayerHelper $kmlLayerHelper = null,
        EventManagerHelper $eventManagerHelper = null,
        array $extensionHelpers = array()
    ) {

Imho the argument length is insane. If a new helper is added is must be added last to maitainn backwards compatibility, etc.

Perhaps it could be reduced to something like:
public function __construct(HelperManager $helpers = null)

You want all helpers to be accessible within any helper, not just the map helper, right?

from ivory-google-map.

Same goes for the controls in the Map object, this could be reduced with a ControlManager...

$map->getControlManager()->get('zoom')->setOptions(/* ... */)

from ivory-google-map.

Definitively, the map helper constructor is a joke... Your idea is very interesting. IMO, the main issue is about the internal JS container build in order to organize the builded JS objects. If we aggregate helpers into other helpers, how do we generate this container? Is it the map helper responsibility to generate the whole container or each "aggregated helpers" should generate his own part of the container?

from ivory-google-map.

A MapHelper renders the map, a map contains markers, clusters, etc. by definition(!) So yes, the map helper is responsible for the whole thing, imho.

However it should delegate each part to individual helpers without knowing which helpers are registered, something like:
MapHelper::render(Map $map)

$result = '';
$sep = '';
foreach($map->getHelperManager() as $helper) { // HelperManager is iterable
    $result .= $sep . $helper->render($map);
    $sep = \PHP_EOL;
}

This way the Map is passed to each helper and provides scope to other helpers via getHelperManager. Maybe the MapHelper should be something special, e.g. extends ContainerHelper.

How and where the HelperManager is populated/initialized is still something to think of.

If you like I could help you designing the interfaces for a new major release, just let me know. Keep up the good work! Libraries like these are a must nowadays.

from ivory-google-map.

I got this idea.. perhaps the principle of rendering parts of JS code, containers, mirroring/mapping JS value objects and entities into PHP, local/remote assets, the whole fucking thing should get its own library. That way libraries like these only have to define/implement the concrete stuff/logic, i.e. Google Map JS API.

What do you think?

To give you an idea...

class \My\Google\Maps\SizeVO extends \Vendor\AbstractVO
{
    protected $namespace = 'google.maps';
    protected $className = 'Size';
}
abstract class \Vendor\AbstractVO
{
    protected $namespace, $className;
    public function init()
    {
        return 'new ' . $this->namespace . '.' . $this->className; // handle arguments etc.
    }
    public function assignTo($variable, $declare = true)
    {
         return ($declare ? 'var ' : '') . $variable . ' = ' . $this->init();
    }
}

edit:
The whole setOptions thing can be replaced with Symfony OptionsResolver and abstractified in, let's say, an OptionsArgument class.

edit 2:
This becomes a JS code generator thingy... which we probably don't want. Imho we should talk JSON and create some separate JS library that handles the JSON. Mapping the JS API into PHP is still desired though =)

from ivory-google-map.

I'm 👍 for your two proposals but I'm not sure the first one can be done so easily... Additionally, I don't know if you're aware of this feature but there is a special kind of helper: extension helpers which can prepend/append code before/after the container in order to allow people to put their own JS in the middle. Making this kind of extensions in the manager will not be easy...

First, we need to find a good proposal for helpers, your second proposal is interesting but we will see it later :)

from ivory-google-map.

It should work like reversed AMF for javascript where JSON is the message format. However I understand you dont want to change everything right away.

I noticed the extensions as I recently discovered how info boxes work ;-) The InfoBoxHelper and InfoBoxExtensionHelper vs. MapHelper::setInfoWindowHelper and MapHelper::setExtensionHelper were somewhat confusing... but I understand the purpose. It's a good thing you can use the InfoWindow as generic definition and decide somewhere else which JS implementation to use, but just like the helpers in general it's not very scalable.

from ivory-google-map.