osCommerce should use a templating system

[♥FWR Media]

I never thought that PHP doesn't do the job, I just figured it doesn't do the job well enough, and I've given my reasons both here and on the website. More importantly than that, I've never seen an application of PHP templates that seemed to strictly display using logic, while SUIT's logical statements are specifically used for formatting data and nothing else. That might not be a sufficient enough reason to use SUIT for you, and that's your opinion. However, I sure hope that you don't want to "conclude" your part of this discussion simply because of a negative episode of posts. I'm sure that if you looked at more of the material on SUIT, you'd have several interesting points to contribute, and I'm open to criticism as SUIT was essentially built off of it.

 

 

[unconclude]

Yours is an open source project and has obviously taken a lot of time and care to produce.

 

I have taken a long(ish) look at the site and probably will do so again. I think all projects of this nature should attract credit where credit is due. I have stated my feelings openly but it was certainly not my intention to belittle your hard work whether I choose to use it in future or not.

[/unconclude]

[BrandonE]

[unconclude]

Yours is an open source project and has obviously taken a lot of time and care to produce.

 

I have taken a long(ish) look at the site and probably will do so again. I think all projects of this nature should attract credit where credit is due. I have stated my feelings openly but it was certainly not my intention to belittle your hard work whether I choose to use it in future or not.

[/unconclude]

Note that you quoted bkellum. By all means, do not think that I thought you've posted anything but helpful and respectful feedback.

 

Edit: Err, it seems you corrected that. My point stands.

[Mark Evans]

Please ensure your discussions focus on the subject at hand which is templating systems and not continue down this path that this thread seems to be heading.

 

Templating is a touchy subject and there are valid reasons for and against template engines at all, and also valid reasons for and against different template engine implementations. I personally can't see myself using SUIT however that doesn't mean its not a good solution, just as others think that STS, Smarty, PHPTal, PHPTemplate etc etc are all valid for their own solutions, the whole point about open-source is freedom, so use whatever template engine you like, with 2.2 this is quite hard to do and does require a lot of modifications to the core code, who knows though maybe for 3.x the template engine could be pluggable so any template engine could be used easily :thumbsup:

[uramagget]

No it shouldn't! template systems should stick to what they are .. display and layout .. what is fed into them and security is the job of the application.

 

You don't need a template system to auto escape or otherwise sanitise user data.

 

The controller should never return any mark-up whatsoever; just raw data for the templating to process. Since HTML filtering is relevant to displaying data as well, there is no reason why templates should not be handling this. You can forget to escape your strings, but by default in SUIT you can never forget to escape safe data. It's easier to have a whitelist than a blacklist, which is a case that PHP templating does not follow to the margin when faced with SUIT's facilities.

 

You do need a templating system; you just don't know it yet. ;)

 

Anything is easily addressed but .. as in your case .. addressing does not mean answering.

 

Whatever minor logic control your system has it is not within a million miles of the power of PHP. Display logic can be very complex in these times of complex web sites why would I use a system with such restricted power when I have PHP?

 

Nothing naive about me matey! powerful languages with powerful functions need to be used with the propper care.

It is ridiculous however to suggest that one stops using powerful languages and return to the dark ages simply because some developers write insecure code.

 

And your chosen subject on Mastermind will be the screaming bl@@dy obvious!

 

So what!! what do we do? return to non dynamic HTML? Of course we don't. It doesn't matter a jot how secure you believe your template files are .. the rest of the application files will still be PHP ( or any number of others ).

 

Loads ( as I mentioned previously ) PHP is enormously powerful and getting richer all the time, it is an excellent and versatile language

which can lend itself extremely well to a variety of different templating methodologies with little in the way of restriction.

 

That's a bit of a stretch. I was not saying that people should stop writing dynamic websites simply because application code can be insecure, but that people should stop treating PHP as a Swiss army knife, especially in the case of templating, which it does not do all that consistently and well. Using templating (SUIT in particular) does not mean throwing away the flexibility that you have at your disposal when it comes to making dynamic websites. The very fact that "PHP is enormously powerful" is the exact reason why you should not be using it as a substitute for templating when it is suited for writing controllers and other application logic. SUIT is not limiting in any fashion, and nothing stops you from using the [call /] or [transform /] rules to take advantage of PHP's "flexibility" as you describe it without all of the security issues surrounding that method.

