[PEPr] Comment on Structures::Structures_Form
| From: | bertrand Gugger | Date: | Tue, 04 Apr 2006 06:43:15 +0000 |
| Subject: | [PEPr] Comment on Structures::Structures_Form | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-42066@lists.php.net to get a copy of this message | ||
bertrand Gugger (http://pear.php.net/user/toggg) has commented on the proposal for
Structures::Structures_Form.
Comment:
It's lot of work ! A very large API.
Unfortunately, the requirements prohibit some test on the machines I own
(must upgrade :) ).
Anyway, I have the feeling it should be possible to implement easily a
versatile interface for simple forms with it , at least with Gtk2 and QF.
I'm more dubious about a raw text CLI one ... but not impossible,
certainly.
I think it allows the major part of the form to be defined commonly, just
a very few basic steps will have to be separated in the userland. (the
interface detection or some "post" operations as the main loop
Gtk::main())
Some little things:
* first release should only be 0.1.0 , proposals should use 0.0.x
* you define constants for the pathes, I'm not sure it's usefull, anyway,
you should use them consistently and not alternatively with the string as
in registerElementSet()
* I dislike the implementers file structure, I fear it will be confusing
to have e.g. all Gtk2 and QF elements mixed under Form/Element/ , it would
be cleaner to make some Form/Element/Gtk2/ and Form/Element/QF/ subfolders.
Same for Group and Renderer. That instead of prefixing the script names
with Gtk2... or QF...
* Does not QF allows array elements ?
More generally, are the interfaces complete enough to get a maximal
compatibility with QF ? I unfortunately dont know it enough to answer that
myself.
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=377
--
Sent by PEPr, the automatic proposal system at http://pear.php.net