On Aug 29, 12:05 pm, ELINTPimp <smsi...@gmail.comwrote:
On Aug 29, 2:41 pm, Adam Baker <adamb...@gmail.comwrote:
This is a fairly broad question. I have looked for web sites or books
on the topic, by to no avail.
I'm creating a fairly small web site in which the content is drawn
from an XML file (more or less as an exercise, but also so that it can
be maintained easily).
I've got a first-level page and five second-level pages.
One way I'm trying it is to keep a single XML file, and two PHP files,
one for the first level page and one for the second-level page. That
makes pretty clunky content generation.
The second option is to have a different PHP file for each second
level page. Less elegant in one respect, but the individual PHP files
are much simpler.
This is a small example, but I'm curious whether people have
experience with larger applications, and at what point they felt the
PHP got intractable.
Thanks for any thoughts,
Adam
Adam,
The fact that you are using an XML file really has little to do with
your question, that is just want your choosing for you persistent data
storage. Although your question doesn't seem to be worded about how
you are structuring your application based on the XML, in case you
are, just ask yourself if you would structure it the same if you were
using a database for storage. That's all it is, and it should be able
to be swapped out in the future if you so desire.
That gets to my next point. With the little information you gave
about your application, I don't think we can fairly judge and give
suggestions on how to structure your application...but I will try =).
If your "second-level" pages are all formatted the same (in a template
sense), you should have a single template file (presentation layer),
and one or more classes to actually do the business logic and data
manipulation. If the application is as small as you say, you can
probably get away with integrating the logic on how you want to
manipulate your data (control) in with the presentation layer...but
that is sketchy and depends on a lot of factors.
If this doesn't make too much sense, I apologize. If you post more
code, I can be more specific to your situation and probably
(hopefully) make more sense.
~steve
Thanks for your thoughts, Steve. I am less interested in doing my
current project "correctly" than in general principles of organizing
large web sites. Here is the web site if you are interested (I'm
continuing to work on it, so if you visit when something is not
working properly, I apologize):
http://www.u.arizona.edu/~tabaker/apil/
It's just a web site for a lab. The content associated with the middle
three buttons is all fluid, so it makes sense to generate the pages
dynamically.
To offer a specific example of a question I had, I've got one version
where the location and color associated with each button was read from
the XML file. Theoretically that makes modifications easier, and I
could add a new section later on if I want to. But, the programming
gets really clunky. And it's hard to think of a situation where I'd
need to make such a drastic change.
Intuitively it seems like a bad idea to have user interface stuff
controlled in the same database that the content comes from. But in
any but the most trivial graphical interface, the design depends on
the content. But if the interface depends so heavily on the content,
and to change the content would require a change to the interface, why
am I bothering to generate the pages dynamically?
Those are the specifics, but as I say, I'm less interested in this
particular project than I am in general principles.
Adam
