Not everything needs to be dynamic

Ever wonder why some site hosts suck so bad, and other don’t. Sometimes it isn’t the host but the number and quality of the sites on the host.

“What? I’m supposed to increment my counter so my exit clause will be met?”

Don’t laugh, I’ve seen this too many times. Sometimes it isn’t the number of sites on the server, its the number of quality sites on the server. Specificly low quality sites.

Some sites are just crud code from the get go, and because it compiles, people are ready to release. But not so. This code, just because it compiled, may be only at a state of advanced prototyping.

Is there too much code duplication? Are you managing your objects? How about connections, and connection pools? Should you be considering n-Tier development? Are you using threads? Do you have a thread manager?

These are the types of questions that start the ball rolling to improving your code. It is no guarrantee of good code, but it does help. There are plenty of other questions like:

Are you marshalling efficiently? Are your components broken up logically? Do you have clean breaks and calling routines for processing across tiers? Is there an efficient technology that can do this better, or help to do this better?

One site I worked on they wanted everything to be dynamic. Great! Cha-ching!! But as I delved into it, I discovered, that was a bad idea. The server would bog for it’s rating and the demand estamates.

Solution… Make the data entry, for content creation, store data dynamicly and staticly. So now the page being generated is static on the server, but what builds the page is dynamic on the server’s database. Now the server only takes a big hit during content changes and some dynamic only content, like chat rooms. By having a dynamic storage too, you are able to simplify editing and updating the content.

For some of this, I like XML for the mostly static, with a XSLT to generate my HTML. Depending on the nature of the design, if the program is dynamicly skinned, the the XSLT is called on every page render, otherwise the page only changes when the content changes, then call the XSLT on publish, and persist the rendered XML page to an HTML file.

Don’t think you have to be married to any one style of page generation, just remember, decide what you need according to your requirments and your resources. (Shared hosting plans are always considered low end resources.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.