[dev] Architecture: Forms, Model Validation, Presentation: Re: brandnew Turba installation throws errors

[Ralf Lang]

Hi Michael,

Am 22.03.19 um 21:27 schrieb Michael J Rubinsky:
>
> Quoting Sebastian Birnbach <birnbacs at gmail.com>:
>
>> I could not find an appropriate setting in php.ini, could you please
>> be a
>> little more specific?
>>
>> [develop at ixie ~]$ php --version
>> PHP 7.2.13 (cli) (built: Jan  1 2019 23:42:23) ( NTS DEBUG )
>> Copyright (c) 1997-2018 The PHP Group
>> Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
>>     with Xdebug v2.6.1, Copyright (c) 2002-2018, by Derick Rethans
>>     with Zend OPcache v7.2.13, Copyright (c) 1999-2018, by Zend
>> Technologies
>>
>>
>> Am Fr., 22. März 2019 um 14:48 Uhr schrieb Ralf Lang
>> <lang at b1-systems.de>:
>>
>>>
>>> Am 22.03.19 um 11:11 schrieb Sebastian Birnbach:
>>> > On a new horde installation with turba I see these errors upon
>>> accessing
>>> a
>>> > demo entry:
>>> >
>>> > Mar 22 11:05:26 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Type_country::init($prompt = NULL) should be compatible
>>> with
>>> > Horde_Form_Type_enum::init($values, $prompt = NULL) [pid 57796 on
>>> line 0
>>> of
>>> > "/usr/local/share/pear/Horde/Form/Type.php"]
>>> > Mar 22 11:05:26 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Turba_Form_AddContact::validate() should be compatible with
>>> > Horde_Form::validate($vars = NULL, $canAutoFill = false) [pid
>>> 57796 on
>>> line
>>> > 5 of "/usr/local/www/horde/turba/lib/Form/AddContact.php"]
>>> > Mar 22 11:05:26 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::getActionScript(&$form, &$renderer,
>>> > $varname) should be compatible with
>>> > Horde_Form_Action::getActionScript($form, $renderer, $varname)
>>> [pid 57796
>>> > on line 0 of
>>> "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:26 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::setValues(&$vars, $sourceVal,
>>> $arrayVal =
>>> > false) should be compatible with Horde_Form_Action::setValues(&$vars,
>>> > $sourceVal, $index = NULL, $arrayVal = false) [pid 57796 on line 0 of
>>> > "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:34 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Type_country::init($prompt = NULL) should be compatible
>>> with
>>> > Horde_Form_Type_enum::init($values, $prompt = NULL) [pid 35165 on
>>> line 0
>>> of
>>> > "/usr/local/share/pear/Horde/Form/Type.php"]
>>> > Mar 22 11:05:34 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Turba_Form_AddContact::validate() should be compatible with
>>> > Horde_Form::validate($vars = NULL, $canAutoFill = false) [pid
>>> 35165 on
>>> line
>>> > 5 of "/usr/local/www/horde/turba/lib/Form/AddContact.php"]
>>> > Mar 22 11:05:34 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::getActionScript(&$form, &$renderer,
>>> > $varname) should be compatible with
>>> > Horde_Form_Action::getActionScript($form, $renderer, $varname)
>>> [pid 35165
>>> > on line 0 of
>>> "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:34 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::setValues(&$vars, $sourceVal,
>>> $arrayVal =
>>> > false) should be compatible with Horde_Form_Action::setValues(&$vars,
>>> > $sourceVal, $index = NULL, $arrayVal = false) [pid 35165 on line 0 of
>>> > "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:35 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Type_country::init($prompt = NULL) should be compatible
>>> with
>>> > Horde_Form_Type_enum::init($values, $prompt = NULL) [pid 35165 on
>>> line 0
>>> of
>>> > "/usr/local/share/pear/Horde/Form/Type.php"]
>>> > Mar 22 11:05:35 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::getActionScript(&$form, &$renderer,
>>> > $varname) should be compatible with
>>> > Horde_Form_Action::getActionScript($form, $renderer, $varname)
>>> [pid 35165
>>> > on line 0 of
>>> "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:35 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Horde_Form_Action_updatefield::setValues(&$vars, $sourceVal,
>>> $arrayVal =
>>> > false) should be compatible with Horde_Form_Action::setValues(&$vars,
>>> > $sourceVal, $index = NULL, $arrayVal = false) [pid 35165 on line 0 of
>>> > "/usr/local/share/pear/Horde/Form/Action/updatefield.php"]
>>> > Mar 22 11:05:35 ixie HORDE: [turba] PHP ERROR: Declaration of
>>> > Turba_Form_EditContact::renderActive($renderer, $vars, $action,
>>> $method)
>>> > should be compatible with Horde_Form::renderActive($renderer = NULL,
>>> $vars
>>> > = NULL, $action = '', $method = 'get', $enctype = NULL, $focus =
>>> true)
>>> [pid
>>> > 35165 on line 0 of
>>> "/usr/local/www/horde/turba/lib/Form/EditContact.php"]
>>> >
>>> >
>>> > I updated the whole installation through
>>> > sudo pear upgrade -a -B -c horde
>>> > but the errors remain.
>>> >
>>> > Looks to me like an incompatibility between turba application and
>>> base
>>> > packages.
>
> Nope. It's because Horde_Form is badly outdated and needs to be
> refactored for PHP 7. Prior to PHP 7 these were E_STRICT warnings..
>
> This should not be affecting functionality though.
>
>
I have an upcoming project soon which will, as a side effect, provide
some reason to patch most horde_form_* signatures to be compatible by
either expanding the base class signatures to optional parameters or
making additional sub class parameters optional,
depending on what seems to be the more reasonable way.

However, I consider Horde_Form fairly legacy and I won't provide a
refactoring, just make it work without throwing errors - and step by
step moving away.
Tightly coupling presentation to validation seems wrong from the current
standpoint.

My team is currently doing something different. We basically decouple UI
as much as possible from the backend, communicating mostly through JSON
messages.

We have modified the rampage.php endpoint so it can cope with

- different scenarios where apps are not below /horde/ but either on
different domain, document root or other hierarchy (used to break nag)
- horde_routes definitions with http verb limits (POST, GET, ...) - We
want this for RESTish ajax.
- TODO: unauthenticated scenarios (can likely be ported from the rest
POC I did a while ago), scenarios authenticated through tokens
(invitation based guest access to horde_share based objects)

We are currently reproducing common horde UI tiles into ReactJs
components (topbar, sidebar, button bar, generic list views)

We use Horde_Controller to deliver a base plate with skeleton html,
initial horde environment, translation strings, path to js/css/service
endpoints as json.
Basically the client page gets bootstrapped with a sort of registry and
is drawn out of javascripts.

If anything needs to be rendered server side, we build a Horde_View
subclass and template html and deliver it through some endpoint.

We have a de-prototyped plain JS client to the horde ajax framework
which acts like HordeCore.doAction but promise-based.

Most json communication is still based on Horde_Ajax_Application* but we
think we might move to Horde_Controller at some point.

The Model part is still a great void. We are heavy on Horde_Rdo and
either use it directly or hide it inside some hand-coded wrappers which
only exposed a defined API rather than directly allow accessing database
properties.
I tried to abstract some backend-agnostic "model" base but it went
nowhere practical. Too convoluted, to complex. I'd now rather extract
some parts into traits for re-use and have

What we basically want to achieve is to make frontend development as
decoupled as possible from the backend, use modern frontend technology,
slowly get rid of prototypeJs-based building blocks. Horde_Forms doesn't
fit well into this pattern.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537