|
|
Posted by Adam Baker on 08/29/07 20:25
On Aug 29, 12:05 pm, ELINTPimp <smsi...@gmail.com> wrote:
> On Aug 29, 2:41 pm, Adam Baker <adamb...@gmail.com> wrote:
>
>
>
> > 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
Navigation:
[Reply to this message]
|