Proposal for Structures::Structures_Form

Scott Mattocks (http://pear.ph
p.net/user/scottmattocks) proposes
Structures::Structures_Form.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=377

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Scott Mattocks (http://pear.ph
p.net/user/scottmattocks) has edited the proposal for
Structures::Structures_Form.

Change comment:

Bug fix in getGroups().
Search through groups when element is not found in
getElement().

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=377

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

bertrand Gugger (http://pear.php.net/us
er/toggg) has commented on the proposal for
Structures::Structures_Form.

Comment:

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 

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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Justin Patrin (http://pear.php
.net/user/justinpatrin) has commented on the proposal
for Structures::Structures_Form.

Comment:

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...

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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Justin Patrin wrote:
> Comment:
> 
> 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. 

OK. I'll work on that.

> 
> 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.

This only causes duplicate code if you want it to. If you
wanted to 
create an HTML frontend package, where the elements can
extend from a 
base class, just create a base class and have it implement
the needed 
interfaces. You code is implemented in one place and the
rest of your 
elements gain that functionality by extending your base
class.

With PHP-GTK 2, the repeated code is necessary to allow the
elements to 
be cleaner. Repeating a few methods is better than having to
create new 
methods that just call the GtkWidget methods. I know __call
could be 
used for this but I don't think that is a clean solution
either.

> 
> 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.

The elements are independent of the rendering. The Gtk2
elements could 
easily be used with an HTML renderer or a CLI renderer. The
only problem 
is trying to use non-Gtk2 elements with a Gtk2 renderer
because the 
renderer needs the elements to extend GtkWidget. Actually
passing 
non-Gtk2 elements to the Gtk2 renderer will not really cause
much of a 
problem aside from the elements not being displayed. Their
values will 
still be submitted when the form is submitted.

If you create a form and then want to render it will
HTMLRendererA 
and/or HTMLRendererB and/or CLIRenderer it should work fine.
The 
renderer is ultimately responsible for deciding how the
elements are 
displayed. Of course the elements can help out, but the
renderer should 
be able to get all of the information it needs to display
the elements 
how ever it wants.

I am planning to add a method that will translate from one
element set 
to another. This would allow a renderer to force the
elements into a set 
that it likes. With this method, there could be a very
simple element 
set that only manages the data. Then the elements could be
translated to 
some other element set as needed by the renderer or just at
the 
developers discretion.

> 
> 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...

If you have any more insight please let me know. I'd love
help with 
this. My problem is that I am only using the package for
PHP-GTK 2 forms 
at the moment so I may not be seeing all of the little
things that will 
cause issues with other formats.

> 
> Proposal information:
> http://pear.php.net/pepr/pepr-proposal-show.php?id=377
> 

-- 
Scott Mattocks
Author of the soon to be published: Pro PHP-GTK
http://www.crisscott.com

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Scott Mattocks (http://pear.ph
p.net/user/scottmattocks) has edited the proposal for
Structures::Structures_Form.

Change comment:

Added Structures_Form_Exception class.
Added swapElementSet method to easily change from one
frontend to another.

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=377

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Scott Mattocks (http://pear.ph
p.net/user/scottmattocks) has edited the proposal for
Structures::Structures_Form.

Change comment:

Fix Structures_Form_Exception class name typo.
Make Required rule report element label not name.

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=377

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hello,

I would like to hear more comments/suggestions for
Structures_Form and 
Structures_Form_Gtk2. I am looking for comments about the
concept, 
coding, class structure or anything else.

If you have a minute to spare please take a look at these
two proposals:
Structures_Form: http://pear.php.net/pepr/pepr-proposal-show.php?id=377
Structures_Form_Gtk2: http://pear.php.net/pepr/pepr-proposal-show.php?id=379

Thanks,
Scott Mattocks

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

bertrand Gugger (http://pear.php.net/us
er/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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Scott,

> I would like to hear more comments/suggestions for
Structures_Form and
> Structures_Form_Gtk2.
It looks good.

Just a note:
"Unfreezes the element so that its value may not be
changed." in the
Gtk2Text.php isn't the correct description.

Gtk2_FileSelect:
> It is highly unlikely that a user really wants to clear
the value of a
> button. Therefore, this method has been deactivated. It
will always
> return true. If the user really wants to clear the
value, they can
> pass null to setValue()
That isn't correct - set_value returns false if the dir
doesn't exist,
and NULL doesn't exist as file. Btw, does setting the dir
to "/" work on
windows?

Gtk2Date.php:
It would be nice to have a constructor parameter that
determines how
months are displayed. Not all people may want to have the
month name
displayed.
And it's currently not possible to change the year span
displayed for
selection.


Too bad that php doesn't allow multiple inheritance - it
would have
saved lots of repeated setLabel/getLabel/... methods.
-- 
Regards/MfG,
Christian Weiske