bertrand Gugger [2006-03-24 13:32 UTC] As you know, I can only subscribe to this package.
Input can be in almost all cases defined very shortly.
We always encounter situations where this input may come from various sources.
I believe your proposal is linked to the first one I made in pear but deleted , this Console_Extend.
No idea about Gtk , never wanted to have some about QF.
Needing some universal , simple input.
Comments about code in the next :)
Justin Patrin [2006-03-24 16:25 UTC] Exceptions thrown should be extended from PEAR_Exception (Structures_Form_Exception and possibly sub-classes to classify types of exceptions, although codes are also good for this). This, of course, means you'll have to move the require_once of PEAR/Exception.php to the top of your code. ;-)
I'm also a bit disappointed with the separation of Structures_Form and the GTK2 components and I don't really like that the elements "can't" be extended from a base class. This is going to cause a lot of extra duplicated code when it comes to elements. I understand the need for this with GTK2, but it's causing duplicate code in a few ways.
First of all, the elements should be independant of the rendering structure so that you can add types of elements to the form without deciding on a renderer. This would allow the same form object to render in many formats. In addition, this will pull the common code needed for dealing with elements into these classes, leaving the rendering elements leaner.
I'm aware that this is no easy task as it's something I've been working with for FormBuilder2. However, it's not trying to be a form package, it's just trying to generalize the way that it handles forms...
bertrand Gugger [2006-04-04 06:43 UTC] 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.
|