[bkellum]

Note that you quoted bkellum. By all means, do not think that I thought you've posted anything but helpful and respectful feedback.

 

Edit: Err, it seems you corrected that. My point stands.

 

 

I don't see where he quoted me at all?

[bkellum]

Please ensure your discussions focus on the subject at hand which is templating systems and not continue down this path that this thread seems to be heading.

 

Templating is a touchy subject and there are valid reasons for and against template engines at all, and also valid reasons for and against different template engine implementations. I personally can't see myself using SUIT however that doesn't mean its not a good solution, just as others think that STS, Smarty, PHPTal, PHPTemplate etc etc are all valid for their own solutions, the whole point about open-source is freedom, so use whatever template engine you like, with 2.2 this is quite hard to do and does require a lot of modifications to the core code, who knows though maybe for 3.x the template engine could be pluggable so any template engine could be used easily

 

I am in total agreement with the above statement.

[bkellum]

To Brandon and Urramaggot...

 

 

Listen, I don't like the way this thread has gone and I'm sure you don't like it either (I hope anyway).

 

I would like to apologize for making any comments that sounded like an attack to you personally. That is not my style and I hope that if we meet somewhere on this Earth that we could shake hands and talk about all of the good things that osCommerce has done and could do and even bring in SUIT to the discussion.

 

Obviously, we are all very passionate about what we do. I have always tried to respect other people's work and I don't want some long 2 day thread to change that.

 

I am sure SUIT is very robust and can do the job that you are saying it will. No debate here. I have never claimed that STS was designed to be integrated into the core code in a way that SUIT would need to be, total separating design from function. I think this is where we got off track.

 

STS is a very nice solution for the CURRENT state of osCommerce RC2a. I truly feel that SUIT would be a suitable soluction for osCv3. I have always felt that but the emotional, passionate posts have hiddent that.

 

I will be honest and say that yes, deep down inside I am hoping for a nice template option for osCv3 that is very easy for the designers and highly functionable and flexible. I know I said some comments earlier in the thread asking you guys to take this elsewhere but please forgive me for that.

 

I am also being honest when I say that STS should not be compared to SUIT, not because one is superior to the other but because it isn't really comparing apples to apples. STS is a good solution for an old code base. I will be the first to agree that STS is NOT the solution for osCv3, but, osCv3 is in need of a powerful template engine in my humble opinion.

 

When going forward, please keep in mind that not everyone is on board to being "forced" to use a template engine. I am not about to begin to tell you that I have the soluction for that but I do believe if we put our heads together we can come up with something that will please both sides.

[burt]

Interesting thread. OK, can we get some reality back to it;

 

We need to define "templating". Bill well knows my views on STS. Opinion: It is NOT a solution that should be used on a production website, it is simply not needed. Here is an example why not. Index page, 25 Category Pages, 500 Product Pages. All different. This needs over 500 seperate themed files! I actually worked on such a site when I had to give a one on one tutorial to a designer who had been thrown in at the deep end with an osCommerce shop along with STS. I couldn't believe that someone (previous to this designer) had created hundreds of files which were all similar but showed a few things differently! STS is not a templating system, it is a way to change the theme. That's it. Templating and Themage are linked but are not the same thing, this appears to have been a problem within this thread...

 

So... we need to look at who is talking about templating, and who is talking about themage.

 

I have no experience with SUIT. I offered earlier to help with it's implementation and that stands as I would like to see what can be done with it. Done on github, there is no reason why it could not then be taken into the core á HPDL at the press of a button.

 

Note that I am "old school" and prefer to write PHP code. Not pseudo STS code and not pseudo SUIT code. However I strongly agree that osC needs to separate logic from presentation. STS does not do that. SUIT does (well, as far as I can make out, having not made much out yet). There is the difference.

[BrandonE]

I am also being honest when I say that STS should not be compared to SUIT, not because one is superior to the other but because it isn't really comparing apples to apples. STS is a good solution for an old code base. I will be the first to agree that STS is NOT the solution for osCv3, but, osCv3 is in need of a powerful template engine in my humble opinion.

