Proposal: the future of OSC

[Crusoe]

We shouldn't even use the C library, it's too complicated!

 

Better to hand code custom string printing routines in ASSEMBLY.

 

These other projects are mature, and stable, so bugs are less likely to occur in them versus a roll-your-own system. Anyone who thinks otherwise is sticking their heads in the sand.

 

Why, we shouldn't even use PHP, it may be chocked full of bugs! ;)

 

Smart coders re-use.

 

It's a well functioning product. But I agree, on the inside, it looks brittle, and hard to customize. A one-off prototype that gained a life of it's own, and should have been rewritten at the 1.0 stage.

 

Why not use ADODB, Smarty, etc? These are all good libraries, rock solid, with avid user communities capable of providing good support. Then you could just focus on wiriting the business logic, instead of dorking around writing half-broken, inflexible, less feature rich copies of functionality that ADODB, etc, already provide?

 

Face it, your requirements are different than theirs. And six months down the line, you'll go "Gee, I wish we could do this....", write a bad version only to find that Smarty or Adodb already provide it, and it's well written and tuned because the lib users have been using it for years because their applications needed that capability long before OsCommerce existed. Then you'll feel like a heel... ;)

 

It's happened before, it will happen again. Do not make the same mistake that 99% of failed OS projects have made.

 

I wonder how long till Twisted matrix produces a shopping cart system... ( Wonderful python toolkit for network apps. Very very very easy to use ).

[Mark Evans]

Why not use ADODB, Smarty, etc? These are all good libraries, rock solid, with avid user communities capable of providing good support. Then you could just focus on wiriting the business logic, instead of dorking around writing half-broken, inflexible, less feature rich copies of functionality that ADODB, etc, already provide?

I personally cannot see a need to make osCommerce more complicated than it needs to be.

 

Smarty is aimed at sites that need to change often and ADODB is aimed at providing a wide range of database support and inherrent with that, a performance hit.

 

Admittdly its not a large performance hit but one thats easy to avoid.

 

How often are you going to change DB backends?

How often are you going to change the complete look of a store?

 

The advantages of smarty and adodb can be added to osCommerce without introducing an overhead and an overly complex template system.

[Dragonmom]

Guys, take my case- I am an old lady-:) 48 years :) and about the only one of my group of freinds and craftspeople that is web-literate at all. I have taught myself html, and little bit of PHP, but it's just not that easy for me to learn new languages anymore. My group needs a storefront that is functional- as OSc is- an I need it to be easily designable, so I can take care of my friend's sites for them- at a cost they can afford- and I still need to find time to make my own work to sell. I tried STS, and couldn't add new functions into it easily, now I am trying out BTS. But I do need to add some contribs- and remove one or two that only confuse these cranky old solo craftspersons- and the functionality of the template systems get thrown off each time I modify. I am not a programmer!

One case in point is the reviews box, that famously stops working if you move it onto the left column. Does anyone know why?

Please find a template sytem that is easy to maneouver, for the sake of your poor pitiful public heh heh...

[Mark Evans]

One case in point is the reviews box, that famously stops working if you move it onto the left column. Does anyone know why?

Please find a template sytem that is easy to maneouver, for the sake of your poor pitiful public heh heh...

First off take a look here

 

http://www.oscommerce.com/community/bugs,1460

http://cvs.sourceforge.net/viewcvs.py/tep/...r1=1.37&r2=1.38

 

That will fix your reviews box problem.

 

Or you could download the latest cvs which has the above fixes already applied.

 

Secondly, I agree we need a template system that is easy to use, systems such as smarty are just too complex.

[Crusoe]

