Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Templates / Layout


Mark Evans

Recommended Posts

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).

Link to comment
Share on other sites

  • Replies 118
  • Created
  • Last Reply
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.

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :D

 

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

Link to comment
Share on other sites

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?)

sometimes I change code before reading the comments, sometimes code doesn't even have comments, sometimes I rechange code after I read the code others wrote :-)

Link to comment
Share on other sites

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.

 

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

Link to comment
Share on other sites

  • 2 weeks later...
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.

 

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!

Link to comment
Share on other sites

  • 3 weeks later...

A concept that I haven't seen mentioned a lot, is the idea that your categories can become individual stores through some form of templating. A non-osC site called Merch Direct has a shining example of this. Notice how these stores are only slightly changed (different background color, links, and header) yet it's very effective:

 

Example 1

Example 2

Example 3

 

If you can imagine those stores as being categories of one huge store (a store that can sell the exact same products) then you start to see the power of this. Would an "if" statement that calls a stylesheet based on the current category be a possible way to do this? I realize this is only one part of the customization subject, and may have already been mentioned, but I wanted to contribute my idea.

Link to comment
Share on other sites

  • 3 weeks later...
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.

Just FYI I would like to mention that it does not appear to be bloat in the sense of processing time. The "delay" it adds appears not to be (or at least not easy) measurable using the "log parse time" feature osC offers. The speed difference, if any, seems to be about 0.01 sec.. (only done some quick tests)
Link to comment
Share on other sites

  • 5 weeks later...

How far would an XSLT implementation remove OSC from the hands of the average shopkeeper who might only have Dreamweaver or Frontpage to make modifications in?

 

That would be the concern I have. It seems that the popularity of the program and its widespread use is due to the fact that anyone with little or no programming knowledge can get the software up and running in a few minutes. With a little HTML knowledge and a willingness to go through the code, they can have a customized shop. It may not be W3C compliant but it works for everyone. Going to specialized languages which require more knowledge, would eliminate that. Without a true customer support mechanism (support tickets, phone support) or a design service, it would cause a falloff in the usage of the product for solutions like X-Cart, Yahoo Shops or MonsterCommerce.com.

Link to comment
Share on other sites

How far would an XSLT implementation remove OSC from the hands of the average shopkeeper who might only have Dreamweaver or Frontpage to make modifications in?

 

That would be the concern I have. It seems that the popularity of the program and its widespread use is due to the fact that anyone with little or no  programming knowledge can get the software up and running in a few minutes. With a little HTML knowledge and a willingness to go through the code, they can have a customized shop.

 

XSLT is pretty friendly looking. In my opinion much friendlier than the PHP riddled HTML code in there now. A casual user with a "willingness to go through the code" would be able to ingore the XSLT tags in an html template just like they can ignore the current PHP code.

 

Now that said I don't dissagree that there are some definate sacrifices to be made. The main one I think is server config. Unless you're on PHP5 libxsl (the best choice for XSLT serverside parsing, i think) is not an "on by default" PHP extension.

 

I don't know... perhaps this isn't a main branch project? I think it could be, with the proper treatment. Remember that this is a discussion as the the best templating system to implement. There is no question in my mind that XSLT best and easiest for both casual users and the developer who wants to change every element of the HTML.

Link to comment
Share on other sites

Im sorry but i have to voice MO here, the dev team is breaking my heart with the news of osc going template based.

 

can someone tell me how they are going to impliment this "templating".

 

like this stuff?

something --> showit

 

or something like this, much like the so called templates in the script "cutenews" checkout cutenews its kinda neat, well IMO anyway

 

<div class="coolbox">{somedata}</div>

 

whats wrong with php? it is a "templating engine"! ah...

 include("somefile.php");

 

Im sure ill get flamed for that statement, but read php's history, and forgive me if i dont reply to any flames that may come from these statements, iv argued these points before elsewhare not realy interested in doing it again, sorry. theres an old say: keep it simple stupid, no im NOT saying anyone's stupid for using template systems, its personal choice for sure, but learning a sub-language of php isnt logical to me.

 

why not just go with reconfiging the functions with html strings in them, change those darn tables to div's add css class name to each, and optional css id? why keep calling the server, the database, oh what a mess IMO.

 

