Skip to content

Complete V3 design for feature parity with lib/ #19

Open
Open
Complete V3 design for feature parity with lib/#19
Assignees
amulet1

Description

@ralflang
ralflang
opened on Mar 5, 2026
  • Detect missing features and aspects in the src/V3 implementation.
  • Find modern, strongly typed equivalents to lib/ paradigms, potentially using named parameters and defaults.
  • Implement missing aspects
  • Update unit tests to cover the new design. Expectations should be equivalent with lib/ (equivalent input yields equivalent output)

Activity

  1. amulet1
    self-assigned this
    on Mar 5, 2026

  2. amulet1 commented on Mar 5, 2026

    @amulet1
    amulet1
    on Mar 5, 2026
    Member

    There are few things we need to make it happen:

    • Some simple V3 on/off switch to make it easy to test things and revert back easily if the issue is detected. Possibly some temporary config parameter. Any suggestions? Once we agree on the "switch", just a few changes will be needed to use V3 classes automatically (with a few exceptions).
    • Embed code from VarRenderer classes into V3 classes (does not delay transition to V3 classes)
    • Update interfaces, improve code
    • Tests

  3. amulet1 commented on Mar 5, 2026

    @amulet1
    amulet1
    on Mar 5, 2026
    Member

    @ralflang Please advise on the "V3 on/off switch".

  4. ralflang commented on Mar 6, 2026

    @ralflang
    ralflang
    on Mar 6, 2026
    MemberAuthor

    I think we need a form switch either at application level or at horde-wide level.

  5. amulet1 commented on Mar 6, 2026

    @amulet1
    amulet1
    on Mar 6, 2026
    Member

    Maybe a global setting "Use experimental V3 Form classes"?

    And possibly another checkbox to "Allow users to override" (and then a corresponding user preference). This way it can be tested in multi-user environment, and could be easily enabled/disabled globally or only for specific users.

  6. ralflang
    added 12 commits that reference this issue on Mar 7, 2026

    feat(v3): implement BaseForm with PSR-7 support and multi-type input

    29315cc

    feat(v3): implement Action system with 5 core actions

    4f6d449

    feat(v3): add renderer system interfaces and design

    f548d47

    feat(v3): implement HTML renderer system

    be2cb18

    test(v3): add comprehensive V3 test suite

    d9fb6fe

    test(v3): add comprehensive CRUD form integration test

    c47cd6a

    feat(v3): implement BaseForm with PSR-7 support and multi-type input

    1a7a35a

    feat(v3): implement Action system with 5 core actions

    8c2caa9

    feat(v3): add renderer system interfaces and design

    7a9391a

    feat(v3): implement HTML renderer system

    9d4ad74

    test(v3): add comprehensive V3 test suite

    36b8973

    test(v3): add comprehensive CRUD form integration test

    55bd548

  7. ralflang commented on Apr 20, 2026

    @ralflang
    ralflang
    on Apr 20, 2026
    MemberAuthor

    I think we should support incremental upgrades as you propose. We may have some details to hammer, see your #24
    In practice, I think the more mature apps will have the transition to Horde/Form V3 bundled with other architectural changes and offering a feature switch to support both conservative and early adopter users makes sense. For more niche apps like whups I think we should just dash ahead with V3 and learn some lessons from what goes wrong along the way. At least as long as we are in beta.

  8. ralflang commented on May 23, 2026

    @ralflang
    ralflang
    on May 23, 2026
    MemberAuthor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions