Page 2 of 2

Posted: Thu Jan 22, 2004 3:45 am
by lazy_yogi
That's fair enough

Tho from what I can see, the forms class seems to have a very good interface. I'd be curious what reason someone would have for not using that and deciding to make their own.

Posted: Thu Jan 22, 2004 4:53 am
by McGruff
lazy_yogi wrote:Sometimes bloat is necessary to give full functionality
It's always possible to split a too-large object into smaller objects. Bloat might impair functionality by making it difficult to throw objects together in new ways - that's much easier with tightly designed classes built with RDD in mind. Eclipse is a good example of that, I think.

Posted: Thu Jan 22, 2004 10:10 am
by BDKR
patrikG wrote:I have nothing against using other's libraries - I am using a couple, depending on the application I am developing.

Regarding PEAR: I was looking for a template class quite some time back and had a look at every singe PEAR template package (and yes, even Smarty). Each and every one of them was way too cumbersome and bloated - so I decdided to write my own. It's about 120 lines of code - slim, simple and very easy and straightforward. Yes, it took more time, but it was more fun and I've learned a great deal in the process.

What I found with PEAR in particular (that was some time ago), was that the classes tried to do too much which shifted the focus from what the class was actually meant to do, while the API wasn't clearly thought out at all. Hence the functionality and code was bloated, complicated.
Thanx for describing the issue with PEAR in such a clear and concise manner. This is what I felt when I mentioned PEAR earlier, but could't get out.

Cheers,
BDKR

Posted: Thu Jan 22, 2004 10:53 am
by jason
My Latest, and probably most official opinion, on Templates in PHP

Templates written in PHP are for the most part the way to go. For me, it's really that simple. There are several reasons for this, and they all stem from some simple ideals.

First, using PHP as your templating engine means you don't have to maintain an engine. If you build your own templating engine, you have to worry about not just writing the engine, but adding the needed functionality. All template engines follow this trend. They start of simple, and then they grow. Suddenly, you need simple things, like some form of LOOP functionality, or and IF statement. Maybe you want to make an easy SWITCH command. And then you need to include other files into your template engine. And then you have sub-templates, etc. It can be a headache to program all that.

And even if you aren't programming all that, and you are using something like Smarty, well then you are in a different situation entirely. Now your relying on a third party package to do your templating for you. And suddenly, you need a new feature. You have to learn how to extend that third party package. And then extend it, and modify it. But when the third party package upgrades, there is a chance your modificaiton no longer works.

A custom template engine provides many beneifts, or so it seems. First, their is the example that it's easier to write for template engines than it is to write PHP.

That {PrintMe} is easier than, let's say, <?=$PrintMe?>. And for a long time, that may have been the case. People suggest that the limited scope of the template engine makes it easier to learn. But I have seen people on both sides of the debate make claims either way: every person knows a designer who either a) doesn't know PHP and doesn't want to learn and doesn't understand <?=$PrintMe?>, but understands {PrintMe} or b) knows the basics of PHP, can do the loops and what not, uses <?=$PrintMe?> without a problem in software like Dreamweaver, and doesn't understand what the problem is.

There is a commonly used argument by Pro-PHP (PP) Templaters that the Pro-Custom (PC) Templaters are mistaken in trying to seperate PHP from HTML. They suggest that the PC really want to seperate the logic from the display, and that PHP is perfectly suited for the task.

They are half right. The PC really know what they are doing in that they want to seperate the logic from the display, and in that, the PP are wrong. But with regards to PHP being perfectly suited for the task, that is true.

I value my development time. And my development time should be spent creating applications, not tools that help me build applications when other toosl already exist. I can write my own template engine (and I have done so), but that doesn't mean I want to write one. I dont' want to maintain it. I want to just write software. I don't want to have to download something like Smarty, install it, make sure everything is working, and then learn how to use it. And then learn how to create addons for it. And learn what it can and can't do. And then find out that what it can't do, I have to addon.

Not when PHP does most of this for me out of the box. The idea here isn't that templates are bad. They are good, very good things.

My ideal platform for templates now is PHP. Carefully crafted PHP, so that it only handles the output. It doesn't actually do any real business logic, but rather, it works to display the output. My interface that I use for the business logic looks just like your typical template interface. I assign variables to the template, and then call a display method. The templates, in this case, just take the variables, and then performs the actions that are necessary.

The whole reason behind all of this is to say that while template engines can make easy things easier (like alternating colors in a table), it can make the more difficult things harder. For a simple site, your typical template engine would probably be just fine. But when you are doing serious work, you might want the added control of a complete system. And PHP is that complete system.

With all the discussion over which way is best, it can be a headache discovering this on your own. My own adventures in the world of templates have taught me one thing: It's easier to a large system and make it small (PHP as a template engine), than it is to take a small system and make it large (Customer template engines). When you need the added capabilities of PHP for just one area, being able to carefully craft your requirement becomes a major-boon. I find that with custom template engines, you are limited by the capabilities of the template engine. If a template engine makes something difficult to do, it's less likely you are going to do it.

I currently use PHP as my template engine, because I enjoy the fine-tuned control I can have over how my output displays, and what that output can do. It's much easier for me to take something, and make it good using PHP, than to try and work within the confines of a custom template engine. Custom template engines are not bad, nor are they useless. However, when it comes down to it, they are highly limited when compared to something like PHP.

