Transition to V3 classes

[amulet1]

This allows a seamless migration to V3 classes, while still supporting legacy {app}_Form_Type_{type} classes that do not yet have the correct V3 classes.

Note, the 3828e85 commit (included here because if affects V3 class too) provides a global fix to the behavior change in getInfo() for 'file' type. The horde/turba@5abeb2d fix is no longer needed as a result (and it was fixing it only in Turba, anyway).

Experimental, cherry-picked from my fork.

[ralflang]

This looks very interesting! Thank you for providing this.

[ralflang]

Thinking about it, the getInfo fix is something which should not have to wait for the PR as a whole. I will probably cherry pick this.
The is_a / is_object are also something I'd like to incorporate fast.

As for the additions to createVariable it seems like we had similar ideas - see VariableFactoryTrait

The global flag I am not so sure about. Maybe we can achieve the same without it?

As a concept I like very much lib/ trying the V3 classses first. It allows us to migrate even if not all types have been replicated yet (think custom or app specific types)

[amulet1]

Re: getInfo()

The original code was doing nothing if there was no file uploaded, so the closest we could do is to return null. Technically this is not 100% equivalent to the original code, but it restores the original behavior.

There could be other cases like that. Essentially we have to re-check places where we (now) have $info = [] to see if all paths should really return the array.

[amulet1]

Updated to exclude merged changes.

I think [to facilitate testing] we do not need the flag restoring old behavior. If any issues are found, they would be mostly related to possible out-of-sync changes between original and V3 classes, so should be easy to fix.

If the changes are merged, the next steps would be to migrate rendering code into the V3 classes; update other apps; then drop old classes (but keep Horde_Form for BC).

[ralflang]

I agree. Let's do it this way.

[TDannhauer]

@amulet1 : I applied this PR to my local instance and found no regressions from user perspective. PR is still marked as draft. How should we proceed? is it ready to merge?

FYI @ralflang

[amulet1]

Yes, I think we can proceed. I think the only issues could be if there are any leftover is_a checks (or any other checks expecting specific class name) or out-of-sync changes made in Horde_Form_Type only, but these should be easy to fix.

[amulet1]

I see a couple of places to fix (apart from tests and doc block comments):
https://github.com/horde/whups/blob/6494c88dec2100daf690b56509252f12e90020f8/lib/Driver.php#L165
https://github.com/horde/hermes/blob/2e58b9b6e6e6b22d52a43e86d224667f67c8d1d3/lib/Table.php#L51

Both should just use Horde_Form::createVariable for now.

Also, there are some references to Horde_Form_type::create() that should be eliminated, for exmaple:
https://github.com/horde/turba/blob/a027dfbb16ca41f349e146f2688805fb7a607c3e/bin/turba-validate-email#L71