That's the thing. I repeatedly mentioned that STS didn't seem to do what SUIT was, because it didn't seem to have the same mission, and you seemed to get offended by this. It was Jan who originally mentioned your program, and with a name like "Simple Template System", that's a pretty simple misunderstanding. It obviously has an array of completely unrelated features. If you don't think these features would be necessary for osCv3, well, ok, we'll (Well, at least I'll) refrain from mentioning it in the thread. I'm pretty sure Arnold was planning on writing this for osCv3 anyway.

 

As far as being forced to use a template engine, like you said, SUIT would need to be integrated into the core code. There's really no way it could be turned into an add-on. Regardless of what template engine that would be used (SUIT, Smarty [Please no], or just PHP used properly), it would have to be integrated into the core, and whatever the engine we decide is the best at what it does (I'm confident we can all just discard Smarty right here and now), I strongly recommend osC has one. I figure it this way: you're either forced to have a template engine, or you're forced to modify the core. I think the former is the lesser of two evils.

 

Again, I have no interest in holding a grudge. I've taken a huge amount of criticism from various people on SUIT, but from it, I improved it vastly, and I can defend nearly every line I wrote of it. I understand what it feels like when you think people are attacking something of yours, but they're not.

[♥FWR Media]

SUIT would need to be integrated into the core code. There's really no way it could be turned into an add-on. Regardless of what template engine that would be used (SUIT, Smarty [Please no], or just PHP used properly), it would have to be integrated into the core

 

That's interesting Brandon, Zend Framework can use template systems like ( sorry to swear at you as it is obviously a disliked competitor ) Smarty which you set as the view .. the view can then be passed into the layout ( if using the two stage system view / layout ).

 

Any reason why yours would differ in this ability?

[bkellum]

Interesting thread. OK, can we get some reality back to it;

 

We need to define "templating". Bill well knows my views on STS. Opinion: It is NOT a solution that should be used on a production website, it is simply not needed. Here is an example why not. Index page, 25 Category Pages, 500 Product Pages. All different. This needs over 500 seperate themed files! I actually worked on such a site when I had to give a one on one tutorial to a designer who had been thrown in at the deep end with an osCommerce shop along with STS. I couldn't believe that someone (previous to this designer) had created hundreds of files which were all similar but showed a few things differently! STS is not a templating system, it is a way to change the theme. That's it. Templating and Themage are linked but are not the same thing, this appears to have been a problem within this thread...

 

So... we need to look at who is talking about templating, and who is talking about themage.

 

I have no experience with SUIT. I offered earlier to help with it's implementation and that stands as I would like to see what can be done with it. Done on github, there is no reason why it could not then be taken into the core á HPDL at the press of a button.

 

Note that I am "old school" and prefer to write PHP code. Not pseudo STS code and not pseudo SUIT code. However I strongly agree that osC needs to separate logic from presentation. STS does not do that. SUIT does (well, as far as I can make out, having not made much out yet). There is the difference.

Wow Burt! That's just ridiculous.

 

He could have easily written code to stick with just a few templates to accomplish the same thing. I have never heard of anyone making that many template pages. Typically, just a few pages would suffice any store. But, then again, if you don't know PHP, at least you are not locked out of using osCommerce.

[MrPhil]

We need to define "templating".

...

we need to look at who is talking about templating, and who is talking about themage.

Good point. I can see the upside to creating a consistent look and feel across a site, along with a cleaner development effort, with just a few template/theme files, but worry about the downside of extra execution time to first create the PHP, which is then actually executed, every time it runs. That sounds like what is souring many people on using templates.

 

What about this: you use a system that permits you to template/theme to your heart's content, editing just a few files to change the look and feel. Then, when you're happy with your system, you "compile" it down to static PHP scripts. They may have ugly looking code, but you're not supposed to be editing or even looking at the resulting code. This is like running a BASIC interpreter for your accounting system development, then compiling and linking to a nice fast .EXE file for production, as opposed to running production with an interpreter, or writing in Assembly Code in the first place. The best of both worlds. Once you're not making frequent changes, you lock it down to a fast-executing form. It sounds to me like it would make both camps happy -- development is easy, because of templates, while (production) run-time is fast because it's nice static code. You could even start with a current templating system like SUIT, and write a SUIT-to-PHP compiler that emits static PHP code. What thinks ye? Would this be feasible? Done right, "theming" might then just be a matter changing the CSS (with a Web-based editor) and not touching the PHP at all.

