PHP Language - Problems opening a page inside PHP-code.

Author

Problems opening a page inside PHP-code.

Jack L.

2006-05-29, 6:58 pm

Hi group.

Once again, I need some more help, and I have two questions (the other is
pretty far down in the text hehe).

I am writing a simple questionnaire site in which the admin, as she creates
a new questionnaire, can choose the number of questions to ask and the type
of questionnaire (simple, matrix-form, ranked, etc) as part of the setup.

Currently, for each form the admin has filled out, she will be sent to
another page (as soon as the data have been validated). But I'm having
trouble sending the person to another page / sending WITH session variable.
I have tried three methods so far.

If I use a simple JavaScript inside a php-file:

session_register($no_of_questions);
<script language="javascript" type="text/javascript">
window.location="questions.php";
</script>

.... then using session_is_registered() in questions.php, I find out that
$no_of_questions is not passed to questions.php. However, if I use include,
ie:

session_register($no_of_questions);
include("questions.php");

.... then the same variable is passed to questions.php. I have also tried
using the meta-tag, ie:

print "<META HTTP-EQUIV='refresh' CONTENT='0'; URL='questions.php'>";

.... however, what happens is that the same page is reloaded, thus the user
is not directed to questions.php. And because of that, I don't know if the
session variable will be passed. In questions.php, I have naturally invoked
session_start() on top of the code.

What should I do?

---------

Also, on a more general basis, what factor makes you decide that the user
should be passed to another page? Would you say "let's just make all forms
as functions that can be invoked" instead of forwarding the user to the next
page that contains another form? It looks like some websites choose to put
the entire process in a single php-file (although, for the user it might
look like different html pages). I'm not what strategy to follow. What
thoughts should I make when designing the admin page?

--
Mvh. / Best regards,
Jack L.,
Copenhagen, EU

David Haynes

2006-05-29, 6:58 pm

Jack L. wrote:
> Hi group.
>
[snip]
>
> What should I do?

Don't use session_register().

Use:
session_start();
$_SESSION['foo'] = 'bar';
session_write_close();
header('Location: http://some_url.com');

Try this simple example:

[file1.php]
<?php
session_start();
$_SESSION['number_of_questions'] = 2;
session_write_close();
header('location: file2.php'];
?>

[file2.php]
<?php
session_start();
$number_of_questions = $_SESSION['number_of_questions'];
echo "There are $number_of_questions questions to be answered\n";
?>

> Also, on a more general basis, what factor makes you decide that the
> user should be passed to another page? Would you say "let's just make
> all forms as functions that can be invoked" instead of forwarding the
> user to the next page that contains another form? It looks like some
> websites choose to put the entire process in a single php-file
> (although, for the user it might look like different html pages). I'm
> not what strategy to follow. What thoughts should I make when designing
> the admin page?

Typically it depends upon the goals of the application. Is the
application likely to grow? Are there going to be a number of developers
looking at the code? Are elements of the presentation going to change?
Do you need to support many different presentation modes such as HTML
and XML and WAP and ...?

If you are the only coder and will be the only one maintaining the code,
then you are free to pick the form that works for you. If you are going
to hand the code off at some point, then anything that reduces the
complexity of the code is a good thing.

There is a trade off between the unified form approach (everything in
one monolithic file) and the dispersed approach (all sorts of things in
all sorts of files) and, typically, it is the size and internal
complexity of the individual file vs. the complexity of managing and
importing multiple files.

Coming, as I do, from the more object-based approaches, I tend to like
to keep individual files as simple as possible and pay the penalty in
managing and importing the multiple files. (NOTE: When I say penalty
here, I am not really talking about the issue of loading the file pieces
in PHP in order to produce the page output, but rather the penalty of
managing the complexity of which files are included and where they
normally reside.)

Having essentially done the same application in a unified file form and
in an MVC2 form, I would strongly recommend the latter for serious
production work in an environment with lots of changes to the look and
feel components. Being able to adjust the presentation without affecting
the business logic (even if accidentally) is a benefit that far
outweighs the benefits of everything in one place.

Also, from a selfish point of view, if I keep the elements separated
with clearly defined APIs, I can hand off pieces to other people without
having to teach them the entire system. Since the APIs are clearly laid
out, it is easy to adjust code and test harnesses without intimate
knowledge and/or having to jump through logic hoops to toss away
presentation elements in order to test the business logic.

OK. Enough soap boxing...

-david-

Jack L.

2006-05-31, 7:00 pm

"David Haynes" <david.haynes2@sympatico.ca> wrote in message
news:QBLeg.76110$6k1.14205@fe38.usenetserver.com...
> Jack L. wrote:
> [snip]
>
> Don't use session_register().
>
> Use:
> session_start();
> $_SESSION['foo'] = 'bar';
> session_write_close();
> header('Location: http://some_url.com');
>

