2.x: Preset Form Improvements

2.x already removes the ability define custom non-layer-supported projections. I don't see this removal as being necessary, since the preset ui is getting a lot better. Have you checked out the current 2.x branch?

Looking at the preset UI, I think there could be much improvement if we drop the 'all in one form' approach. I think an example of a really well-done UI that we could emulate is the Feeds module admin form. By divvying up the preset UI into different sub-forms, we can deal with error better, and drop the whole AHAH thing.

This will also allow different sections of the form to be more context aware. I'm thinking specifically of adding behaviors, and having the behavior know which layers are enabled, so they can be selected. Same thing obviously goes for layers and projections - we can drop AHAH and have things be a little more robust. There are other likely 'context' wins from this change.

Thoughts?

@phayes - I agree, I think that that approach is way better than trying to do the same dynamic stuff dynamically. It's a large task, though, and I'm not sure how we can exactly develop that alongside the 2.x branch without breaking the entire thing. Possibly we should have another branch for that task?

Hmm.. It's basically just rewriting the openlayers_ui module. Perhaps we could jump off into github, and then when we are satisfied we can dump it back into cvs in a big chunk.

sounds familiar ;)

Anyway, I'm kind of more for developing this in OpenLayers 3.x or something; I think we're already kind of messed up horribly on versions and all, and would like to keep it straightforward for now (not have some kind of 2.git version).

Also, we should probably churn through bugs & features for a while before making this change, and by that time possibly things will be different.

I guess this comes down to a question of how stable we want 2.x to be at the moment. My personal feeling is that as 2.x is in early alpha, that gives us permission to still pull the rug out from under people in pretty substantial ways. I think this should go into 2.x, I really don't want to start a new branch any time soon. Given that this is only a change to openlayers_ui and really shouldn't touch the rest of it, I would prefer destabalising 2.x, and simply not run an alpha2 until it's over. (Or run an alpha2 right before we jump into this, and not role an alpha3 before it's over).

I'd have to say I disagree entirely about the state of 2.x. I've been focusing narrowly on bugfixes, and think it would be a really bad idea to 'destabilize' it temporarily when it's moving quickly towards being a stable release. It's also extremely likely that the newest tagged version of 2.x will become the most-used branch, replacing 0.x in that role. The reality is that Managing News is a huge driver of usage here. The alpha designation is because we have just started tagging the branch, and the module itself, I would say, is more ready for end-users than 1.x, and the bugs are becoming more minor as we move on. Anyway, yeah, I am not cool with destabilizing 2.x for this change; it's not vital and having a steady stream of bugfix-centered tags is my goal.

I guess this is the problem with having different developers who are at different stages of capacity and availability at different times. There are things about 2.x that I'm not satisfied with that require some bigger changes (and need to be discussed), such as the event system, how behaviors work, and the preset UI among a few others. But my availability over the last few months simply has been limited, and will be for the next few also. You're at a stage where you want to concentrate on bug-fixes and polish, and revisiting some of these bigger issues is a pain in the ass for you. Ahh the joys of open-source...

I'm not quite sure what the way forward is. I really want to get us all on one page. I feel like 2.x has slid into 'bug-fixing' mode without much of a heads-up. Might I suggest that we set a deadline - say March 15th - where we close off major changes to the 2.x branch and concentrate on bug-fixes. That will give zzolo and I some time to roll patches for 2.x that are more fundamental. I think this deadline is enough time to do this, but also close enough that this won't inconvenience you too much.

Patches would be a good idea, the slight inconvenience of applying / reverting, etc., should be worth the utility they provide in neither branching nor destabilizing the 2.x branch.

I'm not ignoring the fact that there are big improvements and changes to be made to the 2.x module and I'm excited to see and help them happen. However, I'm interested in a stable, strong core of the module before developing any non-essential parts. My work on the project has been mainly in bug-fixing mode, but this doesn't mean that yours or Alan's have to be in that direction.

I don't think a deadline for middle of March or whatnot is a good idea, and I don't really get the intent behind it.

Ah good! I think we had a misunderstanding then. It's sounds to me like bigger changes are still welcome, as long as they are robust enough that they don't destabilize. I can totally work with that. I'm still a little confused about where we go with the UI update then. Are we willing to accept it into 2.x as long as when it is committed it is at a fairly robust / bugfree state?

Essentially. We should develop it as a big patch and have everyone test it before committing anything related to it. I'll post in this ticket if any changes change the code of the preset ui significantly.

Awesome!