[uramagget]

That's interesting Brandon, Zend Framework can use template systems like ( sorry to swear at you as it is obviously a disliked competitor ) Smarty which you set as the view .. the view can then be passed into the layout ( if using the two stage system view / layout ).

 

ZF follows the MVC pattern, so it would be trivial to implement any third-party solution into it. However, we are not discussing ZF; we are discussing OSC, which by chance, does not follow the MVC pattern, therefore making the integration of third-party solutions rather difficult by definition. You cannot address such a large problem with plugins/modules; integrating SUIT to work perfectly with OSC would require going into some core files anyway, so why not just go all way?

 

@bkellum, I think the best choice would be to just not discuss STS. However, since you agree that SUIT would probably be a better solution for OSCv3, we welcome any help/contributions you have to offer once I setup the github repo.

[BrandonE]

Good point. I can see the upside to creating a consistent look and feel across a site, along with a cleaner development effort, with just a few template/theme files, but worry about the downside of extra execution time to first create the PHP, which is then actually executed, every time it runs. That sounds like what is souring many people on using templates.

 

What about this: you use a system that permits you to template/theme to your heart's content, editing just a few files to change the look and feel. Then, when you're happy with your system, you "compile" it down to static PHP scripts. They may have ugly looking code, but you're not supposed to be editing or even looking at the resulting code. This is like running a BASIC interpreter for your accounting system development, then compiling and linking to a nice fast .EXE file for production, as opposed to running production with an interpreter, or writing in Assembly Code in the first place. The best of both worlds. Once you're not making frequent changes, you lock it down to a fast-executing form. It sounds to me like it would make both camps happy -- development is easy, because of templates, while (production) run-time is fast because it's nice static code. You could even start with a current templating system like SUIT, and write a SUIT-to-PHP compiler that emits static PHP code. What thinks ye? Would this be feasible? Done right, "theming" might then just be a matter changing the CSS (with a Web-based editor) and not touching the PHP at all.

You're implying that SUIT compiles to PHP, but are upset that this would happen every single time. Neither of these things happen. I considered writing a compiler, but I figured the way SUIT works, this is completely useless. Let me summarize how it works, and perhaps then you'll have a better view of it.

 

1. A user provides a string (The template contents) and a list of rules that define the syntax.

2. SUIT finds every instance of a special string in the template (Ex. [var], [/var]) and stores them in an array. This array contains tokens.

3. SUIT then matches these tokens together to create a parse tree. This shows which strings and statements are in other statements.

4. Finally, SUIT walks through each of the nodes of the tree and sends the contents to a PHP function which handles the data and returns the transformed contents. After replacing the original statements with this return values, the document is transformed.

 

The only real overhead is in the 2nd and 3rd step. After all, breaking down a document (parsing), takes extra time. The fourth step, we could all agree, works as fast as the PHP functions that handle the data, and that's up to the user-defined rules, of which the ones suitframework.com provide seem fairly efficient. As such data handling would have to be done anyway, this step is negligible.

 

So, how do we eliminate the overhead of steps 2 and 3? Simple: SUIT stores all of the tokens and parse trees in an array so that if the same parameters are given, it doesn't need to search for tokens or parse the document, but merely work off of the cached values of each. Now, if you JSON encoded this array after finishing the page, wrote it to a file, then loaded and decoded it on the next run, all of this overhead is eliminated. SUIT will only have more overhead if a new template or new syntax is provided, and after running through all of the different pages, this simply won't happen.

 

Does this eliminate your concerns? We thought about this issue a lot, and it seems like this solution does sites justice. By the way, like the avatar. ;)

[Mark Evans]

As far as being forced to use a template engine, like you said, SUIT would need to be integrated into the core code. There's really no way it could be turned into an add-on. Regardless of what template engine that would be used (SUIT, Smarty [Please no], or just PHP used properly), it would have to be integrated into the core, and whatever the engine we decide is the best at what it does (I'm confident we can all just discard Smarty right here and now), I strongly recommend osC has one. I figure it this way: you're either forced to have a template engine, or you're forced to modify the core. I think the former is the lesser of two evils.

 

There is no reason why the template engine couldn't be a pluggable engine which is abstracted from the core so wouldn't require any touching of core code to switch between them.