Hi David.

Thank you for your time on replying my post. I tried the abovementioned
example, and it seems to be working, even by using a JavaScript. I can't
invoke header() without getting an error message, because before the
redirection, HTML-code is outputted.

I have read your "soap box" few times now, and gotten a bit inspiration on
how to structure the site. You said that you prefer to separate elements
from the API. Are the elements the visual part of the site, and if so, do
you suggest a Document/View-approach?

--
Mvh. / Best regards,
Jack L.,
Copenhagen, EU

David Haynes

2006-05-31, 7:00 pm

Jack L. wrote:
> "David Haynes" <david.haynes2@sympatico.ca> wrote in message
> news:QBLeg.76110$6k1.14205@fe38.usenetserver.com...
>
> Hi David.
>
> Thank you for your time on replying my post. I tried the abovementioned
> example, and it seems to be working, even by using a JavaScript. I can't
> invoke header() without getting an error message, because before the
> redirection, HTML-code is outputted.
That is true. A redirect via the header requires that no output has
already occurred for the page. This makes sense because, if there is
already some output, you would expect the browser to display it and not
redirect.

Once you have some display, you should only redirect via links or forms.

> I have read your "soap box" few times now, and gotten a bit inspiration
> on how to structure the site. You said that you prefer to separate
> elements from the API. Are the elements the visual part of the site, and
> if so, do you suggest a Document/View-approach?

Wow! An invitation to get back on the soap-box...

I usually go with a model-view-controller approach. The model consists
of the database schemas, SOAP interfaces, etc. The views consist of the
various HTML, XML, etc. transformations on the data, the controller
manages the relationships between the views and the model.

It is important to recognize that, just as the methods to classes have
carefully defined APIs, so, too, should the interactions between the
views and the controller. The view will send data to the controller via
POST or GET and the controller will send data to the view via SESSIONS.
Both the view and controller have to agree on what data will be sent and
under what name it will be referenced for them to have any hope of
having a meaningful exchange of data.

So, how does it actually work?

Everything starts with the controller which consists of three main logic
areas:
1. bringing in any includes required for running, debugging, logging, etc.
2. processing any POST or GET values
3. populating the SESSION with values required for the target view.

The last thing the controller does is call header() to invoked the php
code to generate the HTML code to paint the view.

The view (and in this case, I'll just talk about the HTML view) also has
three areas to it:
1. bringing in any includes just like the controller
2. pulling the values from the SESSION and generating any
display-specific values
3. generating the HTML to show the page.

As I mentioned before, I always set a value called 'controller' in my
SESSION which is the URL to the controller that caused this view
generating code to be invoked.

So, where does the model come into it?
The controller accesses the model in steps 2 and 3 of its processing. In
my case, I have three general types of model classes:
1. classes that map directly to a database table or SOAP API. These deal
with a single instance (a row in database, a command in SOAP)
2. classes that operate on sets of results (e.g. sets of rows from a
table, more complex combinations of commands in SOAP)
3. classes that support these other two classes a.k.a. helper classes -
e.g. generic database access classes, SOAP service communication,
classes, HTML utility classes, etc.

So, a typical session might go as follows:
1. the controller is called with no POST data.
2. it does some setup of its environment, skips the POST processing and
goes directly to populating the SESSION for the view. To do this, it may
access tables in the database and data from some SOAP services.
3. the session is closed (session_write_close) and the appropriate view
program is invoked via the redirect (header).
4. the view program conditions its environment
5. it then reads back the SESSION values it needs and generates the
appropriate HTML code.
6. Let's say that part of the HTML code involves a <form> element. The
form is set up as <form action="<?php echo $_SESSION['controller'];?>"
method="POST">
7. I also supply an action on the form so that the POST processing in
the controller knows what I want it to do. I do this via a hidden form
element. e.g. <input type="hidden" name="command" value="add_to_order">
8. When the user clicks on the 'submit' button, this is all sent back to
the controller via a POST operation.
9. Now the controller conditions its environment and then processes the
POST values. The code for this section is typically something like:
if( isset($_POST['command'] ) ) {
switch( $_POST['command'] ) {
case 'add_to_order':
...
10. Once the 'add_to_order' business logic is complete (which may have
involved conversations with the various model classes) the controller
populates the SESSION and calls redirect again.
11. Round and round it goes until the user gets tired...

This is a gross simplification of an MVC2 implementation but it will
give you a good understanding (I hope!) of how it all goes together and
where the boundaries are.

-david-

Sponsored Links