discussion: script structuring and mod_rewrite?

[Susanne West]

hi group.

i'm tackling a bigger project that will use mod_rewrite to patch
a series of urls into a master php-script. this script builds the
page framework that contains a series of elements that remain on
every page. only a center part (a <div>) is filled with different
contents, depending on how the page is called (= mode of the page).
the point is, there are quite a few (approx 20) different 'modes'
for the center part to be filled with.

so now i wonder, what kind of approaches you guys use to keep the
project and all the subpages/includes/static elements as flexible
and clear as possible. there's really many ways to do this but i
can't yet decide on 'the right way' to do it...

let me examplify this:

/program index.php?mode=program
/movie index.php?mode=movie
/reservation index.php?mode=reservation
etc...
+-------------------+
|menu |
|calendar |
|etc.. |
| +--------------+ |
| | content 1 | |
| | ... | |
| | content 20 | |
| | | |
| +--------------+ |
| footer, banner... |
+-------------------+
- one way would be to have a master php script and include ALL
subitems such as menu, calendar etc. as well as the contents
that go in the main content section, thus keep everything in
.inc files besides tha main logic. (= whole project becomes a
huge puzzle). as such:

index.php [the logic switch]
menu.inc [decoration elements]
calendar.inc
footer.inc
banner.inc
content1.inc [content elements]
content2.inc
content3.inc

- another way would be to make many master pages for evey mode and
only include the framework-items (= every page-type can be
edited as one, only the framework-items are detached). of
course mod_rewrite would properly map the calls to those pages...

content1.php [content pages]
content2.php
content3.php

menu.inc [framework elements]
calendar.inc
footer.inc
banner.inc

- then the version with the exact opposite:

index.php (with menu, calendar, footer elements fix)
content1.inc
content2.inc
content3.inc

- make one HUGE page with all the subelements in the same script
and tons of switches and if's to turn them on and off.

index.php (menu, cal, footer, content 1-20 as switches)
what would you suggest? is there a way that i'm missing?
speedwise, all the versions should be more or less that same...

are there any tutorials or links that deal with these kinds of
structuring issues? i know i'm starting bible studies here, but
i think the discussion is pretty relevant also for newbies.
thanks already for all the input!

[Rik]

On Tue, 13 Feb 2007 00:11:29 +0100, Susanne West <sw***@gmx.dewrote:

i'm tackling a bigger project that will use mod_rewrite to patch
a series of urls into a master php-script. this script builds the
page framework that contains a series of elements that remain on
every page. only a center part (a <div>) is filled with different
contents, depending on how the page is called (= mode of the page).
the point is, there are quite a few (approx 20) different 'modes'
for the center part to be filled with.

so now i wonder, what kind of approaches you guys use to keep the
project and all the subpages/includes/static elements as flexible
and clear as possible. there's really many ways to do this but i
can't yet decide on 'the right way' to do it...

let me examplify this:

/program index.php?mode=program
/movie index.php?mode=movie
/reservation index.php?mode=reservation
etc...
+-------------------+
|menu |
|calendar |
|etc.. |
| +--------------+ |
| | content 1 | |
| | ... | |
| | content 20 | |
| | | |
| +--------------+ |
| footer, banner... |
+-------------------+
- one way would be to have a master php script and include ALL
subitems

- another way would be to make many master pages for evey mode and
only include the framework-items (= every page-type can be
edited as one, only the framework-items are detached).

- then the version with the exact opposite:
index.php (with menu, calendar, footer elements fix)
content1.inc
content2.inc
content3.inc

- make one HUGE page with all the subelements in the same script
and tons of switches and if's to turn them on and off.

what would you suggest? is there a way that i'm missing?
speedwise, all the versions should be more or less that same...

Bigger project -go for a database.

Specify in the database what modes require what scripts, what pages have
what content (possibly storing flat HTML directly in the database for easy
maintainability). Make an interface for it, and presto, with u few
buttonclicks most of the pages adapt directly to how you want them,
without fiddling about in tons of files.

I usually define one or several layouts, store a page-tree in the database
and link layout-id's to the pages as desired. Create content (where
'content' can be flat HTML, the name of a (php-)file to include, some
custom wrapper around a certain database-queries, etc.), and again link
that to the pages. Voilà, the beginnings of your own custom build CMS.

--
Rik Wasmus

[Susanne West]

Rik wrote:

>
Bigger project -go for a database.

Specify in the database what modes require what scripts, what pages
have what content (possibly storing flat HTML directly in the database
for easy maintainability). Make an interface for it, and presto, with u
few buttonclicks most of the pages adapt directly to how you want
them, without fiddling about in tons of files.

I usually define one or several layouts, store a page-tree in the
database and link layout-id's to the pages as desired. Create content
(where 'content' can be flat HTML, the name of a (php-)file to include,
some custom wrapper around a certain database-queries, etc.), and again
link that to the pages. Voilà, the beginnings of your own custom build
CMS.

hi.

i know what you're heading after. the point is, that a raw db with data
exists, and i don't want to build a page-based db besides. all i need is
already in a relational structure and i only have to pull it out in
different ways. that can easily be done with identifyable modules and
routines which is much faster than to build a whole page-system on top.

what you describe makes maily sense if you have tons of manually-
maintained pages. then i'd opt for a page-db also. also, i don't have
'different' layouts with modules that are turned on/off depending of the
page. it's really just a framework with the same components around
all the time...

greets.