David,

I'm beginning to think I don't understand about using the header()
function. I have read in your books and others that "Using header() or
starting a PHP session must be done before any output is sent to the
browser." Does that mean in the "sending" page not the "receiving"
page? I thought it meant the receiving page, the page to which you are
redirected. Now I'm thinking I have misunderstood this entirely.

So my question is, as I posed to Micha in this thread, how does one
construct a page like I have with 20 include files, each of which
contains html. As you may know from my post on your FOE forum "backend
blight", the page I'm trying to build has 5 Spry accordions each of
which contains 4 panels for LIST, ADD, EDIT, DELETE. My intention was
to create the individual pages for each panel and include() them in the
appropriate panel, forms, tables and all. I believed this "modular"
approach was the best and cleanest way to accomplish this. Now I'm not
sure how to go about it given my desire to use header() to redirect on
update or delete.

Also, Micha says that my solution - using ob_start() and ob_end_flush()
is an ugly workaround. I'm trying to understand why that is if it
accomplishes what is needed and functions as expected. Is this a case
of coder aesthetics and my solution is just not elegant, or is it truly
flawed?

Thanks to you and Micha for responding.

Best,

Brett

Brett wrote:
> So my question is, as I posed to Micha in this thread, how does one
> construct a page like I have with 20 include files, each of which
> contains html.

The simple answer is: "You don't". Twenty include files sounds like
overkill. The other problem is that you're mixing the business logic of
your page with the presentation. In an ideal situation, you should keep
separate the code that queries the database and makes other decisions.
Dreamweaver does that by putting all the decision-making code above the
DOCTYPE declaration. It's a technique that works fine for small
applications, but when you start building something more ambitious, you
need to think about adopting the Model-View-Controller (MVC) design pattern.

MVC is a much more complex way of building a site, and it's an approach
that I understand in theory, but have never created in practice. If
you're interested in learning more, you might want to take a look at
"Practical Web 2.0 Applications with PHP" by Quentin Zervaas. I managed
to get only halfway through the book before being sidetracked onto
another project, but it's excellent. Be warned, though, it's pretty
advanced.

> Also, Micha says that my solution - using ob_start() and ob_end_flush()
> is an ugly workaround. I'm trying to understand why that is if it
> accomplishes what is needed and functions as expected. Is this a case
> of coder aesthetics and my solution is just not elegant, or is it truly
> flawed?

It's ugly because you're relying on a hack to solve your problem. If
your code is well designed, you don't need the output buffer.

--
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS3" (friends of ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

Brett wrote:
> So my question is, as I posed to Micha in this thread, how does one
> construct a page like I have with 20 include files, each of which
> contains html.

The simple answer is: "You don't". Twenty include files sounds like
overkill. The other problem is that you're mixing the business logic of
your page with the presentation. In an ideal situation, you should keep
separate the code that queries the database and makes other decisions.
Dreamweaver does that by putting all the decision-making code above the
DOCTYPE declaration. It's a technique that works fine for small
applications, but when you start building something more ambitious, you
need to think about adopting the Model-View-Controller (MVC) design pattern.

MVC is a much more complex way of building a site, and it's an approach
that I understand in theory, but have never created in practice. If
you're interested in learning more, you might want to take a look at
"Practical Web 2.0 Applications with PHP" by Quentin Zervaas. I managed
to get only halfway through the book before being sidetracked onto
another project, but it's excellent. Be warned, though, it's pretty
advanced.

> Also, Micha says that my solution - using ob_start() and ob_end_flush()
> is an ugly workaround. I'm trying to understand why that is if it
> accomplishes what is needed and functions as expected. Is this a case
> of coder aesthetics and my solution is just not elegant, or is it truly
> flawed?

It's ugly because you're relying on a hack to solve your problem. If
your code is well designed, you don't need the output buffer.

--
David Powers, Adobe Community Expert
Author, "The Essential Guide to Dreamweaver CS3" (friends of ED)
Author, "PHP Solutions" (friends of ED)
http://foundationphp.com/

..oO(Brett)

>> No. It's an ugly workaround, but doesn't fix the real problem. You
>> should re-order your code so that all tests and calculations happen
>> before the first line of output.
>
>I thought that was the purpose of output buffering. What is the real
>problem then?

It's just a workaround, not a solution. The purpose for output buffering
is not to overcome a "suboptimal" code structure, but for example to
apply some kind of filters to the final page before it gets delivered to
the client (gzip compression for example).

Turning it on just in order to prevent the headers problem is ugly IMHO,
because it's not really what OB is meant for and it requires more CPU
time and memory on the server. It's also quite ugly if your script
already generates a lot of output, but then has to discard it because of
a redirect. This would mean a lot of HTML generated for nothing.

Although this shouldn't become a real problem on a modern server, it
could be completely avoided quite easily with just a little better code
structure.

>I thought the problem was that I couldn't redirect to my
>page because I was getting the headers error.

Yep.

>What makes this an ugly workaround? I have 20 includes in this page,
>each of which has some html, either a table or form. Are you saying
>that my includes should only contain the php tests and validations, and
>that all forms and tables should be in the accordion panels directly in
>this page? So the dynamic data in my forms and tables need to be placed
>within this page?

Nope. Includes are still perfectly fine and important for this.

>Doesn't this defeat the purpose of using includes to
>make a site more modular?

