This just shot in my head and want to get it down. This is definitely post 1.0 (starting new tag).

The Layer Handler hook (or another hook) should include a way to put in form elements for options. Meaning that the Layers setting page will just aggregate options defined in each hook implementation. Right now, we are just manually creating a settings page in the Layers module.

Not a priority, but will be much cooler when someone wants to implement new layers that have specific options like keys.

Comments

zzolo’s picture

zzolo commented
Title: Layer Handler Form Options » Layer Handler Form Options for 2.0
phayes’s picture

phayes commented
Title: Layer Handler Form Options for 2.0 » 2.x: Layer Handler Form Options
zzolo’s picture

zzolo commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
zzolo’s picture

zzolo commented
Title: 2.x: Layer Handler Form Options » 2.x: Layer Handler Form Options and Architecture

This needs to be thought about more in detail. There needs to be a way to have specific form items for creating layers for each type of layer. Layers are now ctools plugins, but the idea of Types/Handlers Layers is not addressed.

zzolo’s picture

zzolo commented

Also, the layer handling in the UI needs to change a fair amount. Right now, it is just a form to add a specific kind of layer.

tmcw’s picture

tmcw commented

I'm going to be pushing a big commit to the 0.x branch with an ctools-plugins-powered version of layer types, which will let layer types provide options forms and generate exportable layers.

phayes’s picture

phayes commented

That sounds awesome.

We should have a discussion soon about which FAPI we will be using in 2.x . I am personally in favour of the ctools fapi since it seems to provide better functionality multi-step, dynamic type forms. I know zzolo has a different opionion. This is a good conversation to have know, as the FAPI for layers, layer-types, behaviors, presets is going to be an important part of 2.x

zzolo’s picture

zzolo commented

Do I? :)

I am torn on the subject. I am not a big fan of dependencies (in Drupal). And though we are already depending on CTools, I think there is a much better chance of having the plugin stuff into core, later on, than the FAPI changes. But all that is so far away, anyway.

I also don't know much about the CTools FAPI and what the real benefits are. Overall, I would say, if it makes sense and has some real benefit, then go for it. It would be nice to hear about the benefits, but I guess I'll take a look one day.

tmcw’s picture

tmcw commented

I'm not sure about the direction of the form api discussion - the ctools module provides functionality for multi-step forms, of which we have.. maybe one? I'm pretty sure that that omission from the Drupal form API is the reason why ctools provides an extension, and that it has no aspirations to be a replacement for the core drupal functions. That said, there's no big reason (besides... api instability perhaps) not to use the ctools form api enhancements when they make sense.

tmcw’s picture

tmcw commented
Status: Active » Fixed

The commit is made for layer forms, let's make detailed issues based on that for further work.

Status: Fixed » Closed (fixed)
Issue tags: -openlayers post 1.0 feature

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.