im sure some will take this all as a flame but the truth is im hurt bythe news, not mad. oh well, im gonna go cry in my beer now. :'(

Link to comment
Share on other sites

...learning a sub-language of php isnt logical to me.

 

I couldn't agree more. It's not logical. That's why if templating is to be done (which for those of us who have to reconfigure OSC for new look and feels on a regular basis aggree that it must) XSLT is the only answer.

 

It's clean, its a standard... what other arguments are there?

 

why not just go with reconfiging the functions with html strings in them, change those darn tables to div's add css class name to each, and optional css id?

 

We're agreed that the css needs to be improved, templating system or no templateing system, but an important goal in a project of this size is to seperate business and display logic. WHAT you display on a given page should have nothing to do with HOW it is displayed. The last thing OSC need now is MORE integration of PHP and HTML. Again, this is something an XSLT structure would solve.

Link to comment
Share on other sites

  • 3 weeks later...

As much as I adore xslt .. there is a steep learning curve and little if any wysiwyg editor support.

 

That said the only other viable solution that I see is to use smarty - smarty.php.net - to output xhtml 1.0 transitional (or strict or 1.1) markup in a SEMANTIC fashion. Then use css to handle the formatting.

 

Having used smarty and oscommerce both extensively I have to say that smarty is very quick, very extensible, easy to learn and has so many features that would make catalog generation very easy. OSC on the other hand is a pile of crap from a coding perspective. You have multiple styles of syntax in use and have succumbed to the terrible habit of using php procedurally by mixing it inline with html markup.

 

Personally I think OSC should go back to the design table..

 

Implement a set of classes that do the following..

 

An abstraction layer for db access. Do this using PEAR:DB so that you can switch db systems as you wish.

 

An abstraction layer for authorizing logins. Do this in such a way that the username and pw fields and the auth table are set in a config file. This would make integrating osc into sites with their own auth schemes SO MUCH EASIER.

 

Implement a REALISTIC language tool and some automagic localization features. GETTEXT and ip2locale should make this a piece of cake. Of course you can also easily allow users to switch locales in the case (common) of ip2locale errors.

 

USE SMARTY and make LIBERAL use of it's built in pre/post filters and modifiers. Write consistent concise plugins for the few features that smarty doesn't have that you may need. What those would be I can't even imagine. By doing this you ensure that the DATA coming from the MODEL LAYER won't be munged by any sort of business logic until viewing occurs at the clients end of things. By keeping all of your data in it's purest form (integer / floats for numerics - raw unescaped text for text - etc) you can ensure that any manipulations of said data are possible.. so you want a wap store.. easy. So you decide you need an RSS feed for new items .. piece of cake. The data could even come out of the MODEL as XML and allow the CONTROLLER layer to handle what sort of output format to spit to the client.

 

My suggestion (as a lowly php developer of 4 years) is to use PEAR as much as possible to handle your application logic. Write a clear and efficient class to handle the MODEL - thus giving you a clean API for handing data off to the view. Extend the smarty class as needed for the view layer and leave the html OUT OF THE CODE.

 

As an added benefit : If you do all of this correctly you have a clean MVC application that should run fine (aside from some possible PEAR issues) on php 5 .. which you should be seriously concerned with. It is the new version and eventually your old procedural shitpile will become not only obsolete but a running joke.

 

Having played with your competition

http://www.icdevgroup.org/i/dev/index.html

http://www.icdevgroup.org/i/dev/index.html

http://www.agoracart.com/

 

I would have to say that you guys are behind the curve for speed (compared to interchange and xcart.) as well as customization (interchange uses generic php templating and xcart uses smarty. agora is crap) features. The only one you have an edge on features wise seems to be Agora. There was once a time where you guys had the best cart system around. It's about time you caught up with the competition and took back the throne, yes?

 

** edit **

One last comment. The other option and the one I would most like to see.. is a php 5 version of osc using xml/xslt/custom doctypes along with css2 or lower styling rules and simply begin marketing yourselves as an out of the box PRO e-commerce solution aimed at webmasters and developers who know a little bit about the technologies.

 

In the end this is just my $0.02 and opinions are cheap.

Link to comment
Share on other sites