Usually the creation of the HTML output should be the last step in the
whole process, when all other tests, actions etc. are done and their
results are known.

In case of a form for example you could easily split the processing into
multiple pieces. One function does the validation, one processes the
data and another one just prints the entire form. Three completely
independent things: validate(), process() and render() for example.

If the validation fails, process() will not be called (or at least
doesn't do anything with the data), instead render() should just show
the form again with error messages:

validate() --> FALSE
process() not called
render()

But if the validation succeeds, then process() will be called and might
even do a redirect to a "thank you" page. Until that point there was no
output, hence there's no headers problem at all:

validate() --> TRUE
process() --> redirect, script stops
render() not called

>Micha, I'm not challenging your knowledge, you've probably forgotten
>more than I'll ever know



>but I'm trying to understand these concepts
>better.

No problem.

Micha

..oO(Brett)

>> No. It's an ugly workaround, but doesn't fix the real problem. You
>> should re-order your code so that all tests and calculations happen
>> before the first line of output.
>
>I thought that was the purpose of output buffering. What is the real
>problem then?

It's just a workaround, not a solution. The purpose for output buffering
is not to overcome a "suboptimal" code structure, but for example to
apply some kind of filters to the final page before it gets delivered to
the client (gzip compression for example).

Turning it on just in order to prevent the headers problem is ugly IMHO,
because it's not really what OB is meant for and it requires more CPU
time and memory on the server. It's also quite ugly if your script
already generates a lot of output, but then has to discard it because of
a redirect. This would mean a lot of HTML generated for nothing.

Although this shouldn't become a real problem on a modern server, it
could be completely avoided quite easily with just a little better code
structure.

>I thought the problem was that I couldn't redirect to my
>page because I was getting the headers error.

Yep.

>What makes this an ugly workaround? I have 20 includes in this page,
>each of which has some html, either a table or form. Are you saying
>that my includes should only contain the php tests and validations, and
>that all forms and tables should be in the accordion panels directly in
>this page? So the dynamic data in my forms and tables need to be placed
>within this page?

Nope. Includes are still perfectly fine and important for this.

>Doesn't this defeat the purpose of using includes to
>make a site more modular?

Usually the creation of the HTML output should be the last step in the
whole process, when all other tests, actions etc. are done and their
results are known.

In case of a form for example you could easily split the processing into
multiple pieces. One function does the validation, one processes the
data and another one just prints the entire form. Three completely
independent things: validate(), process() and render() for example.

If the validation fails, process() will not be called (or at least
doesn't do anything with the data), instead render() should just show
the form again with error messages:

validate() --> FALSE
process() not called
render()

But if the validation succeeds, then process() will be called and might
even do a redirect to a "thank you" page. Until that point there was no
output, hence there's no headers problem at all:

validate() --> TRUE
process() --> redirect, script stops
render() not called

>Micha, I'm not challenging your knowledge, you've probably forgotten
>more than I'll ever know



>but I'm trying to understand these concepts
>better.

No problem.

Micha

Micha,

Thanks for your reply. I completely reworked the page based on your
recommendations, and now it works quite well with no header() problems.
Basically I took my include files, separated the validation and
processing and put that above the doctype, then put the forms, etc. in
their respective Spry accordion panels in the body. I see now what you
mean about it having better structure.

As always, thanks for your help and advice.

Kind regards,

Brett

Micha,

Thanks for your reply. I completely reworked the page based on your
recommendations, and now it works quite well with no header() problems.
Basically I took my include files, separated the validation and
processing and put that above the doctype, then put the forms, etc. in
their respective Spry accordion panels in the body. I see now what you
mean about it having better structure.

As always, thanks for your help and advice.

Kind regards,

Brett

David,

Thank you very much for your input. I feel quite confident that the MVC
approach would be well over my head at this point. So I needed to find
another way. After reading your post and Micha's, I realized that this
required a major redo. Actually, it turned out to be a less daunting
task than I originally feared, taking only a couple of hours. That
short time was helped by the fact that I already had the code in my
include files, so it only meant cutting and pasting.

Anyway, it's working now and all processing and validation is above the
doctype, and all html below. No more header() problems.

Thanks very much for your continued help.

Best,

Brett

PS. I ordered "PHP Object-Oriented Solutions" last week and am
expecting it to arrive any day now.*
*

David,

Thank you very much for your input. I feel quite confident that the MVC
approach would be well over my head at this point. So I needed to find
another way. After reading your post and Micha's, I realized that this
required a major redo. Actually, it turned out to be a less daunting
task than I originally feared, taking only a couple of hours. That
short time was helped by the fact that I already had the code in my
include files, so it only meant cutting and pasting.

Anyway, it's working now and all processing and validation is above the
doctype, and all html below. No more header() problems.

Thanks very much for your continued help.

Best,

Brett

PS. I ordered "PHP Object-Oriented Solutions" last week and am
expecting it to arrive any day now.*
*

..oO(Brett)

>Micha,
>
>Thanks for your reply. I completely reworked the page based on your
>recommendations, and now it works quite well with no header() problems.
>Basically I took my include files, separated the validation and
>processing and put that above the doctype, then put the forms, etc. in
>their respective Spry accordion panels in the body. I see now what you
>mean about it having better structure.
>
>As always, thanks for your help and advice.
>
>Kind regards,

You're welcome.

Micha