118 replies to this topic

[devosc]

An interesting read: http://www.massassi.com/php/articles/template_engines/

[dreamscape]

I vote no Smarty.  It adds too much overhead.

[cannuck1964]

In reality a simple system that relies on modularized file structures is much more perferable then adding in a whole new abstraction layer.  The separation of the business logic is a good idea, but to take that idea and say smarty is the way to go, I would say no, and if osC ever did use it, I would think that other forks out there would be more appealing to me.

I am not concerned with how designers want the php out of the template layout, this is not ever going to happen.  You can replace the php with some other type of tag system (ie what smarty uses), but what is the advantage of doing that?  

PHP was designed to work on web sites, and it is plain that it is here to stay. If you want a dynamic site, then you are going to have either embedded php or some type of tag which is parsed into a php function/logic.  Why do this at all?  That is just one more step.

A good template system in my opinion leaves a small footprint in parsing, is easy to implement changes with, and separates the business logic from the displaying logic.  Notice that the display has logic, and this is what is needed, you can not have dynamics without logics to control it.

There is no need to use smarty, or any other external solution, since there are many ideas already here which would deal with the prime concerns listed above.

cheers,

Peter M.

[devosc]

My personal preference is a class method of the BTS system (from its early days).

The fundatmental point of it being something like:

 require( $page->template() )

Then as like BTS, this calls the mainpage.tpl

Within which:

<?php if($page->templateType() == 'string') { echo $page->content; } else { include($page->contentFile); } ?>

The preference here for me atleast, is that since it is pure php, no placeholders etc.

[cannuck1964]

Quote

My personal preference is a class method of the BTS system (from its early days).

I agree with the classes, and parts of the BTS system.  I see no need to define the BTS as it is done now in the filename defines.  This idea of using the tpl.php extension just adds in additional logic executions which are not needed.  Just as easy to name it the exact same as the page, and then call the page layout and classes in using a page_name variable.

As for the classes, I think putting much of the various php logics into a class would be much better, then calling in the pieces would enable the designer to move them easier.  Classes also have the ability to separate the logic easier.  And then calling in the required parts is as straight forward as what devosc laid out.

I also like how the install is done with the layout system, and add in a mix of classes and folders defining various parts would be a good mix.

cheers,

Peter M.

[snakerboy]

cannuck1964, if the output was valid XHTML without any tables for layout layout then there would be no issue.

I'm current having to step though functions like tableBox to try and create some slightly valid markup so I can actually use CSS to build something that not your bog standard OSc installation.

[cannuck1964]

vaild XHTML and a template system are two separate and different issues.  Any template system can have valid XHTML, and having standard XHTML does not imply you have a template system.  Yes, I agree the output from the standord osC should comply with standards, but that has nothing to do with a template system.

I disagree with having the entire system rely on css for the template system, this limits the system too much, rather a template system which uses css and complies with standards, while retaining the ability to use other methods is more functional and what people are looking for.....

cheers,

Peter M.

[SCG]

I think this is great!! How can I get this new feature.

sparky, on Nov 13 2004, 02:35 PM, said:

As you might of seen from the current CVS we are introducing the concept of templates into the osCommerce administration tool.

These templates will also be integrated into the catalog area.

Please post any features / suggestions you have for the templates and general layout of osCommerce in this thread.

There will only be a single supported template engine for osCommerce. Any other template engines that are contributed will not be supported so please make sure you post your suggestions here to get the features added.

Any posts not related to the templates / layout are likely to be removed.

<{POST_SNAPBACK}>

Edited by SCG, 28 January 2005 - 03:21 AM.

[dwatson]

devosc, on Jan 26 2005, 03:09 AM, said:

An interesting read: http://www.massassi.com/php/articles/template_engines/

<{POST_SNAPBACK}>

This is a really great article.  I like Smarty, but it is probably too much overhead, and too controversial for the oscommerce community.  A simpler strategy that removed the presentation logic from the business logic would be fantastic.  The important point, I think, is to separate the HTML and presentation (with minimal logic, php-type code) into separate files that designers can work on.  Keeping it simple as possible, with as little overhead as possible, seems the way to go.  But the current style, with the heavy intermixing of PHP logic with HTML, should be cleaned up.

[ebay258]

I don't know if someone already menssioned this, as I was not following the topic but,I would suggest changing the category links on the left into buttons instead of text.The default color is also bad. The "color against background" evaluation criteria needs to be looked at. Thank you for you're kindness and doing something like this. Just think if all programers did this...Cyber OS! lol

Edited by ebay258, 30 January 2005 - 08:10 PM.

[maxmsn]