So far I think we all agree that seperating backend code (php) from frontend (HTML/JavaScript etc.) is what current development on the web is about resp. has been for some time.

 

Next, there are two areas:

a] developers wishing to have the maximum, most convenient way of customizing frontend for their client projects etc.

b] users / shop owners trying to customize their just downloaded default installation of osCommerce, with very little effort and best by using a common way. And also web-designers knowning nothing about php coding but having great skills in frontend-tweaking (css/html) should have all the possibilities at their hand.

 

How to get these two areas together might be somewhat tricky :)

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...

Hi

 

One friend, who owns a car sales office, asked me if oscommerce could sale cars. I said: "of course it can!" and then he asked: "can our customers make a reservation online according to existing stock and let know others customers that a particular car is reserved for another client?". Ehhhh... good question!

Is it possible? I mean something like this:

 

- make reservations online (with a button for that option next to the one "add to basket")

- put a text next the reserved car like "reserved"

- a date for the customer to buy. For example: when a reserve is made, the customer have5 days to complete the buy, otherwise the car will be automatically available for someone else.

 

 

Thanks :thumbsup:

Link to comment
Share on other sites

  • 3 weeks later...

Well, like what i'm currently building is a webshop in which all the products for a categorie can be seen in one big picture. sort of like a shop window. When the mouse goes over certain areas, you will see a closeup of that spot underneath the pic. On the right side you can see each product separate to place them in your cart and get a more detailed description.

 

I think, especially for fashion and furniture shops, this would be a handy addition.

This will give the buyer a good perspective on the size of things, next to that it will show people what to wear with a certain necklace or with a certain skirt or whatever... Makes them buy even more :devil:

Link to comment
Share on other sites

  • 3 weeks later...

I'm partial to PHP, it's fast, configurable, and well documented. XLS is ok, but not as dynamic, and will cause problems with people who have php configured to short <? insted of <?php

 

http://drupal.org/node/509

Some intresting talk about theming, not sure if aneyone else here uses it, they are also looking for shop modules, perhaps an API & Theme engin would be good. The ability to flexibly deply shops via Mombo TikiWiki & drupal would be advantagous to deploying related sites that incorperate a base shop, and give a unique and powerfull edge to oscommerce, setting it as the standard in ecomerse packages (which it appears to be aneywas)

 

With modular development you could do things with other CMS's or even use them as the frame work & focuse on product administration.. *shrug* my 2 bits.. but I'm new what do I know ;)

 

 

Anyhow back to the sandbox to play..

I'm sporting osCommerse 2.2.ms2

With these additions:

 

I worry about if take credit cards? I wonder if I make a shop that keeps track of how much product I have? If I find somthing good it'll be out of my budget, I'm trying to start a shop to make money not spend it..

Quot the raven "Never more." Get osCommerse never worry, or wonder again.

Link to comment
Share on other sites

  • 1 month later...
the templates are a good idea..but from the design point of vue (sorry my point of vue)

i would favor more a developpment directed towards the pros,the artists....

templates have a way to destroy imagination and craftmanship.

and what we need is not a couple of templates

but a more friendly ways of making them

Templates have way to uniformize a variety of officials design by making them accessible to non-artist/designer... and eventually replace the artist by some machine way of designing

which produce a low quality of art as we see it in general everywhere ,

with only artist eyes to make the difference beetwen them!

and it is allways the same question.....

are you an artist /designer because you have the tool or because you have the idea?

my english is not so good so i apologize in advance for the typos and the grammar

thanks for your time.

paul.

 

Well put. However, when it come to selling online, there are "tried and true" principles to apply. I'm familiar with the template market and frankly, it provides quick, viable business oriented solutions that make life easier...the historical reason why good ideas stick. Website templates are good. I should preface that I have not designed a webpage for over 2 years and have been using templates for my clients ever since. They save both time and money and are better design than I am capable of. (better design than most designers are capable of too)

 

OSC Templates with thorough instructions for install / deployment / user manual etc , would go a long way. One could concieve of 250 differnet Xmas OSC templates. The same goes for Halloween etc. This idea isn't new.

 

The "artist" could come in and design his/her own templates and submit them for sale as commissioned work. Every sale gets him/her a cut. That way the artist has an outlet and the business has a solution. Win win.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...