How dynamic is too dynamic?

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

Re: How dynamic is too dynamic?

On Aug 29, 2:41 pm, Adam Baker 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

Re: How dynamic is too dynamic?

Adam Baker wrote in news:1188412863.944070.231590
@g4g2000hsf.googlegroups.com:

> 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

I'm a fan of clean seperation and order over perceived 'convenience' of
a single/a few PHP files.

One of the problems with rolling all your second-level pages into a
single PHP file is updating the file - if you make a code-error
somewhere (say, adding an enhancement to one section), 'all' of your
second-level pages will fail.

Secondly, once you come back to this project in six months or so, you
(or someone else, especially) will probably appreciate distinct pages
for each specific section as opposed to spending/wasting time poring
over the single PHP document and trying to figure out what's happening
where.

It is not uncommon for some programmers to have seperate files for each
class, and even for classes which extend other classes.

It's obviously a matter of personal preference, but as far as planning
for the future goes, I think seperation and order is a good thing.
Basic shared elements of your second-level can certainly utilize an
"include" file which makes basic updates as simple as if your pages were
all in one PHP file...

Re: How dynamic is too dynamic?

Adam Baker 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.

My framework (and I guest that of most folks) does pretty much the same
thing.

The way I did it was to create a database class (bvckvs_database()) that
does all the DB interaction.

Then I have an abstract baseclass (bvckvs_baseclass()) that aggregates
the database class. It defines a few properties that are specific to
tables, but not to any one table.

Finally I have the class I actually use (bvckvs_publication) that
EXTENDS the base class. That class is used to build the web pages, and
gets its data through the other tiers. I create the same "publication"
class for each web page, but by simply changing the title, it auto-loads
all of the data for that specific publication.


In tiered terms - Database->Business Logic->User Interface.

That's an architectural structure that I learned from Microsoft's
"Solutions Architecutres" courses. It's not the way everybody does it,
but it works pretty darned well for me... and Bill.

Re: How dynamic is too dynamic?

Good Man wrote:

> One of the problems with rolling all your second-level pages into a
> single PHP file is updating the file - if you make a code-error
> somewhere (say, adding an enhancement to one section), 'all' of your
> second-level pages will fail.

Of course, that's also its strength - because if you make a mistake, you
only have to fix it one file.

Re: How dynamic is too dynamic?

> Secondly, once you come back to this project in six months or so, you
> (or someone else, especially) will probably appreciate distinct pages
> for each specific section as opposed to spending/wasting time poring
> over the single PHP document and trying to figure out what's happening
> where.

I'm actually in this situation, as a webmaster for an absolutely
insane PHP design. I think it all even feeds back to a single file.
Some of the web site's content is provided through a database, and
some is just text. As you mention, if something goes wrong with that
site I'm SOL.

Including headers and footers is probably the right way to go.

Thanks for your thoughts.

Adam

Re: How dynamic is too dynamic?

On Aug 29, 12:05 pm, ELINTPimp wrote:
> On Aug 29, 2:41 pm, Adam Baker 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

Re: How dynamic is too dynamic?

Post removed (X-No-Archive: yes)