I suggest to make use of the main tags that are part of basic html specifications.
this means that hx, div, span, p and ohter few can be used in a easier way than all those tables needed at this time to render a side box. in conjunction with css, obviously.
boxes could be rendered individually exclusively by css, having for example this classes:
#tit_boxname
#cont_boxname
so we could set all the necessary css attributes for all the contained html tags, as in this example:
#cont_boxname a
#cont_boxname  p
#cont_boxname  h1
#cont_boxname  bla bla

this method could be useful as a guideline for all contributors that need to write their own boxes.

anohter idea comes from the mambo cms templating system. with mambo, i can set a template to work for an individual page, or for all the site. so it would be easy to have specific templates only for desided pages, nothing more than the necessary.
more, mambo template files can be edited nad viewed with a simple wysiwyg editor (dreamweaver, html-kit, etc).  this is an invaluable thing.
please note: I'm not saying you should include mambo templating system into osc. but their ideas could be an interesting suggestion for your project.

I don't look good at nested templating (html box templates, called to be nested into html column/section template, nested into html page templates, etc).

[Nimitz_1061]

cannuck1964, on Jan 27 2005, 09:48 AM, said:

vaild XHTML and a template system are two separate and different issues.  Any template system can have valid XHTML, and having standard XHTML does not imply you have a template system.  Yes, I agree the output from the standord osC should comply with standards, but that has nothing to do with a template system.

I disagree with having the entire system rely on css for the template system, this limits the system too much, rather a template system which uses css and complies with standards, while retaining the ability to use other methods is more functional and what people are looking for.....

cheers,

Peter M.

<{POST_SNAPBACK}>

I quite agree on the CSS issue.  osCommerce is widely used by designers and developers with extremely different skill sets.   Java and html or xhtml fan's should all be able to work with it.  If they aren't , the project restricts itself severely and will not maintain its popularity, much less increase it.

David

[ebay258]

A better design, a more lively template with some color to it. It would be cool if the theme was like this bulletin board (boxes and stuff).

[BlueYon]

I use BTS for mine:

Edited by Johnson, 23 September 2005 - 08:55 AM.

[BlueYon]

I would look at mambo the PHP CSM open source system. It is a bit simular to oscommerce but the coding is a lot more advanced.

It uses a very good template system with only a few files needed to produce a new template.

Edited by BlueYon, 07 February 2005 - 06:00 AM.

[peterr]

Hi,

Recently helping someone with a site that uses a free (GNU) osCommerce template. Having had a background of doing different osC contribs and other customisations, after taking a really good look at how the template was designed, I advised the person to drop the template and go for either STS or BTS.

My point is, whatever the osC developers do with the new template, it should be designed in such a way to still enable the (easy) addition of osC contribs or other customisation. This one we tried/used was not, and it was so far removed from the "standard" osC template/layout, it made any minor mods very difficult indeed.

I won't mention the template, so pls don't PM me for it.  

On another "method", I like the idea, concept and ease of use that quite a number of CMS systems use, that is, you go into admin, and just check a box to say if you want left or right columns, what you want included in the columns and headers, footers,etc, and even who can access each 'part'. Most of these are "Smarty" driven, at the root level.

Peter

[little.pm]

Hi everyone,

sorry if this is gonna be a huge post but I am really interested in the topic and in a professional (read easy to use and reuse) solution.

The idea of using a template system is great. Period.

The way it is gonna be implemented could turn everything into being bad. Period.

Ok, I do not know of the very best way to do this, but here comes my suggestion.

The Frontend visible to the customer shall be well formed according to whether document format the shop owner applies for.

Having said that this means that the documents being delivered to the client must confim to either of these standards (short example list, you name just the ones that you think have been left out).
HTML 3
HTML 4
XHTML 1
XHTML 1.1
including their variants.

So, for the customer it is unimportant how the content he gets is being produced, all that counts is that the document he receives is valid (read can be rendered correctly in his /her browser).

For the shop owner it is only important to
- add/remove/change the sites contents as quick as possible. (the mor often happening case)
- change the layout of the documents in general (a rare case as design changes do not very often happen)
- add/remove/change products

Preferably the shop owner might want to edit only ONE general template (as it is the case in BTS). And a "no" wispers through the audience.

BTS itself is no choice as is and as per se.
Smarty is to be considered.

So for both only counts what they see - not what is in behind.

create a template for the page (in mind that you are goping to use smarty)

go to your admin
go to website admin
create a new url
assign a handler to create the document placed at the location
now assign a content to the produced document
the produced document could in fact look just alike the original shopping cart.

To make this more clear

we want a document at location "url"
looking alike shopping_cart.php looks now

so we can produce a document alike (pure and simple example, admittedly)

