Go-forward Form extension strategy?

[claytondaley]

I'd like to contribute to ZfcUser by normalizing some of the form handling behavior and propose some specific changes to the location and sequencing of Form construction. Before I do that, I want to make sure I'm clear on the go-forward strategy for Form extension.

As ZfcUser is split into many optional modules, I assume we'll badly need -- and therefore adopt -- a consistent Form extension strategy. This will make it possible for arbitrarily many modules to enhance a single Form. Is the preferred Form extension strategy still in flux or is there a specific strategy that's been decided?

An obvious choice is an event-based system -- a convention used (somewhat inconsistently) in the current code base. However, I'd hate to invest time standardizing and tweaking this strategy if it is instead a legacy that's going away.

[Danielss89]

@grizzm0 might have some insight to this, i know he has been working on it already.

[grizzm0]

Feel free to look at https://github.com/grizzm0/ZfcUser/compare/master...grizzm0:Refactor/form-inputFilter-validator for insperation. Sadly I don't have time to work at this atm.

[grizzm0]

And no, events is not a good idea imho. Other modules can add/remove form elements using delegators. That's powerful enough.

[claytondaley]

OK

• Who needs to consent to the delegator strategy before we can move forward on that assumption?
• The init event is widespread in the current codebase. Do we know why it's there?
  • If not, who needs to consent before we can remove it?

[grizzm0]

Init is called in the pluginmanager when the object is ready to use (ie, has been dependency injected)

On Tue, Mar 10, 2015, 00:53 Clayton Daley notifications@github.com wrote:

OK

• Who needs to consent to the delegator strategy before we can move forward on that assumption?
• The init event is widespread in the current codebase. Do we know why it's there?
  • If not, who needs to consent before we can remove it?

— Reply to this email directly or view it on GitHub https://github.com/ZF-Commons/ZfcUser/issues/576#issuecomment-77969600.

[claytondaley]

I think you misunderstand me. I'm literally talking about ZfcUser's form constructors (for example, see here and here).

[claytondaley]

@grizzm0 - Did you find a good strategy to provide $options to forms since you can't pass constructor parameters through FormElementManager->get()? Perhaps this particular item is still a work-in-progress as you definitely:

• Use FormElementManager->get() frequently to get forms
• Still have options in the RegistrationForm constructor

[grizzm0]

As events (imho) should be removed from forms what I said about init has nothing to do with the current code.

And about passing in options, https://github.com/grizzm0/ZfcUser/compare/master...grizzm0:Refactor/form-inputFilter-validator#diff-c0f52594dbb3f537ea4c4597888b0ae6R30

[claytondaley]

OK so back to my question... who needs to consent to:

• [BC] Removing events from forms (and)
• Establishing delegators as the "best practice" for extension (and setting a good example by using them in other ZfcUser modules)