I'm looking for help with project. I have written a detailed post about
it.
Please see:
it.
Please see:
-
-
Re: OO Form Framework Seeks Assistance
oliver.saunders @gmail.com wrote:Looks right you are trying to create something like struts-tags or jstl.I'm looking for help with project. I have written a detailed post about
it.
>
Please see:
>
Am I right?
That would be interesting.
-
Re: OO Form Framework Seeks Assistance
oliver.saunders @gmail.com schrieb:I assume you are aware of:I'm looking for help with project. I have written a detailed post about
it.
>
Please see:
>
If you want to add to your page a quick overview, in which aspects your
approach differs from QuickForm, this would be interesting.
--
Markus
Comment
-
Re: OO Form Framework Seeks Assistance
oliver.saunders @gmail.com wrote:
hmmm, interesting. But what makes it different from BlueShoes / PHPPeanuts /I'm looking for help with project. I have written a detailed post about
it.
>
Please see:
http://forums.devnetwork.net/viewtopic.php?t=52753
PfP Studio / Prado?
C.
Comment
-
Re: OO Form Framework Seeks Assistance
oliver.saunders @gmail.com wrote:To be honest, I've yet to find a good forms class that lets me doI'm looking for help with project. I have written a detailed post about
it.
>
Please see:
http://forums.devnetwork.net/viewtopic.php?t=52753
things the way i want without to much hassle.
I've tried to design and plan my own form suite, but there are always a
couple of inherent problems I run into that are always at odds:
1) Presentation. Most forms autogenerate the html and spit it out.
Meanwhile, i have to manually set dozens of attributes for each element
of it to get it to have css classes even resembling something i can
style. The end result is I write just as much code using the API as I
would have writing raw HTML.
1a) Complex Presentations are hard to generate using a simple API. Ex:
your date object. IMO, having 3 fields they fill out is ugly, and it
can actually be faster to write mm/dd/yyyy instead of "type - click -
type -click -type", even better is having a javascript calendar, or
maybe its limited by the year, and you dont' care about the month.
The point is, that one input field can be displayed dozens of ways,
each one requiring some nuances.
1b) Label and input relations. Most forms can be divided up into a
table (not that its the best way, but for ease of explanation, think of
a grid layout). Where do the labels go? How far do they span?
Sometimes a simple [Label | Input] layout isn't conductive or feasible
space wise. Maybe I want the label on the right. Maybe I can't put
the label anywhere *but* the right. Maybe it goes above and spans
multiple rows. Maybe its not really a label, but just a header for
group of inputs. You see the problem? It gets complicated really
easily.
2) Logic: Most form classes have inadequate logic processing rules and
abilities for my tastes or circumstances. Sometimes things depend on
things depend on other things, and then those things need to change
other things or invalidate more things etc etc. the pear QuickForm
isn't so bad, but I can't stand the pear style of coding with the
isError() methods and such. PITA.
3) Tries to tie together too many things. A lot of form things i find
like to mix and match presentation, logic, and data stuff all into one.
All those should be seperate. I should be able to mix and match any
combination of them.
4) Don't use PHP5 abilities. Everything I see still uses masses of
arrays and operations on arrays of data. Objects, people, objects.
They let you do all that but you don't have to pass all that data
around or worry about indices being set or any of the inherent and
frustrating difficulties dealing with arrays. PHP doesn't need to go
creating copies of it all. You can reference that same data from other
places without using & or having to store some sort of key lookup or
implement some sort of trigger to lookup the current value and bla bla.
4a) Exceptions! Yes, I know a logic error in a form isn't the best use
of exceptions, but the concept is what i'm getting at. If there is an
error in a form I want to be able to simply get a value back and be
able to use the error to operate directly on that field. I don't want
to have to look it back up in the form then execute custom code:
foreach($err as $e) { $e->field->setErrText($ e->getMsg()); } See?
Wasn't that easy? I just marked every invalid field with its specific
message.
Its a good start, but don't:
* Combine presentation with business logic.
* Combine data logic with the form. (the form does database
update/delete, etc)
* Force a specific presentation. (new Input("Label", "name") always
displays the same)
* Limit validation abilities
</rant>
Comment
-
Re: OO Form Framework Seeks Assistance
Richard Levasseur wrote:People have tried and tried. The approach is fundamentally flawed. A>
To be honest, I've yet to find a good forms class that lets me do
things the way i want without to much hassle.
solution that's highly structural in nature simply will not work for a
problem that isn't.
Too often people equates "structured " with "superior" in programming. I
don't know if it's a prejudice they instill into students in CS. My own
education was in human languages. To me it's obvious that a language is
far a far more powerful and flexible tool than a class library. HTML is
very good at what it does, that is, describing the appearance of a web
page. PHP is also very good at what it does, gluing various
functionalities together. I don't understand why people keep insisting
on having a structural framework when the structure has questionable
benefits and imposes constraints.
/rant off
Comment
-
Re: OO Form Framework Seeks Assistance
Chung Leong wrote:
You put it better than I could. Terry Pratchett had a creature in one ofRichard Levasseur wrote:>>>
>To be honest, I've yet to find a good forms class that lets me do
>things the way i want without to much hassle.
People have tried and tried. The approach is fundamentally flawed. A
solution that's highly structural in nature simply will not work for a
problem that isn't.
his books called a "drome". It could catch you by trapping you in a waking
dream. In the dream there would be much food, which you would eat and eat
and eat while starving to death because of course it was just a dream.
Then the drome ate you after you died.
Object-oriented forms frameworks appear to me to be the drome. They catch
you with a dream and you starve to death (lost productivity and billing)
eating the imaginary food (silver bullet of perfect programs).
All this being said, there is much value in having library routines that
handle repetitive tasks or make your code more readable. We have found
that simple routines like "hSpan($content )" make code readable, while
comprehensive routines like "hInputsFromTab le($table_id)" that create a
complete set of form inputs are also very useful. But structuring it all
into a nested hierarchy of objects just adds more labor with no payoff.
Ken's $.02.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )
Comment
-
Re: OO Form Framework Seeks Assistance
Kenneth Downs wrote:It's easy to show an OO architecture in a diagram. That's where I thinkObject-oriented forms frameworks appear to me to be the drome. They catch
you with a dream and you starve to death (lost productivity and billing)
eating the imaginary food (silver bullet of perfect programs).
people make a mental mistake. A good way to visually present
information is not necessarily a good way to create that information in
the first place. In fact, the opposite is likely to be true. It's hard
to fit a system of interacting parts into a pre-defined structure when
the rules governing the interactions are independent of those governing
the structure.
The recent fad with design pattern is another case of failing to see
the asymmetry between observation and creation. The fact that you can
identify patterns within a complex system does not mean you can
recreate a similiarly complex system using those patterns. The patterns
might give you some insights into the original system, but they are not
good starting points for a new one.
You're of course, not obliged to use those routines when they won'tAll this being said, there is much value in having library routines that
handle repetitive tasks or make your code more readable. We have found
that simple routines like "hSpan($content )" make code readable, while
comprehensive routines like "hInputsFromTab le($table_id)" that create a
complete set of form inputs are also very useful. But structuring it all
into a nested hierarchy of objects just adds more labor with no payoff.
work in a particular situation. They're like contractions we use when
we talk. We say "google" this and "google" that when the word actually
signifies a number of different actions: opening a web browser, typing
in www.google.com, etc. "To google" is a higher level function than "to
type", which in turn is a higher level function than "to press," so
there is a sort of hierarchy. We don't need to pay attention to it
however.
Comment
-
Re: OO Form Framework Seeks Assistance
Chung Leong wrote:Kenneth Downs wrote:>Object-oriented forms frameworks appear to me to be the drome. They catch
you with a dream and you starve to death (lost productivity and billing)
eating the imaginary food (silver bullet of perfect programs).
It's easy to show an OO architecture in a diagram. That's where I think
people make a mental mistake. A good way to visually present
information is not necessarily a good way to create that information in
the first place. In fact, the opposite is likely to be true. It's hard
to fit a system of interacting parts into a pre-defined structure when
the rules governing the interactions are independent of those governing
the structure.
>
The recent fad with design pattern is another case of failing to see
the asymmetry between observation and creation. The fact that you can
identify patterns within a complex system does not mean you can
recreate a similiarly complex system using those patterns. The patterns
might give you some insights into the original system, but they are not
good starting points for a new one.
>>All this being said, there is much value in having library routines that
handle repetitive tasks or make your code more readable. We have found
that simple routines like "hSpan($content )" make code readable, while
comprehensive routines like "hInputsFromTab le($table_id)" that create a
complete set of form inputs are also very useful. But structuring it all
into a nested hierarchy of objects just adds more labor with no payoff.
You're of course, not obliged to use those routines when they won't
work in a particular situation. They're like contractions we use when
we talk. We say "google" this and "google" that when the word actually
signifies a number of different actions: opening a web browser, typing
in www.google.com, etc. "To google" is a higher level function than "to
type", which in turn is a higher level function than "to press," so
there is a sort of hierarchy. We don't need to pay attention to it
however.
$form = new Form(new GridBagLayout() );
<....500 lines ...>
$form->output();
I guess thats the *other* option ;)
Comment
-
Re: OO Form Framework Seeks Assistance
Richard Levasseur wrote:A theory of mine is that every programmer at some point of their career>
$form = new Form(new GridBagLayout() );
<....500 lines ...>
$form->output();
>
I guess thats the *other* option ;)
has written a HTML widget class library. I know I have :-)
Comment
-
Re: OO Form Framework Seeks Assistance
Chung Leong wrote:
....before or after the database report writer?Richard Levasseur wrote:>>>
>$form = new Form(new GridBagLayout() );
><....500 lines ...>
>$form->output();
>>
>I guess thats the *other* option ;)
A theory of mine is that every programmer at some point of their career
has written a HTML widget class library. I know I have :-)
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )
Comment
-
Re: OO Form Framework Seeks Assistance
Kenneth Downs wrote:After the widgets, but before the template library.Chung Leong wrote:
>>Richard Levasseur wrote:A theory of mine is that every programmer at some point of their career>
$form = new Form(new GridBagLayout() );
<....500 lines ...>
$form->output();
>
I guess thats the *other* option ;)
has written a HTML widget class library. I know I have :-)
...before or after the database report writer?
On another note, why the HELL doesn't php have built in HTML widgets
for the most basic things? You would think after 5 years of
development they'd have the smart idea to create a ComboBox class that
didn't suck.
Comment
Comment