Great, until you need to use Oracle instead of Mysql because of volume. Or you need custom code that USES the idea of transactions. You may NOT need it now, but what about the future? HW is cheap, if it's a lil slower, just buy a faster box. This is what AdoDB provides. It gives the user choices, not the developer who considers MySQL "good enough" for his scratch. Sure it's great for WebMonkeys. But then, Oracle is just as fast as MySQL, with a lot more features ( It's perhaps 5-10% slower, but you get a LOT of useful extras ). Why deny this to your users because "Mysql is good enough". In fact, it would be simpler, as you wouldn't have to worry about MySQL or Oracle specific features, but only ADODB features.

 

Templating being 'complicated'

Great until you need write a plugin that doesn't involve breaking other plugins ( As oscommerce currently requires lots of ad-hoc coding and possible breakage ). Writing stuff right now in OScommerce is a PITA. Look at all the complaints about trying to fix bugs, track down issues or even simply customize presentation! Look at the complaints about how hard it is to write a module that doesn't break other features! Hello! It's only gonna get worse unless fixed NOW.

 

If you used smarty, or another template system, you'd have some good documentation to start! You'd be halfway there? Where is the OsCommerce docs on customizing presentation? Nowhere. Now look at the complaints on tweaking boxes, code scattered through multiple files, etc. Now go to the Smarty website, and look at their 'floating box' example. That's simple!!!

 

If you are worried about installing PHP libraries being complicated, that somehow installing something increases the complexity. What a silly argument. If it takes a lil time to install, but saves time coding, that is a worthy tradeoff.

 

And you won't worry as much about customizations breaking existing code.

 

Ugh, I was trying to track down how to turn off display of items that out of stock. I saw SQL code in files that also build UI displays. **whimper**

[Mark Evans]

Great, until you need to use Oracle instead of Mysql because of volume. Or you need custom code that USES the idea of transactions. You may NOT need it now, but what about the future? HW is cheap, if it's a lil slower, just buy a faster box. This is what AdoDB provides. It gives the user choices, not the developer who considers MySQL "good enough" for his scratch. Sure it's great for WebMonkeys. But then, Oracle is just as fast as MySQL, with a lot more features ( It's perhaps 5-10% slower, but you get a LOT of useful extras ). Why deny this to your users because "Mysql is good enough". In fact, it would be simpler, as you wouldn't have to worry about MySQL or Oracle specific features, but only ADODB features.

 

Templating being 'complicated'

Great until you need write a plugin that doesn't involve breaking other plugins ( As oscommerce currently requires lots of ad-hoc coding and possible breakage ). Writing stuff right now in OScommerce is a PITA. Look at all the complaints about trying to fix bugs, track down issues or even simply customize presentation!  Look at the complaints about how hard it is to write a module that doesn't break other features! Hello! It's only gonna get worse unless fixed NOW.

 

If you used smarty, or another template system, you'd have some good documentation to start! You'd be halfway there? Where is the OsCommerce docs on customizing presentation? Nowhere. Now look at the complaints on tweaking boxes, code scattered through multiple files, etc. Now go to the Smarty website, and look at their 'floating box' example. That's simple!!!

 

If you are worried about installing PHP libraries being complicated, that somehow installing something increases the complexity. What a silly argument. If it takes a lil time to install, but saves time coding, that is a worthy tradeoff.

 

And you won't worry as much about customizations breaking existing code.

 

Ugh, I was trying to track down how to turn off display of items that out of stock. I saw SQL code in files that also build UI displays. **whimper**

I agree oracle is better than MySQL which is why database independance will be introduced to the codebase so the store owner can decide on a DB backend.

 

We dont need to use ADODB though :)

 

The same goes for templating, what most people want to achieve is to be able to change the look and feel of a store without knowing any PHP programming. This is what will be introduced before 2.2 is finalised again we dont need Smarty for this.

 

I will ask this 1 question.... what advantage does smarty give to a new user who knows only basic html programming that a simpler templating solution cant?

[Mark Evans]

If you used smarty, or another template system, you'd have some good documentation to start! You'd be halfway there? Where is the OsCommerce docs on customizing presentation? Nowhere. Now look at the complaints on tweaking boxes, code scattered through multiple files, etc. Now go to the Smarty website, and look at their 'floating box' example. That's simple!!!

This is where the community can help, you dont need to be a programmer to add documentation to the Wiki.

 

We cannot do everything ourselves. I bet if every memeber of these forums added 1 line of information to the wiki you would see a very good set of documentation.

 

I dont think using an external templating system just to get documentation is a very good argument to do it :)

[Guest]

I will ask this 1 question.... what advantage does smarty give to a new user who knows only basic  html programming that a simpler templating solution cant?

