[dev] Horde Forms

Michael J Rubinsky mrubinsk at horde.org
Wed Oct 26 13:34:18 UTC 2016 

Quoting Sebastian Birnbach <birnbacs at gmail.com>:

> Michael,
>
>
> 2016-10-21 18:23 GMT+02:00 Michael J Rubinsky <mrubinsk at horde.org>:
>
>>
>> Quoting Sebastian Birnbach <birnbacs at gmail.com>:
>>
>> I have a couple of problems with Horde Forms, maybe someone can shed some
>>> light on this:
>>>
>>> * is it possible to use the same field in different sections?
>>> Cross-updating does not work and saving the parameter is only possible
>>> when
>>> the right section is open.
>>>
>>
>> You might be able to do this using an "Action", though it's been so long
>> since I've used Horde_Form in depth, not sure off hand.
>>
> I resolved to have the field editable only in one section, that seems a
> good decision from a UI perspective, too.
>
>
>>
>>
>> * about 1/4 of the form elements do not seem to work as specified. What is
>>> the development status?
>>>
>>
>> Well, most of the code is from years and years ago, but it has been
>> updated as we moved to Horde 4, and Horde 5. The library no doubt needs a
>> major overhaul though.
>>
>
> I see you guys are working really hard on the major features and you are
> sure doing a great job. However, to me the choice for Horde came primarily
> because of the opportunity to add my own application and have it
> interoperate with existing ones.
>
> In this, however, Horde does not quite seem to be as good as it could. IMO
> Horde could become much more attractive if the platform for creating more
> applications was better defined, better maintained and better documented.
> This way Horde would sure attract more programmers and give the whole
> project more momentum.
>
> Among the problems I had with Horde were these:
> * general documentation is ragged and spread over different places

Agreed.

> * information is occasionally stale or plainly outdated

Agreed, depending on where you look.

> * (some) Horde mechanisms not well documented for programmers

Agreed.

> * way too few how-tos, code examples, cookbook stuff etc.
> * it is hard to determine he recommended practices. E. g. use View, Forms
> or Templates? Views are recommended, Forms may be deprecated any time,
> Templates seem to never got quite done

Horde_View is the future for general use. Horde_Form and  
Horde_Template are legacy libraries from Horde 3 days. Horde_Form is  
still very functional and a good choice in certain situations, though  
for more complicated forms (or Ajax-y apps) it makes sense to render  
the form "by hand".

> * API documentation is often incomplete/incorrect

dev.horde.org is rebuilt daily, directly from the phpdoc in the code.

> * not all library components seem to be tested

We have unit tests for most of our libraries and they are  
automatically run on every commit. Agreed the code coverage isn't  
100%, but it's still fairly high.

> When I tried to make friends with Whups I set up a configuration that used
> every form element there was. It took me about a week to realise that those
> ~20% that did not work had nothing to do with my installation. Same thing
> with HordeFormTypes: tried to use each element there was and understand
> each its functionality. Took me a lot of time again to figure out which of
> them I could use and which not.
>
> I am sure willing to contribute but due to lack of time my possibilities
> are very modest.

Well, this is of course a major cause of most of the documentation  
issues you raise. Of course we want better documentation, but we, too,  
have VERY limited resources. The documentation problem is unlikely to  
improve in the foreseeable future unless someone else steps up and  
donates the time to help. We simply have too many, more pressing,  
responsibilities - both in the project and out.


> I am working on one comprehensive Horde_Form that uses all
> known elements in order to pinpoint where something is wrong. If you are
> willing to try and reproduce the problems I find maybe we can find out
> where there is a bug and where my usage is just wrong (and maybe
> documentation should be improved).
>
> Sorry with busting out with all this and hope I didn't tread on anybody's
> feet. I still feel that Horde is a good choice for me. But I also feel that
> the platform could be much much more attractive if external programmers had
> an easier time.

We have worked hard to make our libraries re-usable outside of the  
horde groupware stack. We have made great strides in this since the  
Horde 3 days, when most of the libraries were pretty tightly coupled  
to parts of the "core" code. There is still more we can do, and with  
Horde 6, this will be made even better with independent repositories  
for each component, more use of technology like Composer to make it  
easier for our code to be incorporated with non-Horde projects etc...  
but this takes time, and man power - both of which are in short supply.


>>
>>
>> I'd go and file a bug for each misbehavior unless
>>> somebody tells me that this is normal.
>>>
>>> * example: Horde_Form_Type_date does not work at all.
>>> Horde_Form_Type_monthdayyear does not honor the time format settings:
>>> $myform->addVariable(_("duedate"), 'duedate', 'monthdayyear', true,
>>> false,
>>> '', array(null, null, true, '%Y-%m-%d', '%Y-%m-%d') );
>>>
>>
>> I know we use the date and datetime etc... form types in some of our apps,
>> like Whups. So I know they work. If you have a test case you believe should
>> work, but doesn't, feel free to create a bug report.
>>
>
> It seems to me that Turba uses this element only indirectly, that is, not
> as a Horde_Form_Type:



> grep monthdayyear `find . -type f -name "*.php"`
> ./turba/config/attributes.php: *   - monthyear         - monthdayyear
> ./turba/config/attributes.php: *                     Only valid for
> monthdayyear types and removing this
> ./turba/config/attributes.php: *                     from a monthdayyear
> type will hide it from the
> ./turba/config/attributes.php:    'type' => 'monthdayyear',
> ./turba/config/attributes.php:    'type' => 'monthdayyear',
> ./turba/config/attributes.local.php: *   - monthyear         - monthdayyear
> ./turba/config/attributes.local.php: *                     Only valid for
> monthdayyear types and removing this
> ./turba/config/attributes.local.php: *                     from a
> monthdayyear type will hide it from the
> ./turba/config/attributes.local.php:    'type' => 'monthdayyear',
> ./turba/config/attributes.local.php:    'type' => 'monthdayyear',
> ./turba/lib/Api.php:            if (($attribute['type'] == 'monthdayyear')
> &&
> ./turba/lib/Driver.php:                $attributes[$attribute]['type'] ==
> 'monthdayyear') {
> ./turba/data.php:            case 'monthdayyear':
>
> I shall look into this a little further before I go for a bug report.
>
>
>>
>> * another thing: I'd like to offer a choice of about five colors to pick
>>> from. The colorpicker is clearly overdone for this. Any chance to color
>>> the
>>> fields of a Horde_Form_Type_choices element?
>>>
>>
>> Probably not without hacking the code/creating a new form type. If this is
>> for a custom application, you can create your own form types. IIRC, you can
>> look at Turba's tag type to see how to do this.
>>
>
> I am working on this. I stole and modified
>
> nag/lib/Form/Type/NagTags.php and
> nag/lib/Ui/VarRenderer/Nag.php
>
> Everything seems to make sense, only the file with the renderer class does
> not get read at all. I wonder if I have to register the class or something?
>
>   Sebastian



-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2007 bytes
Desc: S/MIME Signature
URL: <https://lists.horde.org/archives/dev/attachments/20161026/091ea5fc/attachment.bin>

More information about the dev mailing list