<?php
include('application_top.php');
include('header.php');
include('contentX.php');
X = new RequestObject();
X->preview_process();
X->display();
X->afterview_process();
include('footer.php');
include('application_bottom.php');
?>

or we can produce a document alike

<?php
include('application.php');
X= new RequestObject(url,params);
X->preview_process();
X->display();
X->afterview_process();
?>

But the goals we are looking at and want to reach
less DB queries
low memory consumption
low processor time consumption
low processing time
low ressource usage

It is faster for the webserver to inlcude a file than to query a DB.

It is nothing wrong with writing variables into files created instead of unesseccessarily fetching them from a DB if they do not change an a regular basis but are rather changed "manually" and sporadically.

I mean think about checkout process. How often do you think that the shop owners email address is gonna change? What about making the deal and to exchange the DB query for the email and the php instruction to insert it with a ONE TIME PROCESS when the shop owner changes that value and in this very case the document checkout_process gets rewritten?

The topic itself interferes with the problems of classic content magement systems (CMS).

So I suggest to include a CMS capable of handling templates as this brings advantages for the frontend but also for the backend as this would allow the system to rewrite its own files (except at least one wich could be called the kernel and is actuallay the absolutely only one doing such hazardous actions on other files) if needed - for example to add a contribution (without charging any skills from the shop owner) or with making an update to the system itself.

To make a long story short:
I suggest to move everything regarding DB queries and php execution to the file creation phase as described above and to let only remain the very few Queries and php executions that would be needed to keep being interactive with the user.

Yes, this will miss the point of low ressource usage, but hey, a server with a second HDD is cheaper than one with a second cpu , no? And it would fullfill all other requirements.

Rethink it with the new cache class in mind :-)

Have a nice day.

Regards


Ralf

(erm, yes, i do have code that does some of that and you might ask for the full source code for a cms based upon osocmmerce wich is not yet ready for publishing but I am working on it as I have the nuts idea of encoding the language in the url and in the document so ending up
with urls alike
http://www.yourdomain.com/en/products/mp3players/IPod_Mini/
and
http://www.yourdomain.com/de/produkte/mp3player/IPod_Mini/
which do actually point to the same product but do not include the description from the DB anymore but things like quantity in stock and attributes etc., wich is only what counts when a customer visits the page. The description won't change very often , no?)

[pixelslave]

sparky, on Nov 13 2004, 10:35 AM, said:

As you might of seen from the current CVS we are introducing the concept of templates into the osCommerce administration tool.

These templates will also be integrated into the catalog area.

Please post any features / suggestions you have for the templates and general layout of osCommerce in this thread.

There will only be a single supported template engine for osCommerce. Any other template engines that are contributed will not be supported so please make sure you post your suggestions here to get the features added.

Any posts not related to the templates / layout are likely to be removed.

<{POST_SNAPBACK}>

Let me make this clear: I am totally new on PHP! I use Jave and .NET extensively and XML/XSLT works extremely well on those two platforms. It's not the fastest rendering method, but with resusable cached XSLT stylesheet, the performance is good enough for most applications. But the benefit is great. I work mostly on the design/UI front, the time I need to communicate with the backend programmers is next to nothing. All we need to do is to agree on a XML schema before a project starts, and that's basically all we need to work together.

Maintanence is another advantage of XSLT -- layout change doesn't require programming changes. Programming changes won't affect the layout.

Now, the problem is, I have no idea how good XSLT implements in PHP. If it works horribly on PHP, there's no point using it. But it's still worth thinking about different approach to solve the templates/layout problem, right?


Kam

[Shopsearch.dk]

Wouldn't it also be possible to add creation of button images on the fly ?
Doing that would automaticly make buttons Multilingual, and make it very easy to change button templates.  

[toasty]

sparky, on Dec 3 2004, 11:51 AM, said:

The couple of lines would need to be called on every page and every component of a page that can have its own template, meaning code is executed numerous times.

Whilst this code is only simple its will be excess for most people.

<{POST_SNAPBACK}>

This sounds similar to the approach taken by one aspect of the Drupal CMS. They have been through these loops already and the system is now very usable (and improving every day at light speed). It avoides bloat by good design.

I hear that core osCommerce likes to keep itself to itself, nevertheless it might be of interest for you to talk to the Drupal team before a great chance is missed, not just for templating.

The structure of Drupal is fantastic. Bring this approach to osCommerce feature rich app and mods and the world would be a wonderful place. How a bout a bit of cros-fertilisation?

Here is a discussion of interest that shows now might be a good time:
http://drupal.org/node/5931

...or contact the head honcho, Dries and chew the cud on big things together!

Edited by toasty, 21 February 2005 - 06:33 PM.