Templating

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

arborint wrote:But he misses the filp side that is the power of scripting languages. Most of those open source PHP projects would not exist unless they were very, very, very badly coded.
I entirely agree and have said on other occassions that PHP's popularity is both strength and weakness.

aborint wrote:The key here is that "very, very, very badly coded" is the subjective judgement of some programmers. They will never accept that scripting languages evolved as a reaction to "coding well" for the simple reason that "coding well" is one of the major impediments to, of all things, CODING.

The fact that so many very, very, very bad programmers produce so much very, very, very bad code that is so very, very, very useful is just, just .... infuriating to them. Why? Because they have elevated programming above what it is: a medium to turn ideas into programs.

Christopher
No, I don't have any personal issues with someone who programs. What I care about is my time. And if I get a solution to a problem that's built crappy, I am wasting my time and I am considering if the money spent on a commercial solution wouldn't be worth it after all.

On the other hand, I would expect anyone to strive for becoming better at what they're doing, especially when your work is published to the world, as OS projects are. But it seems that for years now they have pretty much remained at a certain level - I believe it will change in the future. The problem seems to be extremely prevalent with PHP projects. You can download fantastically coded servers, databases, browsers, email-clients, FTP-programs, network tools, data-administration tools, whole office applications and so on. I don't know if they are programmed in a procedural or object oriented way, and I don't care because they work fast, effiently and beautifully. They are indeed successful projects.

It's much harder to come up with an equally impressive list if you start thinking about PHP, even though PEAR is being overhauled and it has a number of very good classes.
I do get the impression that those PHP applications out there are first-generation OS. Projects like Firefox, for example, use an entirely different model, despite being open source. They have enjoyed the backing of AOL/Netscape and set up a foundation dedicated to their products while offering their them for free. Amazing. It seems that this kind of OS business model, where the core product is given away for free rather than created by enthusiasts who are learning about what they are doing as they are doing it, produces much better results.
What I am keen to see is PHP projects that are offered like that. There is, probably the (hopefully not only) shining example of ezPublish - and the company behind it gives it away for free and live off the commercial "halo" around their core product. But what else is there?
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I really agree with you. And I personally have the same motivation to continually improve my programming skills. I also have similar hopes for the professionalism of PHP applications to improve.

I do think apps like WordPress, Coppermine, phpNuke (et al), Typo3 and the much maligned phpBB are like the apps you mention. Like it or not, phpBB is so popular that is was targeted by hackers. That's one indicator of success.

I think my point was that PHP allows programmers to produce sopbisticated apps, AND it also lets essentially non-programmers create useful apps as well. Those two groups should not be judged by the same standards. Nor should they criticize each others code for being too elitist or too poorly written.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

arborint wrote:Those two groups should not be judged by the same standards. Nor should they criticize each others code for being too elitist or too poorly written.
I agree, but then started to think: "No, actually, unless they learn, PHP apps will stay at that level. If I think they do something wrong, I should voice my opinion, contribute and participate in the project and see whether I'm right or wrong about it all." My problems with that is that there are many projects and I don't have the time.

On the other hand: that's the way PHP itself has grown into what it is now: excellent. So, yes I agree, voting with the feet (or rather, installations) works. However, as McG has pointed out, if phpBB had applied unit testing (if possible), XSS-attacks could have been avoided - and that's the kind of headache people want to avoid. I've recently read somewhere that on average programmers used to spend about 20% of their time on maintenance and 80% of it on developing and implementation a good ten years ago. Nowadays the figures are reversed. Yes, it shows that PHP is, of course, not the only language in which you can produce crappy code, but it also means that crappy coding ties down innovation potential by using up way to much time. Imagine you buy a car and it's has to be serviced a tad over 19 hours every day.

I am only just grasping what big projects involving many people (and not just programmers) really are and unless it's very well co-ordinated, it'll bite the dust sooner rather than later and becomes very expensive.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Again, my point is that for those who are essentially non-programmers the goal of "unless they learn, PHP apps will stay at that level" really doesn't matter. Our goal may be to keep moving to the next level, but that does not mean it is everyone's goal.

Also: if phpBB had applied unit testing (if possible), XSS-attacks MIGHT have been avoided.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Aren't you two getting a bit off topic? patrik want to split it? :)

Theory seems like a good place as any..
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

