By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,805 Members | 1,273 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,805 IT Pros & Developers. It's quick & easy.

New ideas

P: n/a
I have this idea I've been working on and I have some implementation but
wondering how many of you guys would find it useful. Heres the outline of
how it works.

Essentially one has what are called actions. An action is a block of php
code that is executed after a form as been processed but is defined inline
in the form. The idea is that you insert the actions inline in code but you
can presume that the form has been filled out. Your code, while inline, will
actually be executed after the fact on the next page change(which can be
made to be the same page.
You can see this in action at www.jonslaughter.com/Index.php. Note that All
the code is on the Index page except for a class script that is used for the
cookies and manage the actions.
The main parts are the form and the action handler. The handler executes the
actions after the form has been handled.

If anyone things this thing might be useful then I'm thinking about
rewriting everything and make it a little more clean. What it does allow one
to do is treat forms as inline objects that are not event driven. The
drawback is that the code to handle them must be in a string instead of
actual php code that will be parsed, say, by an IDE. Maybe someone knows of
a way around this or has some idea to make it better(I know there are going
to be the regular nay sayers but who knows).

Again, the main idea is to treat form evaulation as inline instead of on a
seperate page. In this way one encapsulates the function of the form with
the form itself. Its slightly more work but might be worth the effort... and
actually can be less work and ultimately less confusing. Note also that the
action handler is fixed and would just need to be included at the top of
every page.
Thanks,
Jon

<?php

session_start();

require_once($_SERVER['DOCUMENT_ROOT'].'/Scripts/WebLogin.php/');
$login = new WebLogin();
// This code is essentially the actions handler that executes all actions
and in this case sets the cached cookies
if ((!empty($_POST)) & ($login->RunActions()))
{
$url = $_SESSION['URL'];
$login->SetCookies();

session_destroy();
unset($_SESSION);
unset($_COOKIE);

echo '<meta content="0; URL='.$url.'" http-equiv="Refresh" />';
exit();
}
else
{
unset($_SESSION['CALLBACKS']);
unset($_SESSION['ACTIONS']);
unset($_SESSION[$login->cookietable['UserCookieData']]);
}

// Decodes the cookies because they are encrypted when loaded
$login->DecodeCookies();

// Displays the cookies
if (empty($_COOKIE) | !isset($_COOKIE)) { echo "<br />No Cookies<br />\n"; }
else { echo "<br />Displaying Cookies<br />\n"; foreach($_COOKIE as $key =>
$val) { echo "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;".$key." =>
".htmlentities(serialize($val))."<br />\n"; }}

?>


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
</head>
<body>

<form action="" method="post">
<label><?php if (empty($_POST['Cookie_Name'])) { echo '<span
style="color:#FF0000;">*Cookie Name: </span>';} else { echo 'Cookie Name:
';} ?></label><input name="Cookie_Name" value="<?php echo
$_POST["Cookie_Name"]; ?>" type="text" /><br />
<label><?php if (empty($_POST['Name'])) { echo '<span
style="color:#FF0000;">*Name: </span>';} else { echo 'Name: ';}
?></label><input name="Name" value="<?php echo $_POST["Name"]; ?>"
type="text" /><br />
<label><?php if (empty($_POST['Data'])) { echo '<span
style="color:#FF0000;">*Data: </span>';} else { echo 'Data: ';}
?></label><input name="Data" value="<?php echo $_POST["Data"]; ?>"
type="text" /><br />
<input name="FormAction" type="submit" value="Add Cookie">
</form>

<?php

// These handlers just check the forms entries to make sure they are not
empty... if they are then the page is not complete and it should be
re-evaluated...
$login->AddAction('Add Cookie', 'if (empty($_POST["Cookie_Name"])) { return
FALSE; } ');
$login->AddAction('Add Cookie', 'if (empty($_POST["Name"]) |
empty($_POST["Data"])) { return FALSE; } ');

// This adds a cookie with the form data if the actions were all valid and
sets the page to goto... in this case Index.php
$login->AddCookieP('Add Cookie', '$_SESSION["URL"] = "/Index.php/"; return
TRUE;', 'return $_POST["Cookie_Name"];', 'return array("username" =>
$_POST["Name"], "userdata" =$_POST["Data"]);', array('location' ='/'));
?>
<form action="" method="post">
<label><?php if (empty($_POST['Cookie_NameD'])) { echo '<span
style="color:#FF0000;">*Cookie Name: </span>';} else { echo 'Cookie Name:
';} ?></label><input name="Cookie_NameD" value="<?php echo
$_POST["Cookie_NameD"]; ?>" type="text" /><br />
<input name="FormAction" type="submit" value="Delete Cookie">
</form>
<?php
$login->AddAction('Delete Cookie', 'if (empty($_POST["Cookie_NameD"])) {
return FALSE; } ');
$login->DeleteCookieP('Delete Cookie', '$_SESSION["URL"] = "/Index.php/";
return TRUE;', 'return $_POST["Cookie_NameD"];');
?>
</body>
</html>
May 21 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
"Jon Slaughter" <Jo***********@Hotmail.comwrote:
Again, the main idea is to treat form evaulation as inline instead of on a
seperate page. In this way one encapsulates the function of the form with
the form itself. [...]
I agree with you that embedding all the code that handle related WEB pages
(the typical example is handling the loop form display, validation, error
reporting, acquisition of the data) is very powerful, and it can implemented
in several ways. Adding "embedded strings with PHP code" may be a pain,
as you experienced. But things can be improved. Some idea follows.
[ Function bound to an URL ]

Rather than add chunks of code as inline strings and send them as cookies,
you might want to consider to associate every "action" to a PHP function.
That is what i called "programming the WEB application by functions".

Then a single PHP source may contain several functions calling each other
via "actions". For example, this function generates a page with 3 anchors
that, once selected by the user, causes the correspondin function/action
handler to be called; handlers can have also arguments:

function Home()
{
PageHead();
echo "<h1>Wellcome in our beautiful WEB site!</h1>";
echo "Please, select a page:";
Anchor("Page 1", 'Page1');
Anchor("Page 2", 'Page2', 'x', 'the_value_of_x');
Anchor("See the source", 'SeeSource');
PageFoot();
}

where the arguments of the Anchor() function are:

- the text of the anchor (what the user actually will see)
- the name of the PHP function to be called if this anchor get clicked
- the name and value of zero or more arguments to be passed to the function

The example of this solution is availabe on my WEB site along the source
at http://www.icosaedro.it/php/esempio1.cgi, that implements several sample
WEB pages in a single PHP source. This simple program can handle only
GET requests.
[ Handling also the POST method ]

A more refinite example that handle also POST requests is available here:
http://www.icosaedro.it/php/esempio2.cgi
Anchors are handled just as before. Creating a FORM is very simple:

function InputForm()
{
Form();
echo "Write here a string: <INPUT type=text name=s value=\"\">";
Button("Cancel", 'Home');
Button(" OK ", 'InputForm_POST');
Form_();
}

where the arguments of Button() are:

- the text of the button
- the PHP function to call once this button is pressed
- the arguments of the function, if any

So, for example, if the "Cancel" button will be pressed, the function Home()
will be called. The informations about functions and associated arguments are
stored inside hidden fields of the FORM and protected from tampering via HMAC.
[ bt_ ]

An even more refined solution I'm currently using is what i called "bt_
framework". bt_ is suitable for modal applications whose reference model are
the stand-alone applications rather than the WEB, i.e. the user is forced
to follow the path established by the application, and it cannot jump here
and there between the pages because every page is bound to some internal
state of the WEB application.

The HTML code generated by bt_ is very light, since no hidden fields are
required: all the informations that represent the status of the WEB appl.
are stored in the session, so these informations don't go back and forward
between the client and the server.

bt_ implements also a sorta of "stack of the calls", with which the WEB
application becomes something really similar a regular applications, with
"jump to subroutine" statements (the functions bound to anchors and buttons)
and the "return from subroutine" statements. The typical application
of the stack is handling generic pages that need to show something to the
user, then need to return to the calling page, whatever this page can be.

For example, this page displays the current date and the button "OK"
that send back to the calling page:

function show_date()
{
echo "The current date is: ", date(....);
Form();
Button("OK", "bt_return"); # return to the caller page
Form_()
}

This page might appear in several contexts of the WEB application:

function main_menu()
{
echo "<h1>Main menu</h2>"

bt_Anchor("See the current date", "show_date");
bt_Return_To("main_menu"); # back to me on "bt_return()"
}

function another_page()
{
echo "<h1>Another page</h2>"

bt_Anchor("See the current date", "show_date");
bt_Return_To("another_page"); # back to me on "bt_return()"
}
Hope this may contribute to your idea.

Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

May 21 '07 #2

P: n/a
Jon Slaughter wrote:
If anyone things this thing might be useful then I'm thinking about
rewriting everything and make it a little more clean. What it does allow one
to do is treat forms as inline objects that are not event driven. The
drawback is that the code to handle them must be in a string instead of
actual php code that will be parsed, say, by an IDE. Maybe someone knows of
a way around this or has some idea to make it better(I know there are going
to be the regular nay sayers but who knows).
What you're describing sounds fairly like my form handling code for
demiblog <http://demiblog.org/etc/forms>. Using my form handling classes
you can do something like:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, TRUE);

$blah is a string which is eval()ed to check the validity of submitted
data. However, I allow an alternative syntax:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, FALSE);

Here, $blah is a variable of type callback (the callback pseudo-type is
defined here: http://www.php.net/manual/en/language.pseudo-types.php)
which is passed to call_user_func().

That way, you can write a normal function -- say, validate_email() -- and
create a form field like:

$f = new DBF_Field_Text('email', 'y**@example.com', 'E-mail:');
$f->set_validity_check('validate_email', FALSE);

I also have a few common validity checks built-in, such as checking that a
field is numeric, checking a field is not left blank, and so on. These are
checked not only after the form has been submitted, but by a special piece
of client-side Javascript too.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 21 '07 #3

P: n/a

"Umberto Salsi" <sa***@icosaedro.italiawrote in message
news:f2**********@nnrp.ngi.it...
"Jon Slaughter" <Jo***********@Hotmail.comwrote:
>Again, the main idea is to treat form evaulation as inline instead of on
a
seperate page. In this way one encapsulates the function of the form with
the form itself. [...]

I agree with you that embedding all the code that handle related WEB pages
(the typical example is handling the loop form display, validation, error
reporting, acquisition of the data) is very powerful, and it can
implemented
in several ways. Adding "embedded strings with PHP code" may be a pain,
as you experienced. But things can be improved. Some idea follows.
[ Function bound to an URL ]

Rather than add chunks of code as inline strings and send them as cookies,
you might want to consider to associate every "action" to a PHP function.
That is what i called "programming the WEB application by functions".
No, you misunderstand, the cookies are just cookies for the data. It uses
code to evalude data that is to be stored. I call it dynamic data.
Then a single PHP source may contain several functions calling each other
via "actions". For example, this function generates a page with 3 anchors
that, once selected by the user, causes the correspondin function/action
handler to be called; handlers can have also arguments:
This is similar to what I had in mind to some degree. I did not want to make
a function for every thing that would be used. For example, I did not want
to code up a html form in php and supply the functions to the user to be
used.

Essentially I did not want to wrap html code because I feel its just an
extra layer of dead weight. That is, unless it serves a purpose. I did have
that idea though but just wasn't sure if it would be a good idea or not. On
one hand it does make things much easier but on the other it could be to
restrictive.

My initial idea was to implement some type of framework .NET for php and
html. One could have an visual IDE to create pages but the code would be
all be php. I feel that this might just be to much work and it would be
overkill. php is a scripting language and not ment to do what html easily
does. Although it might be something worth while to work on.

Of course with my idea the user can create there own functions to call sorta
like what you do but you supply the functions for them. Its more robust but
more complicated and confusing too. If PHP had something like C++ templates
then it probably could be a very powerful thing and really remove all the
problems that html has.

Thanks,
Jon
May 21 '07 #4

P: n/a

"Toby A Inkster" <us**********@tobyinkster.co.ukwrote in message
news:2s************@ophelia.g5n.co.uk...
Jon Slaughter wrote:
>If anyone things this thing might be useful then I'm thinking about
rewriting everything and make it a little more clean. What it does allow
one
to do is treat forms as inline objects that are not event driven. The
drawback is that the code to handle them must be in a string instead of
actual php code that will be parsed, say, by an IDE. Maybe someone knows
of
a way around this or has some idea to make it better(I know there are
going
to be the regular nay sayers but who knows).

What you're describing sounds fairly like my form handling code for
demiblog <http://demiblog.org/etc/forms>. Using my form handling classes
you can do something like:

Well, kinda. Your forms is just a wrapper for html with some extra stuff but
has similar goals as mine... and maybe I was headed down that path. I just
didn't want to wrap the forms though but I thought about it. I just don't
see any benefit except that it could make the code I'm using easier to
use(since, say, all the functions need to know what type of method is used
but if you wrap everythign in php you can set it once).

Your set_validity_check seems to be very similar to what I was doing except
I didnt' call it validation and mine is more primitive. Mine simply executes
code and that code can be anything. It is attached to a form(or could be
attached to the page) and is executed when the form is processed. In this
way one can do anything they want when a form is submitted rather than just
validate data... although I suspect that your function is not that
restrictive either?

Are the forms you created fixed in style by the php class or are the basic
html forms that are completely modified by css selection? One of the issues
that is keeping me from wrapping the html forms is that it seems that it is
to restrictive. Either you have to define the format of the form or you end
up wrapping the primitives of the form so that it just becomes a dead
wrapper. What I mean is, say I want to insert a div for absolute positioning
of some element inside a form... can I do that with your class easily?

Maybe if one completely wrapped html or used xml interface and a parser for
it they could get a similar result but much more close to html? (what I
means is add some new tags to it and then handle ther semantics in php)

Thanks,
Jon
May 21 '07 #5

P: n/a
On May 21, 4:20 am, Toby A Inkster <usenet200...@tobyinkster.co.uk>
wrote:
Jon Slaughter wrote:
If anyone things this thing might be useful then I'm thinking about
rewriting everything and make it a little more clean. What it does allow one
to do is treat forms as inline objects that are not event driven. The
drawback is that the code to handle them must be in a string instead of
actual php code that will be parsed, say, by an IDE. Maybe someone knows of
a way around this or has some idea to make it better(I know there are going
to be the regular nay sayers but who knows).

What you're describing sounds fairly like my form handling code for
demiblog <http://demiblog.org/etc/forms>. Using my form handling classes
you can do something like:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, TRUE);

$blah is a string which is eval()ed to check the validity of submitted
data. However, I allow an alternative syntax:

$f = new DBF_Field_Text('foobar', 'Default value', 'Label:');
$f->set_validity_check($blah, FALSE);

Here, $blah is a variable of type callback (the callback pseudo-type is
defined here:http://www.php.net/manual/en/language.pseudo-types.php)
which is passed to call_user_func().

That way, you can write a normal function -- say, validate_email() -- and
create a form field like:

$f = new DBF_Field_Text('email', '...@example.com', 'E-mail:');
$f->set_validity_check('validate_email', FALSE);

I also have a few common validity checks built-in, such as checking that a
field is numeric, checking a field is not left blank, and so on. These are
checked not only after the form has been submitted, but by a special piece
of client-side Javascript too.

--
Toby A Inkster BSc (Hons) ARCShttp://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
Toby,
What is the main difference between your approach and PEAR
HTML_QuickForm?
http://pear.php.net/package/HTML_QuickForm

May 21 '07 #6

P: n/a
Jon Slaughter wrote:
What I mean is, say I want to insert a div for absolute positioning
of some element inside a form... can I do that with your class easily?
Not yet, no. It wraps a good few elements round each form control by
itself though, most of which have classes and IDs, so can be styled as
required. The comment forms on my website are one example.
Your set_validity_check seems to be very similar to what I was doing
except I didnt' call it validation and mine is more primitive. Mine simply
executes code and that code can be anything. It is attached to a form(or
could be attached to the page) and is executed when the form is processed.
In this way one can do anything they want when a form is submitted rather
than just validate data... although I suspect that your function is not
that restrictive either?
Mine is entirely intended for data validation. You can't reasonably do
much more with it because it only operates on a single field -- not the
whole form.

When the form has been submitted you call:

$ok = $form->accept_submission() && $form->validate();

then the DBF_Form object will read submitted data and validate each field
in turn. Then you can call:

$vals = $form->get_values();

which returns an array of validated values, and you can do with that what
you want (e-mail it, store it in a database, etc).

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 22 '07 #7

P: n/a
jmark wrote:
What is the main difference between your approach and PEAR
HTML_QuickForm?
http://pear.php.net/package/HTML_QuickForm
Conceptually they are fairly similar. I looked at HTML_QuickForm to begin
with, but it was unsuitable for my project for the following reasons:

1. It went a bit too far -- it was a big framework for form
input, whereas I wanted something a bit simpler; and

2. HTML_QuickForm ties you to XHTML 1.0.

My full rationale is explained at the top of my source code:
http://svn.sourceforge.net/viewvc/de...ss?view=markup

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
May 22 '07 #8

P: n/a

"Toby A Inkster" <us**********@tobyinkster.co.ukwrote in message
news:ik************@ophelia.g5n.co.uk...
Jon Slaughter wrote:
>What I mean is, say I want to insert a div for absolute positioning
of some element inside a form... can I do that with your class easily?

Not yet, no. It wraps a good few elements round each form control by
itself though, most of which have classes and IDs, so can be styled as
required. The comment forms on my website are one example.
>Your set_validity_check seems to be very similar to what I was doing
except I didnt' call it validation and mine is more primitive. Mine
simply
executes code and that code can be anything. It is attached to a form(or
could be attached to the page) and is executed when the form is
processed.
In this way one can do anything they want when a form is submitted rather
than just validate data... although I suspect that your function is not
that restrictive either?

Mine is entirely intended for data validation. You can't reasonably do
much more with it because it only operates on a single field -- not the
whole form.

When the form has been submitted you call:

$ok = $form->accept_submission() && $form->validate();

then the DBF_Form object will read submitted data and validate each field
in turn. Then you can call:

$vals = $form->get_values();

which returns an array of validated values, and you can do with that what
you want (e-mail it, store it in a database, etc).

--

If you have multiple forms how do you distinguish from them?
May 22 '07 #9

P: n/a

"Jon Slaughter" <Jo***********@Hotmail.comwrote in message
news:zX****************@newssvr22.news.prodigy.net ...
>
"Toby A Inkster" <us**********@tobyinkster.co.ukwrote in message
news:ik************@ophelia.g5n.co.uk...
>Jon Slaughter wrote:
>>What I mean is, say I want to insert a div for absolute positioning
of some element inside a form... can I do that with your class easily?

Not yet, no. It wraps a good few elements round each form control by
itself though, most of which have classes and IDs, so can be styled as
required. The comment forms on my website are one example.
>>Your set_validity_check seems to be very similar to what I was doing
except I didnt' call it validation and mine is more primitive. Mine
simply
executes code and that code can be anything. It is attached to a form(or
could be attached to the page) and is executed when the form is
processed.
In this way one can do anything they want when a form is submitted
rather
than just validate data... although I suspect that your function is not
that restrictive either?

Mine is entirely intended for data validation. You can't reasonably do
much more with it because it only operates on a single field -- not the
whole form.

When the form has been submitted you call:

$ok = $form->accept_submission() && $form->validate();

then the DBF_Form object will read submitted data and validate each field
in turn. Then you can call:

$vals = $form->get_values();

which returns an array of validated values, and you can do with that what
you want (e-mail it, store it in a database, etc).

--


If you have multiple forms how do you distinguish from them?
oh... I guess you use 1 object for 1 form...
May 22 '07 #10

P: n/a
On May 22, 2:04 am, Toby A Inkster <usenet200...@tobyinkster.co.uk>
wrote:
jmark wrote:
What is the main difference between your approach and PEAR
HTML_QuickForm?
http://pear.php.net/package/HTML_QuickForm

Conceptually they are fairly similar. I looked at HTML_QuickForm to begin
with, but it was unsuitable for my project for the following reasons:

1. It went a bit too far -- it was a big framework for form
input, whereas I wanted something a bit simpler; and

2. HTML_QuickForm ties you to XHTML 1.0.

My full rationale is explained at the top of my source code:http://svn.sourceforge.net/viewvc/de...ncludes/DBF_Fo...

--
Toby A Inkster BSc (Hons) ARCShttp://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux
Thank you for your explanation

May 22 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.