Disclaimer: You should note this is just my thoughts on the topic. This is not intended to start a "Template Engine War". These thoughts are merely based on my experience with template engines, in both using third party engines, custome built engines, and PHP as the template engine. There, maybe I covered myself. =)

Posted: Thu Jan 22, 2004 11:03 am
by BDKR
lazy_yogi wrote:That's fair enough

Tho from what I can see, the forms class seems to have a very good interface. I'd be curious what reason someone would have for not using that and deciding to make their own.
There is nothing wrong with the interface as far as I'm concerned. However, to accomplish the smaller interface, some algorthmic overhear is incurred (sound intelligent? :P ). A simple addElement method is cool, but the method has to figure out which element it is you want (you do tell it via an argument) as oppsed to something like

Code: Select all

$form->addTextArea();
This does mean that the interface grows in size, but it also makes for a more effecient core.

Something that patg made reference too was Eclipse. I still use (at times) the earliest version Eclipse (I prefer it's architecture to the newer release of it and Eclipse CE). It's a small and tight framework with little in the way of overhead as well as also being exceptionally small internally.

As opposed to Quick Form, which really is rather large. Parse time really must be considered. Most shared hosting environments are not using accellerators so the overhead of parsing QuckForm.php, PEAR.php, and Common.php will be incurred at each script run. With classes this large, I wouldn't be suprised if the parsing phase accounts for 30 - 40% of the overall execution time.

Yeah...., the more I look at it again, the more I see that it's really making a mountain out of a mole hill.

Cheers,
BDKR

Posted: Sun Jan 25, 2004 5:46 am
by patrikG
I agree with you Jason that for pure server-side templates, PHP is probably the best solution. After all PHP started off as a templating language – creating a templating engine with a templating language is somewhat silly (e.g. Smarty – they seem to be developing another PHP with a different syntax).

Where templating engines do make sense, however, is for front-ends. Here’s the scenario:
One service I am offering is quick and simple websites maintained through a CMS incl. online HTML editor. Some ‘premium’, HTML-savvy users can also upload their own templates. Something I do not want to them to do is include real code in that template, so PHP is out of the question. Hence my need for a templating engine.
I don’t want them to create dynamic pages – the users edit the content with the CMS which writes static HTML pages to the root directory of their subdomain. I retain full control over anything dynamic.
jason wrote:They start of simple, and then they grow. Suddenly, you need simple things, like some form of LOOP functionality, or and IF statement. Maybe you want to make an easy SWITCH command. And then you need to include other files into your template engine. And then you have sub-templates, etc. It can be a headache to program all that.
That was exactly my problem with the PEAR classes as well as Smarty. They tried to do too much and complicated things unnecessarily, simply because they were poorly though out or tried re-inventing the wheel.

That was where the need to write my own template class came from - which does exactly what you’ve outlined above: you can have nested IF-statements and loops. The code is still very simple and straightforward, does everything I need and is around 120 lines long. Three methods: one checking for IF statements and loops, one replacing the template-tag with the respective value, one calling the above two functions.
You pass an object to that class and if the respective value (e.g. {!myContent!}) exists, it will be replace with the respective propertry (e.g. $myClass->myContent).
I have no need to extend the class as it has all the functionality I need and want.

But what I do need, because I can’t have users submit their own PHP code, is to separate the logic and functionality of PHP from the presentation. This is only necessary for front-end templates otherwise, as I said above, PHP is the definitely best solution.

PHP has grown tremendously since it started and has become a proper computer language (well, some will argue that only PHP5 with its proper OO implementation etc. can be considered ‘proper’). There’s no need to re-invent the wheel, but there are cases where template engines make perfect sense and are indeed necessary.

Posted: Sun Jan 25, 2004 9:01 pm
by BDKR
lazy_yogi wrote: Not only that, it's been designed well, ...
Just because it exists and is used doesn't mean it's well designed.
lazy_yogi wrote: Why you would want to waste time and effort doing something that's been done and is available to you is beyond me, when you could spend time working on something else and be productive instead.
This really depends on if something that is well designed exists in the first place. If it is, I agree with you. If not, get hackin!

Cheers,
BDKR

Posted: Wed Feb 11, 2004 8:48 am
by Tanus
Bumping a dead topic, but I was in a similar boat to the initial poster; I got sick of doing forms the old way, and while quickforms is good, it annoyed me quite a bit too. I'd been using C# quite a bit, and loved being able to make a quick form up with that and have it right there. So I used #Develop, took it's form designer, and wrapped some conversion code to create PHP classes that encapsulate forms designed in #develop and elements within them. At the moment the code is a bit bloated, as it started out as a proof of concept and is being refined as much as possible now that I've got some proper use out of it, and reading through a few forums have quite a few ideas for making it a lot more efficient, less strict on it needing to be a complete framework, and things like templating etc. ( http://webpanels.sourceforge.net if you're interested )

Like what other people have said, I find a lot of the time that if I don't find something that suits my needs I'll go out and code like crazy to get something that does; sometimes it comes out good, sometimes it doesn't and you have to go back to a more tried and tested way of doing things.