I guess we are getting off topic. ;) If you think it's necessary to split the topic, do - I find the genesis of the discussion quite interesting, but that might be just me. ;)
User avatar
PHPadvisor
Forum Newbie
Posts: 11
Joined: Mon Dec 13, 2004 3:20 pm

Post by PHPadvisor »

Back to the issue of templating...

I think this is something that can be over used by many enthusiastic programmers.

If you have a function that spits out for example a success/fail message like this:

Code: Select all

if ( something){

   echo('<b>Insertion complete. Please proceed to blah blah</b>');

&#125;else&#123;

   echo('<b>Error Inserting, please try to blah blah blah</b>');

&#125;


And this is in a function that is organized sanely in a library of functions... I have seen many programmers who are so in love with html and php seperation that they will do this (or something similar):

Code: Select all

include('/lib/output/messages.inc.php');

if ( something)&#123;

   echo( $my_output_library&#1111;'insertion success 1'] );

&#125;else&#123;

   echo( $my_output_library&#1111;'insertion fail 1'] );

&#125;
---------------------------


This is excessive. If your code is well organized, then there is no point in seperating all html. This really only is a good idea if you are likely to require multiple language support. When I read through that code, I do not want to have to hunt for another file to find out what the message is that is being output.


On the other hand, php templating that seperates the layout code from the main pages with something like a header and footer file included into each page or reused html chunks are better to have seperated. But absracting one time use html strings is excessive except for multi-language support.

This is expecially true if what is being developed is basically an HTML website with some php features attached.

However in the case of a huge php application with a (relatively) small amount of HTML output.... it can be a good idea.

It depends on if you are putting php into html or the other way around.
:roll:

Some concepts that are called 'good practices' should not be blindly applied. Especially when for most commercial projects, everything must be weighed against total project development time (cost).

Always ask:
Does it make sense in this situation? Will it save more time in the future than it will cost now? Am I doing it just because I heard that it is 'what good programmers do'? How will it benefit THIS project?

---
This post is getting rather long so let me just explain an experience I had. I took over the care of a project done by the programmer who had my job before me. He made a kind of CMS/ecommerce system that would be basically a drop in for any site. It would do all sorts of great stuff all organized into modules. Great right?

No.

Everything was abstracted away 3, 4, 5 levels deep! It was hard to find where things were truely defined. Some strings were stored in a database and somethings not. For example the copyright for the bottom of each page would source the company name from one database (ok, that's good) and the date from another database table! Why?? A simple call of date("Y") would have done the trick.

And that was just the smallest of examples. It was insanely hard to get more than a general high-level idea of what the program does, because everything was a scavenger hunt to find included files and functions and data sourced from config files and databases mixed with hard coded crap and language files and more.

The main webpage called some 'super' functions like display_cart(). Hunting down that function in a library finds that it uses smaller functions like show_total() and display_items() sourced from another library file. These use database functions from somewhere else and currency and language functions from another location. Then all the text was sourced from a language file, and sometimes from the database. Took forever just to find out what display_cart() actually did and how it did it. Excessive. If all that code had been put together it would have amounted to about 15 lines!

The moral of this big long post... sometimes abstraction can make things worse - don't apply it blindly because you love the idea. Organization and documentation is sometimes more important than abstraction.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I go for total seperation when the medium being output is in question, like XML vs HTML or other languages entirely. For me, it's better to have a central location where all the "text" type data is, instead of having to dig through lots of code to find them. This is especially true of international support.
magicrobotmonkey
Forum Regular
Posts: 888
Joined: Sun Mar 21, 2004 1:09 pm
Location: Cambridge, MA

Post by magicrobotmonkey »

Yea, at my job we just went through hell trying to implement multiple language support for our product. We used templating to allow use to display in multiple languages, but we tried to make it too flexible (mostly through abstraction) and it ended up being a nightmare. We were pulling plain text from three different places: template files, the db, and these core linux language files that required an apache restart each time they were changed. Now as we try to move developers over to the new system the learning curve is incredibly steep because everything is buried under all these layers. I have been working with it for a couple of months and still find myself spending hours trying to find out where this one $#%# variable is set.

The lesson I took away from it is that sometimes you may have to sacrifice some flexibility in order to get the required functionality without shooting yourself in the foot.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

still looking if i find some time to try something like:

php -> xml -> cocoon (i18n) -> xsl -> xhtml

have to test if it works,
have to test how it performs,
have to test if i don't prefer gettext solution ;)
Post Reply