Forum Moderators: coopster
In content management one typically has a "header", "body" and "footer". In the "body" one typically places "dynamic content" one way or the other. This part is one we'll leave as understood. As would be the case with the end user in mind having to work with the finished app - usability in a word.
In the Object Orientated world an item is reduced to its n'th degree - as in the smallest complete component. In the database world, data is "normalised" to its least dependent component. In workflow we have the above - header, body, footer - being a vehicle to hold objects (as in functions, etc) and data. That's the theory.
At the moment I'm hacking through a body of code and trying to figure out what the original author was trying to do.
We have this. There's a body of content - call it main.php plus plus (as in various pages). Each page calls (as an include) a page called top.php. This page has nothing but code to show the date and run a search feature on each page.
Top.php, in turn, calls a page named header.php (there's also a footer.php). The header.php in turn has calls to pages named config.php and functions.php. Config.php in turns call some other pages - db.php, display.php, etc.
As a result, in the above scenario, the main page was calling a function that was listed in the functions.php which was 4 "hops" away. This struck me as being a little absurd.
Believing that "less" means "more" and that the shortest distance between two points is a straight line, I ditched the top.php and moved that code into the header.php. In the header.php there were functions there that got moved into the functions.php page and so on.
Both approaches work. Which one works better or more efficiently is hard to say. From a coding point the latter seems easier to deal with - as in having fewer things to recall (mentally) and appears to be a more logical route.
From a computing point of view - as in making calls to both the server and database - there appears to be no discernible difference. In seeing which approach is faster and thus better, I guess we're talking micro-seconds.
The question begging here is this, is there a definitive way in handling or managing the design of this sort of workflow? Page design (HTML, PHP and otherwise), programming and database design all seem to call for differing approaches and yet, have to be "married" in such a way to produce a working and meaningful end result.
This is something I've been check out for a while now. Other than a mass of snippets here and elsewhere, have yet to find a definitive or authorative source on the matter - be it on-line or in print.
[edited by: jatar_k at 9:05 pm (utc) on Feb. 7, 2004]
It is, unfortunately, a very common practice to have the "spaghetti" includes.
The question begging here is this, is there a definitive way in handling or managing the design of this sort of workflow?
Well, definitive might be impossible. The marriage, as you so rightly put it, of many technologies is a very difficult process. I think we try to understand the best practices and the options available for each and then make project based decisions from there. The trouble really is that we don't make the same decisions in each project.
I most often let the final decision come down to what is best for my user. If it doesn't affect the user then I look at which technology will handle a task the most efficiently.
As an example look at the system I work with, we employ php, oracle, mysql, apache, html, js, css on sun and freebsd on a large secure and public site.
This scenario leaves me with decisions of who is going to handle what all the time. We assess each specific enhancement and look at which technology can handle parts of it and then which should.
We also have the issue of classic software development cycles against the fluid web development environment.
All that said you need to understand each language or technology and know its strengths, weaknesses and best practices. You can then make educated decisions and educated comprises, always keeping in mind what is best for the your users as well as your programmers and anyone else involved in the process.
any other thoughts?
I look at this problem from a slightly different angle than jatar_k. I'm the one who manages the code, the websites, and everything other than the customers themselves. So for me it's all about efficiency and manageability.
Boy, those file names sound familiar and I agree - that does seem like a convoluted way of building a CMS. I personally don't like to have more than 1 hop for all of my includes - meaning that my includes are deadends - no hopscotching to other includes. That's personal preference.
However, if you had asked me the same question 2 years ago, I probably would have answered that I don't like any includes! Reason: my experience and comfort level with PHP was far less than it is now. Ask me again in 2 years and see what I say.
My point is that I think it really does come down to your experience, comfort level, and intended users. In my case - I'm the end user so a little convolution is fine - as long as I can keep track of it. But if I were planning on handing the whole system over to someone else to manage, edit, or expand upon - I'd rethink how I built it.
You're right on 2 accounts. On the one point, the above relates to a CMS that I've been faffing about with over the last few months and yes, a case of KISS.
On the other - "as long as I can keep track of it" - is precisely my point. Keep it tight and keep it short.
jatar_k - hi and thanks for opening up this item as a new thread.
As in going back to basics - I think we need to look at the seed (or, maybe in this case, the kernel) before we look at the flower, let alone the tree.
What I'm trying to come to grips with here are the basics and fundamentals of, if not "good design" at least, "sensible design" - page-wise as well as code-wise.
Case in point, I'm trying to set up something to handle 30 or so preference items. How best to do it?
Yes, these items can be grouped. Let's say we have General, Display and Features.
Okay, these prefs are going to be used site-wide. So, what do we do? Each group could have its own page. Thus each page across the site would now carry 3 includes. Or, (wait for it ...), have a top.php or header.php that has those includes and all the other pages call that page.
Could put all this stuff into a database. Here we could serialize the prefs into the database and then unserialize that data when each page calls for it.
Okay, other options could be considered here as well, but let's look at this lot for the time being.
Back to the point - sort of. In all my searches I have yet to find any definitive information on serializing data and its benefits. I mean, how much data can be effectively serialized? Serializing cookie or session data is fairly tame stuff. PHP docs suggest any amount of data can be serialize. Remember this being said about DOS in the days when the biggest HDD was 10 Mb and they had yet to figure in the 2 gig limit. But, does anyone really know at this stage?
Further to the above, which is the more efficient - calling a page or multiple pages as maybe the case here or pulling data from a database?
Yes, horses for courses, but is there any definitive documentation out there where this sort of thing has been effectively reviewed?
Guess what I really want here is to get beyond the "thumb-stuck".
I mean engineers have their Molesworth - a sort of compendium of data. They want to move water from one point to the next. Pull out the compendium look up pipe bores. Okay, a pipe of this bore will deliver water at this rate. Looks good - we'll use this pipe, etc. It ought to be that basic and that easy.
Cez impossible (excuse my French).
A pipe is a pipe whether it be plastic, lead, steel or copper - the flow rate will be reasonable close. Not so for a CMS. Too many variables.
Is there a best practice for determining how far to go, what steps/path to take, or when to stop? I don't think it exists. Each application is so customized that it's very hard to draw clearcut explanations of what should be done. And the core applications I use (LAMP) are open source so I don't expect to see any in depth documentation from research on SOPs.
I think this is where, *cough*, M$ has done a lot of good work in that they do have engineers testing and documenting how to use their products and step/paths that are appropriate for given applications. But then, they have a much larger budget.
The only true test we have is to benchmark performance of the applications we build and to track those benchmarks. I'd be curious as to what our peers think would be a good starting point to develop Best Practices for working with PHP/MySQL.
I agree with lorax, there are always too many vars involved with programs. Things that I make for my own systems are benchmarked, tested and usually I know whether I should make a db call or I should keep something in the session. I know the process time and environment I am working with.
Distributed programs need to be built with a highest common denominator approach. What is the average server cpu, how much ram etc.
I was reading all of your scenarios and all I could think for each one was "It depends on ....."
I think it really does come down to your experience, comfort level, and intended users
well said
I knew you'd correct me. ;)
don't like to have more than 1 hop for all of my includes
Why not? I can think of many situations where I might not want this to be true... To pick just one (or will it be two?):
Let's say I have a config.php which is included at the top of all pages and sets sitewide variables, constants, and so on.
- I want to be able to develop on one server and deploy on another, so if the file local-settings.php exists, include it.
- I want the site interface to be switchable between French, Urdu, Berber and Latin, so I have constants for all text strings
define('NEXT', 'Prochain');
Then in the config file, I have
if ($lang == 1) { include("./langs/urdu.php");}
Anyway, IMO it's not the number of hops that are the problem in the first example, but the illogical and convoluted nature of the hops.
Maybe a new thread should be
Top 100 Signs That I Am Writing Spaghetti Code in PHP
100. I have no idea where this constant is defined.
99. I have echo stmts littered throughout my code.
I'll let others fill in the 98 better signs since I can't think of any right now.
Cheers,
Tom
LOL
Why not more than one hop? Oh I know there may be reasons for it but I don't like the idea - primarily because I haven't developed a good way to handle/track them. And I haven't had need to write an app of such complexity as to require them.
It comes back to comfort and experience. While I think I may be missing out on some places where I could possibly streamline my code - I haven't taken the time to go back and evaluate it and layout a plan for what needs to be done. The few applications where it might help have grown organically and I've upgraded them a bit at a time.
One of these apps is soon to be dependent upon the Amazon XML AWS and I think I'll be forced into learning how to deal with daisy-chained includes. What scares me the most is that with my lack of experience in using them, any poor decisions may not become evident until later.
Est-ce que cela se comprend? ;)
Often with large sites I use an include file. One central list of includes that all the files need. from there if they need a specific file I include that in the script itself. Any site wide constants or db connections can also be done there. I try to be very careful to only include site wide libs though.
Not ....?
Yea I've thought of that but then my desire to keep the server load to a minimum kicks in and I ask why load a bunch of functions the page won't necessarily use?
Of course I keep telling myself I should just learn C++ and compile a set of base functions into the Linux kernal and be done with it.
That's a good one. Nobody else is chiming in here, so I'm going to open this in new thread [webmasterworld.com]....
