[PHP] Re: table-less layouts; Ideas welcome
On 21/05/2009 10.02, Jim Lucas wrote: Since this has been a topic of dicussion, I figured I would add my thoughts. I have been toying with the idea of doing a table-less layouts involving tabular data, calendars, etc... Recent threads have finally made me do it. Let me know what you think. http://www.cmsws.com/examples/templates/div_tables.php http://www.cmsws.com/examples/templates/div_tables.phps (source for above) http://www.cmsws.com/examples/templates/div_cal.php When you turn off the styles, the calendar becomes pretty rough on the eyes, but still accessible. Same thing with the tabular data structure. But, not knowing how the various types of accessibility applications work, I am guessing that the layout to an application trying to read it should work fairly well. Let me know if I am way off the mark with my thoughts. If you want to respond off list, that if fine by me. TIA Table-less html is a silly idea. Semantic html where tables represent tables makes sense instead. A calendar IS a table, semantically speaking, so emulating it with css-p is useless torture. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Forms validation and creation- easier solution?
On 20/05/2009 9.03, Angelo Zanetti wrote:
Hi all.
We have done quite a few projects and we are looking to find better ways to
implementing forms.
Forms seem to be quite time consuming and repetitive.
Generally are there any classes or libraries that will assist with:
1. Easy creation of forms (fields and layout)
2. Validation of specific fields within the forms (server side not JS)
3. Decrease in time required to setup the forms pages
any other comments are welcome.
Thanks in advance
Angelo
Elemental
http://www.elemental.co.zahttp://www.elemental.co.za/
Dynamic Web and Mobile Solutions
Personally I created a little Class that handles it.
First I create an array of associative arrays, every associative array
represents an input of an abstract type (similar to the webforms,
meaning i have stuff like type=telephone).
Stuff like
$inputs[]=array(
name = foobar,
required = true,
type = string, // text is reserved to textarea
label = Foo Bar,
error_required = you need to provide a Foo Bar value, dummy,
group = main
);
etc.
Then I create an array for groups.
$group[main] = array(
type = block, // types are either block which means div, set
which means fieldset, paragraph which means p or a raw html opening tag.
parent = NULL //optional of course, if set to the name of another
group, then the group becomes a child of the referenced group.
)
Then I create an associative array of options for the form.
Finally, I call the class constructor with the three arrays as params.
The class provides me with a few nifty functions:
* toHtml();
(do I need to explain?)
* toArray();
Returns the inputs, options, and groups inside a single array, with the
value altered when necessary
* wasSubmitted();
Does some guesswork to see if the form was submitted, there's a lot of
smart automagicness inside.
* runAutoChecks();
Runs the checks he can, like the validity of emails in 'type' = 'email'
inputs, pattern validation for input with a set pattern, required
inputs, fills the error array with error messages, sets class[]='error'
to wrongly filled inputs...
* wasValidInput();
Returns true if none of the autochecks or eventual manual checks
returned an error.
And it works like this:
[...]
if ($form-wasSubmitted()){
$form-runAutoChecks();
/* Additional non-automatable controls */
// None in this case
if ($form-wasValidInput()){
// success, do stuff
} else {
// show errors and form again
}
} else {
echo $form-toHtml();
}
There are other things I didn't list, like the fact that ever input has
options to specify a wrapper (class and id are associated to the wrapper
if it's defined), the form encoding automatically changes in case of a
file input, etc etc etc...
The types are abstracted enough that one could easily make a function
that automatically creates the code for a first draft of the forum out
of the db schema of an eventual table. Of course you'd have to provide
error messages, remove unnecessary inputs, adding new ones...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Parsing of forms
On 20/05/2009 2.45, Nathan Rixham wrote:
Daniele Grillenzoni wrote:
On 19/05/2009 18.09, Andrew Ballard wrote:
On Tue, May 19, 2009 at 10:11 AM, Ford, Mikem.f...@leedsmet.ac.uk
wrote:
On 19 May 2009 14:37, Daniele Grillenzoni advised:
My complaint is this: a I can have a select multiple with a
normal name,
which is allowed by every spec, but PHP requires me to use []
in order
to properly retrieve the values.
I really don't understand the problem with this -- in fact, I find it
quite useful to distinguish inputs which may have only 1 value from
those which may be multi-valued. And it all depends on what you mean by
a normal name, of course -- no current (X)HTML spec disallows [] as
part of a name attribute, so in that sense a name containing them could
be seen as perfectly normal...!! ;) ;)
Can you explain why this is such a hang-up for you, as I haven't seen
anything in what you've posted so far to convince me it's any kind of
problem?
Cheers!
Mike
I can't speak for the OP, but I've always thought it somewhat odd. An
HTML form should be able to work correctly without modification
regardless of the language that receives the input. As it is, it makes
the HTML for a form implementation specific. You might be able to use
ASP correctly process a form originally targeted toward PHP, but you
could not similarly take a form designed for ASP and process it with
PHP without modification.
It also impacts the use of client-side JavaScript. Consider a simple
page like this:
sundae.html
==
html
head
script
function countToppings() {
var totalToppings = 0;
var toppings = document.sundae.toppings;
// To work with PHP, the above line would have to be changed:
// var toppings = document.sundae.elements['toppings[]'];
if (toppings.length 1) {
for (var i = 0; i toppings.length; i++) {
if (toppings[i].checked) totalToppings++;
}
} else {
if (toppings.checked) totalToppings++
}
if (totalToppings == 0) {
confirm(Are you sure you don't want any toppings on your sundae?);
} else if (totalToppings 3) {
alert(Wow! That's a lot of toppings!);
} else if (totalToppings == 1) {
alert(You only want one topping.);
} else {
alert(You have selected + totalToppings + toppings! Yummy!);
}
}
/script
/head
body
form name=sundae
div
fieldset
legendToppings/legend
input type=checkbox id=toppings-sprinkles name=toppings
value=sprinkles/ label
for=toppings-sprinklessprinkles/labelbr/
input type=checkbox id=toppings-nuts name=toppings
value=nuts/ label for=toppings-nutsnuts/labelbr/
input type=checkbox id=toppings-fudge name=toppings
value=fudge/ label for=toppings-fudgefudge/labelbr/
input type=checkbox id=toppings-caramel name=toppings
value=caramel/ label for=toppings-caramelcaramel/labelbr/
input type=checkbox id=toppings-strawberries name=toppings
value=strawberries/ label
for=toppings-strawberriesstrawberries/labelbr/
/fieldset
input type=button name=count value=Count My Toppings
onclick=countToppings()/
input type=submit name=order value=Order /
/div
/form
/body
/html
The above form, if submitted, could build a perfectly valid query
string of
?toppings=sprinklestoppings=nutstoppings=fudgetoppings=carameltoppings=strawberries.
In the grand scheme of things, these are just subtleties that can
easily be handled. Since my first major experience with a web language
was PHP (after a very brief dabble in PERL) before I took a turn at
ASP/VBScript, I'm used to it and it isn't a hang-up for me. But
something about it never seemed quite right to me either. :-)
Andrew
Andrew captured perfectly what I meant.
?toppings=sprinklestoppings=nutstoppings=fudgetoppings=carameltoppings=strawberries
is a valid querystring that php sort of fail at understanding.
I have nothing against supplying a string/array clarification system
based on the name with/without the square brackets, but short of
manually parsing the querystring/request headers, I have no
alternative to that.
Also my original problem came when I had to parse the results of a
form I did NOT originally create, not to mention forms from external
sources...
I don't hate PHP and I don't want to throw off people who like the []
system, just give me an alternative with a small overhead. :P
quick work around :) (could be improved)
?php
function fixGet() {
$newGet = array();
foreach($vals=explode('',$_SERVER['QUERY_STRING']) as $i = $pair ) {
$pair = explode( '=' , $pair , 2 );
if( !isset( $newGet[$pair[0]] ) ) {
$newGet[$pair[0]] = $pair[1];
} else {
if( !is_array($newGet[$pair[0]]) ) {
$newGet[$pair[0]] = array( $newGet[$pair[0]] );
}
$newGet[$pair[0]][] = $pair[1];
}
}
$_GET = $newGet;
}
print_r( $_GET );
fixGet();
print_r( $_GET );
?
outputs:
Array
(
[toppings] = caramel
[order] = Order
)
Array
(
[toppings] = Array
(
[0] = nuts
[1] = fudge
[2] = caramel
)
[order] = Order
)
Yeah, and php://input should be able to handle $_POST, but custom
functions ftl, the idea of having useless overhead for simple stuff like
this makes me angry.
--
PHP General
Re: [PHP] Re: Parsing of forms
On 20/05/2009 12.50, Ford, Mike wrote: Humph! Yes, ok, I concede this point. I also bow to Daniele's need to process forms designed by someone else with (not-PHP) in mind. Actually, I can see the validity of both sides of the argument, and I teeter on the fence as to whether the [] method is right or not!! ;) Teeter not, as I am not pushing for a retool of how $_POST and $_GET work, just maybe a new core function/global array that gets me the pure alternative. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Parsing of forms
On 19/05/2009 18.09, Andrew Ballard wrote:
On Tue, May 19, 2009 at 10:11 AM, Ford, Mikem.f...@leedsmet.ac.uk wrote:
On 19 May 2009 14:37, Daniele Grillenzoni advised:
My complaint is this: a I can have a select multiple with a
normal name,
which is allowed by every spec, but PHP requires me to use []
in order
to properly retrieve the values.
I really don't understand the problem with this -- in fact, I find it
quite useful to distinguish inputs which may have only 1 value from
those which may be multi-valued. And it all depends on what you mean by
a normal name, of course -- no current (X)HTML spec disallows [] as
part of a name attribute, so in that sense a name containing them could
be seen as perfectly normal...!! ;) ;)
Can you explain why this is such a hang-up for you, as I haven't seen
anything in what you've posted so far to convince me it's any kind of
problem?
Cheers!
Mike
I can't speak for the OP, but I've always thought it somewhat odd. An
HTML form should be able to work correctly without modification
regardless of the language that receives the input. As it is, it makes
the HTML for a form implementation specific. You might be able to use
ASP correctly process a form originally targeted toward PHP, but you
could not similarly take a form designed for ASP and process it with
PHP without modification.
It also impacts the use of client-side JavaScript. Consider a simple
page like this:
sundae.html
==
html
head
script
function countToppings() {
var totalToppings = 0;
var toppings = document.sundae.toppings;
// To work with PHP, the above line would have to be changed:
// var toppings = document.sundae.elements['toppings[]'];
if (toppings.length 1) {
for (var i = 0; i toppings.length; i++) {
if (toppings[i].checked) totalToppings++;
}
} else {
if (toppings.checked) totalToppings++
}
if (totalToppings == 0) {
confirm(Are you sure you don't want any toppings on your
sundae?);
} else if (totalToppings 3) {
alert(Wow! That's a lot of toppings!);
} else if (totalToppings == 1) {
alert(You only want one topping.);
} else {
alert(You have selected + totalToppings + toppings!
Yummy!);
}
}
/script
/head
body
form name=sundae
div
fieldset
legendToppings/legend
input type=checkbox id=toppings-sprinkles name=toppings
value=sprinkles/ label
for=toppings-sprinklessprinkles/labelbr/
input type=checkbox id=toppings-nuts name=toppings
value=nuts/ label for=toppings-nutsnuts/labelbr/
input type=checkbox id=toppings-fudge name=toppings
value=fudge/ label for=toppings-fudgefudge/labelbr/
input type=checkbox id=toppings-caramel name=toppings
value=caramel/ label for=toppings-caramelcaramel/labelbr/
input type=checkbox id=toppings-strawberries name=toppings
value=strawberries/ label
for=toppings-strawberriesstrawberries/labelbr/
/fieldset
input type=button name=count value=Count My Toppings
onclick=countToppings()/
input type=submit name=order value=Order /
/div
/form
/body
/html
The above form, if submitted, could build a perfectly valid query
string of
?toppings=sprinklestoppings=nutstoppings=fudgetoppings=carameltoppings=strawberries.
In the grand scheme of things, these are just subtleties that can
easily be handled. Since my first major experience with a web language
was PHP (after a very brief dabble in PERL) before I took a turn at
ASP/VBScript, I'm used to it and it isn't a hang-up for me. But
something about it never seemed quite right to me either. :-)
Andrew
Andrew captured perfectly what I meant.
?toppings=sprinklestoppings=nutstoppings=fudgetoppings=carameltoppings=strawberries
is a valid querystring that php sort of fail at understanding.
I have nothing against supplying a string/array clarification system
based on the name with/without the square brackets, but short of
manually parsing the querystring/request headers, I have no alternative
to that.
Also my original problem came when I had to parse the results of a form
I did NOT originally create, not to mention forms from external sources...
I don't hate PHP and I don't want to throw off people who like the []
system, just give me an alternative with a small overhead. :P
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: CSS tables
On 17/05/2009 20.51, tedd wrote: At 8:08 PM +0200 5/15/09, Daniele Grillenzoni wrote: Most of the IE bugs are due to floating and clearing, once you have learned to master overflow: auto and display: inline, you're good to go. Just don't get insane about trying to achieve pixel perfect in netscape4. Good to go -- only for simple sites. And for pixel perfect, no browser does that. Here's my write-up on the subject: http://sperling.com/four-things-clients-should-know.php Comments welcome. Cheers, tedd Re-read my sentence: most of the IE bugs as opposed to all IE bugs Also: 404. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: CSS tables
On 15/05/2009 19.25, PJ wrote: I know of no better place to ask. This may not be strictly a PHP issue, but... I am busting my hump trying to format rather large input pages with CSS and trying to avoid tables; but it looks to me like I am wasting my time as positioning with CSS seems an impossibly tortuous exercise. I've managed to do some pages with CSS, but I feel like I am shooting myself in the foot or somewhere... Perhaps I am too demanding. I know that with tables, the formatting is ridiculously fast. Any thoughts, observations or recommendations? A table, meaning ONE table for tough layouts could solve many problems, specially for newbies, but tbh there are enough resources to do pretty much whatever you need to do with css if the layout doesn't have absurd constraints. Most of the IE bugs are due to floating and clearing, once you have learned to master overflow: auto and display: inline, you're good to go. Just don't get insane about trying to achieve pixel perfect in netscape4. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Parsing of forms
I noticed that php's way to fill $_GET and $_POST is particularly inefficient when it comes to handling multiple inputs with the same name. This basically mean that every select multiple in order to function properly needs to have a name ending in '[]'. Wouldn't it be easier to also make it so that any element that has more than one value gets added to the GET/POST array as an array of strings instead of a string with the last value? I can see the comfort of having the brackets system to create groups of inputs easily recognizable as such, while I can overlook the impossibility of having an input literally named 'foobar[]', having to add [] everytime there is a slight chance of two inputs with the same name. This sounds flawed to me, as I could easily append '[]' to every input name and have a huge range of possibilities unlocked by that. This can't be right. Or can it? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Parsing of forms
I noticed that php's way to fill $_GET and $_POST is particularly inefficient when it comes to handling multiple inputs with the same name. This basically mean that every select multiple in order to function properly needs to have a name ending in '[]'. Wouldn't it be easier to also make it so that any element that has more than one value gets added to the GET/POST array as an array of strings instead of a string with the last value? I can see the comfort of having the brackets system to create groups of inputs easily recognizable as such, while I can overlook the impossibility of having an input literally named 'foobar[]', having to add [] everytime there is a slight chance of two inputs with the same name. This sounds flawed to me, as I could easily append '[]' to every input name and have a huge range of possibilities unlocked by that. This can't be right. Or can it? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Error handling, apache and ErrorDocument
Hi, I'm having trouble with a framework I'm developing, apparently when a non-catchable error occurs (E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING types) not only I can't fire up my error handling function, I can't even display the static html page I set with the ErrorDocument apache directive. What's weird is that it doesn't look like an apache problem, with perl it works perfectly. This guy had the same problem as me, check his post (point 3 mostly): http://www.entropy.ch/blog/Developer/2007/05/10/Apache-ErrorDocument-PHP-header-interaction.html Thanks in advance Daniele Grillenzoni -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