Efficiency. Smarty compiles (into PHP code files). AFAIK, your system will be interpreted (i.e. if you have a function call that says $tpl->displayContent(), the function call will run every time that the page is parsed; Smarty function calls can be compiled out--the cache files will look more like the current files). Which means that even though it is smaller than Smarty, it can still have higher overhead in practice (i.e. your system might have lower overhead the first time that you run it--when Smarty is compiling the cache file, but as you note--how many times do you change the look of the store? Smarty cache files would have less overhead than the template files).

 

Note: I have heard several people suggest that Smarty is too complex. This does not have to be a barrier. There is no reason why you couldn't use a *subset* of Smarty functionality that gives you what you want to achieve. At the simplest level, just use Smarty display variables and functions (no programming logic like control structures, etc.) in the HTML file. As Smarty can use XML compliant tags, this allows designers to change the layout by moving tags that look like <% $NavigationArea %> or <smarty: $NavigationArea > (obviously, your system could have XML tags of its own, but Smarty already includes this) to where they want them. That said, it may still be to early to ask the dev team to commit to using Smarty (or any particular solution).

 

I still think that the best solution is to make a two layer system. The first layer allows for drop in templates (this is what Brendan's Basic Template Structure provides) with multiple levels (for example, with the product listing page: top level specifies things like three column fluid layout with header and footer added; the next level specifies the arrangement of the content area; the next level specifies how each row of the product listing appears; the next level specifies how each element appears). This would also help with simplifying contributions. With this, if you want to change the way that price appears, you would change the way that the price element appears--one section of code in one file. This would automatically make a change: inside infoBoxes; in the product_listing; on the product_info page; in the shopping_cart; etc. Under the current system, one would have to change each area individually.

 

The second layer (which would be a drop in template) would allow for HTML editing of a file with XML tags (this is what Brian's Simple Template System accomplishes, but you can do it better as you can change all the files; Brian captures and parses the output to keep the changes to a minimum; with the BTS, you would just need to change one file, the main-page.tpl.php, to implement what the STS offers--single HTML page that controls layout of the entire site). Said XML tags could be designed by you for your system; however, this would also allow someone to make a contribution where the XML tags were Smarty tags. Further, someone could make a csszengarden type template, etc.

 

I think that this two layered approach is strictly superior to a single layer approach, as it allows the "market" (i.e. the osCommerce community) to choose what kind of template system best suits it. You would have to commit to a first layer now, but you could push the second layer decision back to MS4 when you are integrating contributions (although you could still implement your own second layer module now and include it with the core code). Ideally, the system should allow people to switch between second layer templates without changing the functional code at all. I.e. if I switch between your solution, a Smarty based solution, and a csszengarden-like solution, I shouldn't have to change any code outside of the template directory. Note: a side effect of this is that the XML tag assignment would have to occur in the template directory (although possibly not in the actual template files).

 

Cheers,

Matt

[Guest]

Where is the OsCommerce docs on customizing presentation? Nowhere. Now look at the complaints on tweaking boxes, code scattered through multiple files, etc.

Right here. Btw, a template system will not fix the "code scattered through multiple files" issue, except tangentially. If the template system continues to use different code in each file, you will continue to have to change this in each file. The fix for this is not a template system; it is to increase the modularity of the code. This can (and might be) done at the same time as implementing a template system, but that does not mean that it has to be or that it will automatically be. The two are separate issues.

If you are worried about installing PHP libraries being complicated, that somehow installing something increases the complexity. What a silly argument. If it takes a lil time to install, but saves time coding, that is a worthy tradeoff.

The install will be done many times (by many different people). Development only needs to be done once. Overall, that extra effort to create a simple, integrated system can easily pay for itself (looking at total time spent) if it makes the install even a little easier. Also, installs cannot require system file changes as system files are outside the purview of most users; the standard osC install is made by someone who just has FTP access to their individual web space. It's not just a matter of complicated; for some people, an install that requires system changes will be *impossible*.

Ugh, I was trying to track down how to turn off display of items that out of stock. I saw SQL code in files that also build UI displays. **whimper**

Yes, but that makes it *easier* to troubleshoot. You will have more difficulty finding where to make the change if the presentation logic is separated out, as you will need to look at *more* files to match the HTML output to the code that controls it. I'm not just saying this, I have actually used an osCommerce sized shopping cart script that operated the way that you describe. It increases the learning curve sharply.

 

Overall, the benefits of implementing a template system (not necessarily Smarty) do outweigh the disadvantages, but there are disadvantages. One of those is the difficultly of matching HTML output (chock full of presentation logic) with the business logic which is separated from the presentation logic in the underlying PHP.

 

Btw, I'm not sure that I agree with Mark on implementing database independence at all (ADODB or not). Anyone who has traffic sufficient sufficient to justify moving to Oracle (a far more expensive solution than MySQL) should have enough money to rewrite the database calls specifically for their store. This will also allow them to take full advantage of their database's features, which a database independent implementation can never do (once you start, it stops being database independent). Those who lack those resources are going to be using MySQL anyway, as it is the cheapest option (and generally available on shared servers, unlike the alternatives). For those people (who make up the vast majority of osCommerce users), the added overhead of database independence is pure waste. Also, it precludes taking advantage of MySQL specific features.

 

Cheers,

Matt

[judgej]

How often are you going to change the complete look of a store?

 

Sorry - I have to respond to this one. Try this for an answer:

 

** every single time a new user picks up this product and trys to deploy it **

[timbeckham]

This thread is extremely important to me, since I am a relative newcomer to PHP and have used OSC as an example for learning both PHP and the ins-and-outs of ecommerce programming. I want to use programming tools that are both effective and versatile, so I would like to offer my perspective as both a student and, hopefully, as a some-day contributor.

 

I cut my PHP teeth on OSC by spending MONTHS digging into the code and making changes to the layout and SQL queries to give my store the face and capabilities I wanted. The experience was grueling, but now that I have been through it, I can say I have learned a LOT. You can view the result here:

http://www.ironwork.com

 

The comments in this thread make several points, as I understand them:

 

1. OSCommerce is an excellent shopping cart system, as far as its capabilities and functionality are concerned. It does the job of an online store as thoroughly as any open source system available.

 

2. OSC's code is an in-house, one-of-a-kind, difficult to modify program. If you learn the code, as I have worked at doing for several months, you will know more PHP, but you will not be able to implement changes easily. You can, of course, use the contributions, but contributions assume no substantial modifications to the base code, and, even in unmodified applications, contributions become broken as the base code of OSC changes.

 

3. Conversely, OSC is not specifically designed to allow other programming systems (e.g. Smarty templates, ezSQL queries) to easily access OSC functionality. This erects a barrier that inhibits reuse of code, in this case the extensive functionality offered by other programming systems like Smarty and ezSQL.

 

4. OSC does not implement CSS for content placement in accordance with the direction recommended by the W3C, nor does it attempt to conform to XHTML standards.

 

5. The pace of development of OSC is painfully slow, due largely to the obscurity, complexity and size of the base code. This problem is exacerbated, at least in part, by a philosophy of development that tries to provide all functionality within OSC itself, without employing the "black boxes" of other coding systems. (Obvious exceptions such as mySQL and PHP itself notwithstanding.)

 

My growing concern is that OSC is digging itself into a development hole. As the complexity of the program increases beyond comprehension, excepting perhaps the core developers, the participation of the community in the development process will likely falter. (It seems to me that we are likely seeing that already.)In addition, at some point custom modifications, such as what I have done for our site, will become less and less feasible. OSC could well fade into a niche environment, superceded by other shopping carts that rely more on a combination of specialty tools, rather than taking the one-program-fits-all approach that I now see emerging from OSC.

 

It seems to me that OSC would benefit by providing an optional approach to the use of its shopping cart functions and classes. I propose that OSC's core functionality be separated from the presentation code in such a way that one has a choice about how to use the system. If one is a newbie, then the existing presentation could be easily employed as an unmodified shopping cart; but if one is a developer, it would be most useful to have a separate set of functions and classes that could be brought into interface with templating, database and other tools to provide the versatility a professional developer needs.

 

I've spent a lot of time learning OSC and cutting my teeth on the "best-of-breed", and I hope OSC will evolve into a system that appeals more to professional developers. On one hand, it is important to provide an easy-to-implement program for those who are new to PHP and HTML and just want to put up a ready-made online store, but that can only be viable over the short term. As the technological demands and pace of ecommerce evolves, OSC needs to position itself to be the favored tool among those who know and work with code for a living. Professional developers know what they need more than anyone else and will necessarily rely on components-based tools, rather than complete solutions.

 

I hope this comment is at least reasonably on base.

 

Tim Beckham

[Dragonmom]

How often are you going to change the complete look of a store?

 

Sorry - I have to respond to this one. Try this for an answer:

 

** every single time a new user picks up this product and trys to deploy it **

Exactly... and it's not that each newcomer is going to change it over and over, but that each newcomer is new to the software, and has merchandising on her or his mind, rather than learning one more language.

[Guest]

My growing concern is that OSC is digging itself into a development hole.  As the complexity of the program increases beyond comprehension, excepting perhaps the core developers, the participation of the community in the development process will likely falter.  (It seems to me that we are likely seeing that already.)In addition, at some point custom modifications, such as what I have done for our site, will become less and less feasible.  OSC could well fade into a niche environment, superceded by other shopping carts that rely more on a combination of specialty tools, rather than taking the one-program-fits-all approach that I now see emerging from OSC.

I don't find this to be true. Serious developers have no problem working with the osC base code (particularly not those who do so on a regular basis). Also, emerging? That is certainly not true. The extras that are being discussed (sessions, login, banners, presentation) have all been parts of osCommerce for quite some time (before the 2.2 development cycle started certainly). osCommerce is becoming *less* one-program-fits-all with the addition of things like the new classes (APIs) to handle login and sessions. If a serious *developer* (as opposed to someone who just installs programs that others write...perhaps with a few tweaks) becomes interested in replacing the existing login/session management, they will be able to do so, even with little knowledge of how osCommerce itself works (will have to understand the interface and how login/sessions work in the other program).

 

That which is being proposed is less flexible than what osCommerce plans to do. The current plan is to make parts of osCommerce black boxes *internally*. I.e. to move to a modular system that allows interchangeable tools (as opposed to the single defined set of tools that others would like to introduce) and includes a simple default set of tools. These black boxes could then be replaced by outside black boxes if preferred. Again, if the choice is overwhelmingly for an outside black box, the current option could be phased out.

 

The biggest problem that I see is that *end users* find it difficult to make presentation changes and install contributions. For example, many feel that an admin login should be built into the core code, so people won't have to leave the osCommerce system to implement it. This is an area where osCommerce does use outside functionality (web server directory protection), but the complaint that I am hearing is that it is *not* integrated with osCommerce specific code. Your complaint about contributions not being updated as the code is updated is along the same lines...it would have been easier on you if osCommerce had integrated *more* code (and taken over the burden of maintaining it), not less.

 

People already get annoyed when told "That is not an osCommerce problem. That is a MySQL problem. You should talk to your host." That would only get worse if Smarty, et. al. were integrated. That's not to say they shouldn't be. It may be that the advantages outweigh the disadvantages. The easiest way to find out would be to create two separate (BTS level) templates. One that uses Smarty and one that does not. People could choose which one was easier. If the Smarty template gets chosen overwhelmingly, then the other template could be phased out. If not, maybe people need both choices.

 

I would say the same thing about using an outside banner_manager. There are only two files in osCommerce that would need to be changed to implement an outside banner_manager. One is the admin page. This could simply be replaced (or possibly removed, which would require a single line to be deleted from one file). The second would be to replace the banner code in includes/footer.php with code referencing the outside banner_manager. Want this included in the core code? Contribute it. If it is popular and complies with osC coding standards, it could be included during MS4. If someone has implemented such a thing, then it would be a very easy contribution to make. The fact that no one has made such a contribution leads me to think that there isn't actually a lot of interest in this.

 

osCommerce has new and updated contributions posted every day (as I write this, the 10th newest was posted yesterday). Switching to external black box systems would slow this for two reasons: one (the good one), black boxes provide more functionality, at least the ones that would reasonably be used--contributions would be less necessary; two, black box systems push development and contributions outside osCommerce. The second can be both good and bad. Good if people really do work on the black box project as well. Bad if they simply find it too complicated to change behavior across two projects (the interface can be a limiting factor) and give up.

 

Cheers,

Matt

[timbeckham]

Matt,

Thanks for the response. I am really flying in the dark on this whole development issue and to get some reassurance that OSC is moving toward more modular, less tangled code is good news. In the course of learning how the various files relate and how the code weaves through various files, I was constantly baffled and increasingly apprehensive. Would I ever be able to get past coding and start running a business??

 

I based my site on MS1 and have not followed the code development since then. My intent is to tackle the whole thing all over again, once 2.2 is finalized. I just do not have the time to relearn the code over and over with each release, much less with the daily changes! I knew my concerns were based somewhat on ignorance of the current development path. I guess things are going in a direction that will make reuse a feasibility, if one chooses to do so.

 

Overall, my main concern relates to the "learnability" of the OSC code. If it becomes simpler (more modular) as development proceeds, then all is O.K., in my opinion; but if it winds up becoming more and more a tangled web, I just do not know how I will be able to keep learning and working at the same time. I do not want to be stuck using something I cannot learn well enough to make into what I want.

 

Thanks again,

Tim B.

[Mark Evans]

How often are you going to change the complete look of a store?

 

Sorry - I have to respond to this one. Try this for an answer:

 

** every single time a new user picks up this product and trys to deploy it **

Exactly... and it's not that each newcomer is going to change it over and over, but that each newcomer is new to the software, and has merchandising on her or his mind, rather than learning one more language.

That is the point I am trying to make. If we integrate smarty and x y and z 3rd party solutions a person who knows basic html and possibly a little PHP/SQL is then going to need to learn how smarty tags work, how adodb works etc etc.

 

Dont you think that will make it more complicated to a new user rather than a basic template system which can be modified to make changes using just html?

 

I think this issue also comes down to the target market of osCommerce. A question we need to ask is. Who are we trying to attract?

 

Newbies who just want a store but dont know anything about html etc etc or web developers that can take the osCommerce code, make improvements and contribute them back?

 

I'm not sure I know the answer to that question myself :D

[judgej]

That is the point I am trying to make. If we integrate smarty and x y and z 3rd party solutions a person who knows basic html and possibly a little PHP/SQL is then going to need to learn how smarty tags work, how adodb works etc etc.

 

Dont you think that will make it more complicated to a new user rather than a basic template system which can be modified to make changes using just html?

 

No I don't believe it will make things harder.

 

The first thing to bear in mind is that not all newbies are newbies in everything. Many already have experience in other products (such as Smarty and ADODB - not that I'm recommending those in particular). The learning curve for those people would be much less steep than learning new OSC custom techniques.

 

Secondly, I would assume that any third-party tools you choose to include would be well-supported, with a decent community and set of documentation for providing support. Simply don't use any products that you are not happy with. I would have thought that would take a vast load of this project's resources - to be able to offload many of the non-commerce queries to the communities that deal specifically with templating/database abstraction etc. and have most likely got an answer for just about any issue already available.

 

You say that new users will find it easier to make updates 'just using HTML'. That is just not true. There is no templating system that just uses HTML - they all have extensions to learn, manage and use, whether they be custom tags, regular expressions or PHP fragments. You are free to create your own home-rolled templating system, but support and documentation of that system will take your time away from the commerce aspects of the project.

 

 

I am glad I am starting to hear the term 'black box' being mentioned by the team members. It shows there is the beginnings of a more systems development approach being made. That can only be a good thing, and I hope that it will continue.

 

-- JJ

[judgej]

I think this issue also comes down to the target market of osCommerce. A question we need to ask is. Who are we trying to attract?

 

Newbies who just want a store but dont know anything about html etc etc or web developers that can take the osCommerce code, make improvements and contribute them back?

 

A newbie is just as likely to want their store to look and feel different to other stores as a web developer. If a newbie does not know how to do that themselves, then they will likely employ the services of a web designer. If that is to happen, then it must be possible to do at a reasonable cost, which means making life as easy as possible for the web designer, so they do not take too much time customising.

 

In the end - it's the designer/developer that the project structure needs to support.

 

-- JJ

[judgej]

I wanted to add this to my previous post, but got a permission error:

 

[PS A technical newbie will have big problems changing the layout of even the simplest HTML template. If it isn't point-and-click, then there is a big section of potential users that you have lost from the start. By the same token, I don't think you want those types of users if they have to start changing any templates, because the effort to take non-technical-savvy people through to having these kinds of skills is enormous. So again - it needs to be cheap and easy for those people to be able to go to a developer for custom changes, even if it just involves purchasing or downloading an off-the-shelf theme.]

[burt]

I've been reading this thread with interest. There's a lot of good points and some negative ones.

 

In my opinion, there is absolutely no need for any templating engine at all - it adds complications to an already over-complicated piece of software.

 

Dont you think that will make it more complicated to a new user rather than a basic template system which can be modified to make changes using just html?

 

What needs to be done is for the whole of Oscommerce to be updated to strict xhtml (getting rid of a lot of Oscommerce bloated code that was written 3 years ago and using html tags wisely to create the same effects), with ALL presentation controlled by the use of .css.

 

This is not difficult. Once done, the core code would never need to be looked at again. All changes may now be made in the .css stylesheet only.

 

Take a look at www.csszengarden.com for more info. It really is that easy, and also the code would be immediately chopped in half - no more nested tables to create an outline! No more functions to create a numbered list when an <ol> will do the exact same job with less overhead. And so on.

[blueline]

I've been reading this thread with interest.  There's a lot of good points and some negative ones.

 

In my opinion, there is absolutely no need for any templating engine at all - it adds complications to an already over-complicated piece of software.

Burt,

 

I completely agree with the you in the regards that NO templating system should be integrated.

 

While it might be difficult for the new user to really get down and customize the cosmetics of a osC shop, it is not hard to do. By giving up a few hours a week and studying (how else are you gonne learn) you can figure out the entire structure (both frontend and backend) of osCommerce.

 

I have been learning osCommerce for over a year now....and I think it's great just the way it is. I do agree with the fact that all the nested tables are a total pain......that's how it is. We can make sections of the software better (like finding an alternative for nested tables) but we would be foolish to try and change the software by adding 3rd party software, or by trying to develop a new application (in this case a template system) as that would eventually need it's own support as well.

[webpro]

The same goes for templating, what most people want to achieve is to be able to change the look and feel of a store without knowing any PHP programming. This is what will be introduced before 2.2 is finalised

 

I wonder if 2.2 includes the ability suggested above (and explored in detail in this thread) of separating the look and feel from the core program code?

 

Any update appreciated. I am in the early stages of evaluating OSC.

 

Peter

[Wendy James]

I have to say that I hate templating systems. I have tried the BTS and STS and find it much more complicated to add contributions to sites that have the systems in place... and often the contributions don't work or are not compatible.

 

Just my 2 cents. : )

 

If you view the roadmap you will see a template system and css layut for the catalog is being incorporated into the next release. http://www.oscommerce.com/community/roadmap

[timbeckham]

I have to say that I hate templating systems.

I completely agree. I tried Smarty and found that it provided me, as a lone developer, virtually no increase in ease of use or clarity of code. It was just another language piled on top of PHP. It didn't and still doesn't make any sense to me.

 

Templates are supposedly for development teams, where it is considered somehow better to isolate designers and core developers from each other's coding language, rather than teaching them how to respect each other's rice bowl. I'd rather spend the time teaching a little coding discipline, rather than the convolutions of a new language that shouldn't be necessary to anyone trying to make a living in this business.

[webpro]

I completely agree. I tried Smarty and found that it provided me, as a lone developer, virtually no increase in ease of use or clarity of code.

 

In some team development environments, separation of design from code does pay dividends. The Template Structure Implementation in the OS Commerce Roadmap look to be just the job.

 

When is that OSC v3 slated to be released?

 

Has anyone used Smarty with OS Commerce?

 

Peter

[goshafad]

Sorry if this is slightly off topic but can I enter sales and new customers manually into osc?