[burt]

Another point of view to bring to the discussion;

 

[burt]

Wow Burt! That's just ridiculous.

 

Agreed.

 

He could have easily written code to stick with just a few templates to accomplish the same thing.

 

Indeed! The site devolved from STS to standard rc2 or 2a. Then 2 or 3 (I don't remember the exact details) php "switches" replaced the hundreds of theme files.

 

I have never heard of anyone making that many template pages. Typically, just a few pages would suffice any store. But, then again, if you don't know PHP, at least you are not locked out of using osCommerce.

 

The point being he did not know PHP and the STS gave him the over-confidence to do what he thought was right without delving into PHP or even touching the sides of osCommerce. It is this exact reason why I dislike STS so much - in other words one of it's greatest strengths (no need to know PHP and/or osCommerce) is also its very worst weakness (users think that they are experts at changing osCommerce).

[BrandonE]

There is no reason why the template engine couldn't be a pluggable engine which is abstracted from the core so wouldn't require any touching of core code to switch between them.

Err, yes, there is. Here's a snippet from the file uramagget linked to:

 

<base href="<?php echo osc_href_link(null, null, 'AUTO', false); ?>" />

 

The purpose of SUIT would to eliminate things like this from happening in the core. If this isn't considered "core", that means that a core file is including this. If that's the case, the inclusion would have to be removed and replaced with a statement that loads the template, translates it, and prints it.

 

I know very, very little about osC, but I know the nature of template engines, and in general, they are integrated into the code so the markup can be separated from it. Even if it didn't have to be, it doesn't make much sense to me to enable / disable a template engine, and I couldn't imagine what insane workaround would have to be done to do so.

 

Again, I'm assuming a lot about osC.

[uramagget]

Another point of view to bring to the discussion;

 

 

Would you care to elaborate more? We are discussing templating engines.

[Mark Evans]

Err, yes, there is. Here's a snippet from the file uramagget linked to:

 

<base href="<?php echo osc_href_link(null, null, 'AUTO', false); ?>" />

 

 

3.x is still in development so there is no reason that templating couldn't be pluggable, we just need to come up with a way that is flexible enough to work for multiple template engines, people like to use what they know and I think limiting people to just a single engine could be short sighted and isn't necessary IMHO.

 

Out of interest, do you have any performance statistics for SUIT? I would be interested to see how well it scales to high traffic sites

[bkellum]

Agreed.

 

 

 

Indeed! The site devolved from STS to standard rc2 or 2a. Then 2 or 3 (I don't remember the exact details) php "switches" replaced the hundreds of theme files.

 

 

 

The point being he did not know PHP and the STS gave him the over-confidence to do what he thought was right without delving into PHP or even touching the sides of osCommerce. It is this exact reason why I dislike STS so much - in other words one of it's greatest strengths (no need to know PHP and/or osCommerce) is also its very worst weakness (users think that they are experts at changing osCommerce).

 

Hey Burt,

I'm trying to keep STS out of the discussion until SUIT developers have a good opportunity to provide their case but you bring up a good point regarding the PHP code. I'm looking into a backend interface (in the Admin of osC) for STS users to select common switch snippets of code to handle these issues. This then would be inserted into either the template page of choice or the actual PHP script (index.php).

 

Currently, the designer has the option of inserting PHP directly into the template, create a new module or create a tag in the sts_inc modules (similar to SUIT Rulebox) to handle this, but if they do not know PHP, then of course, this doesn't help them much. Like mentioned above, STS still doesn't leave the unlearned out by allowing them to do something as drastic as the scenario you described.

 

I agree that logic needs to be separated from presentation but there are times, as noted above, where the two overlap and have a diverse effect on the other. How should (or should not) a template engine handle such a situation? For example: A one column layout definitely effects the presentation (look and feel) of a site compared to a 3 column layout. The same goes for how a page that displays a "Free Shipping" image and possibly a "text blurb if the user has selected the PayPal option" will look like compared to a page that does not display these items. This is where a programmer and a designer often bump heads. One is focusing on pure functionallity (logic) while the other is focused on what the site looks and feels like (presentation). This is why STS jumped on board to try to mend the gap between the two groups. Unfortunately, it could create Burt's scenario.

 

Brandon,

How does SUIT handle a situation where the designer needs to add some functionallity but does not know PHP? To help with this, let's say the user wants to have just the home page show an image (image_1) or specific text (text_string_1) but have a different image (image_2) or text (text_string_2) in just the "New Products" page? Or maybe they just want to have a 1 column layout in category_3 but a 2 column layout for category_10 and category_12 and all other categories would be a 3 column layout?

 

The above could be easily worked out with very basic PHP code but if the point is to not have the designer inserting PHP code, how would SUIT handle this?

 

By the way, I feel I need to mention that I am asking this in an honest and helpful manner. All of us working together for the greater osCommerce.

[BrandonE]

3.x is still in development so there is no reason that templating couldn't be pluggable, we just need to come up with a way that is flexible enough to work for multiple template engines, people like to use what they know and I think limiting people to just a single engine could be short sighted and isn't necessary IMHO.

I mean, if you have an idea how to make it pluggable, I'm all ears, but I'm pretty sure that's a really unconventional thing to do.

 

Out of interest, do you have any performance statistics for SUIT? I would be interested to see how well it scales to high traffic sites

Honestly, I've spent much more time developing and coming up with ideas for SUIT than benchmarking it. In fact, I've never actually measured the speeds, but merely compared how fast it runs to pages running on something else or without a template engine. It seems to virtually cause no difference in the speeds. If you or someone else would like to properly benchmark it, I'd really appreciate it.

 

Also, I have thought about it, and a SUIT compiler IS plausible, so long as the statements are converted into function calls, not the actual code of the function. I never thought of it that way, and it should be faster (Even though I don't think it'd be MUCH faster) and it doesn't remove any of the flexibility of merely running from parse trees. I still think doing it without a compiler has less room to be insecure, but I'm pretty sure if done right, nothing past function calls will be translated to the compiled PHP file.

 

I'll keep you all posted about my attempt to write one. Thanks for suggesting it and forcing me to think it through. :)

[♥FWR Media]

How does SUIT handle a situation where the designer needs to add some functionallity but does not know PHP? To help with this, let's say the user wants to have just the home page show an image (image_1) or specific text (text_string_1) but have a different image (image_2) or text (text_string_2) in just the "New Products" page? Or maybe they just want to have a 1 column layout in category_3 but a 2 column layout for category_10 and category_12 and all other categories would be a 3 column layout?

 

The above could be easily worked out with very basic PHP code but if the point is to not have the designer inserting PHP code, how would SUIT handle this?

 

I know this was directed at Brandon but I wanted to comment on this.

 

There is absolutely nothing wrong with having logic in template files .. sometimes with complex sites it needs to be complex logic .. so long as it is display logic and not application logic.

 

Mr W.Designer who can't code in PHP and can't even code in HTML without that horrible Dreamweaver WYSIWYG .. well .. he's got no hope of changing much without paying someone who can.

 

Just thought to throw that in.

[bkellum]

I know this was directed at Brandon but I wanted to comment on this.

 

There is absolutely nothing wrong with having logic in template files .. sometimes with complex sites it needs to be complex logic .. so long as it is display logic and not application logic.

 

Mr W.Designer who can't code in PHP and can't even code in HTML without that horrible Dreamweaver WYSIWYG .. well .. he's got no hope of changing much without paying someone who can.

 

Just thought to throw that in.

 

 

It's a good thought to throw in.

 

I've come across this several times with things such as a Flash Movie per category and specific product pages. Some product pages want to show a YouTube movie of product details. Being able to place that logic into a template file, without messing with the core code, makes installing other 3rd party contributions so much easier for some users.

 

I do feel sorry for Mr W.Designer though...he is missing out on so much. But then again, he keeps me busy

[BrandonE]

I figure there must be some simple logic no matter what solution you have. The key here is keeping it simple. The main reason bkellum brought it up seems to be if someone wants to use some logic in one theme and other logic in another. SUIT has nothing to do with themes. I'd recommend using hooks to execute logic depending on the theme.

 

However, if you must do something logical from the template, we allow function calls through [call /] and [transform]. We have no problem with users sending parameters to a function and inserting the return value into the template. We do, however, think it's silly to have huge blocks of logic when it could easily be separated. You have the same flexibility as regular PHP, but you are forced to do the vast majority of the logic in the PHP and not in the template.