So I am trying to help my wife build a website to sell T-shirts. I have a decent programming background, but am pretty new to PHP, LAMP, and Web-things. (My background is with MS Access/VBA, VB, etc.)
I understand how to use PHP to do basic programming things on the server, but am quickly realizing that I am over my head with dynamic website?!
I have been working through this book that shows you how to build an e-commerce site, but am completely lost at this point.
The author is using Smarty, and I believe that is where I am getting REALLY lost.
So, I guess that leads me to some questions… (Sorry, trying to keep this post succinct!!)
[b]
1.) Is there something better than Smarty?
2.) How does Smarty relate to MVC?
3.) What is the best way for a newbie to build a modest Dynamic Catalog?[/b] (The author took 6 chapters to teach how to do this, and I just don’t think it has to be so difficult!!)
I am hesitant to get into any complex things like Zend, Cakewalk, etc because I believe in “Less is more” - especially when you are still cutting your teeth.
My goal - for now - is to build a modest online catalog where potential customers can browse (e.g. Departments, Categories, etc) and do basic searching for items.
Obviously I want to avoid writing spaghetti code that doesn’t scale and that is a nightmare to maintain, but I also don’t want to take 20 years to get this website done!!
The author’s end product looks nice so far, but it just seems like he is using 10X the code you would expect.
If there are any experts/gurus out there that can get me pointed in the right direction, that would be appreciated.
(And sorry again for the broad post, but I am not sure where to focus my time.)
1.) Is there something better than Smarty?
plain ol’ PHP
2.) How does Smarty relate to MVC?
By loading a Smarty template with data you can keep your controller and display layer separate. However, you can easily create that distinction your self using your own simple template system w/o Smarty. Smarty is by no mean necessary a necessary component of MVC.
3.) What is the best way for a newbie to build a modest Dynamic Catalog?
The simplest and most used pattern is something like Magento where you create a category tree and link products to each category of that tree. As for the distinction between departments and categories aren’t they one of the same? IE. Shoes would be a category on your menu and is also a department?
I’ve been using Smarty for about 9 months on the project I’m working on and still prefer just PHP. There some neat things in Smarty but at the end of the day I feel PHP itself is the best template language. Let me just put it this way – nothing I can’t recreate or live without.
As for the catalog in the book your working on not sure what to say. Normally well structured and thought out code looks a little more lengthy than something strung together not using OO methodologies.
Okay, although from the little I have read, Smarty is supposed to less verbose.
2.) How does Smarty relate to MVC?
By loading a Smarty template with data you can keep your controller and display layer separate. However, you can easily create that distinction your self using your own simple template system w/o Smarty. Smarty is by no mean necessary a necessary component of MVC.
That is good to know.
A follow-up question would be, "Is it more important that I learn and master MVC or some Template Engine like Smarty?
(Over time I want to learn everything, but since time is important to me/us, I’d like to focus on the things that will help me build this site.)
3.) What is the best way for a newbie to build a modest Dynamic Catalog?
The simplest and most used pattern is something like Magento where you create a category tree and link products to each category of that tree.
Isn’t Magento like a pre-packaged, open-source e-commerce package?
Can you give me a more specific example of this tree you are referring to?
As for the distinction between departments and categories aren’t they one of the same? IE. Shoes would be a category on your menu and is also a department?
In the book, the author says, “Products can be in multiple Categories. A Department is composed of multiple Categories.”
I’m not sure I would set things up that way, but then again, I haven’t thought things through on the business end. I’m just trying to see if I can do the technology part or not!
I’ve been using Smarty for about 9 months on the project I’m working on and still prefer just PHP. There some neat things in Smarty but at the end of the day I feel PHP itself is the best template language. Let me just put it this way – nothing I can’t recreate or live without.
What do the “pros” use?
What is the “Cadillac” of creating the “presentation” layer and making it scalable and flexible?
As for the catalog in the book your working on not sure what to say. Normally well structured and thought out code looks a little more lengthy than something strung together not using OO methodologies.
True, but I just don’t necessarily agree with how the author is organizing things. First off, he seems to be just wrapping procedural code (i.e. functions) in objects which isn’t true OOP.
I guess I would never make it as part of a development team, because I just have my own way of organizing code. (No one ever complains about how I code, but I often have a hard time getting my hands around how others code/organize code.)
It looks like your Smarty question has already been answered. I’ve personally never used Smarty, so I can’t comment on it, however, that fact alone means it’s obviously not a requirement. In fact, if you really want to learn PHP, I would avoid all frameworks and templating systems like Zend Framework, CakePHP and Smarty, etcetera.
That’s a slightly ambiguous question, but it highlights that you really don’t know where to start or even what resources to look to for help, which is to be expected from anyone learning a new language or in your case, a new language AND the web.
To start with the obvious, HTML and CSS knowledge is a must have. You won’t get far in the web world without decent (X)HTML and CSS skills and knowledge. Hand-coding is definitely preferred when it comes HTML and CSS, simply because it’s the only way to do it. No WYSIWYG editor will ever match or beat hand-coding.
Moving onto the “dynamic” side of things, or rather, PHP. I would just focus on learning the language before you start thinking about anything larger than a simple script. Once you know the language, then you can apply programming models and paradigms to your fresh PHP skillset and go from there. When your motivation for learning a language, is motivating by the desire to get something made or working (in your case an online store), it’s hard not to look at the bigger picture, but the only way to go about this process of learning is step-by-step. By focusing all your attention on what your learning or doing at this moment, you’ll speed up the process and end up with a significantly better result.
Not really, but I’m working on going through the author’s code again to see if I can figure out where I am lost.
I’ve personally never used Smarty, so I can’t comment on it, however, that fact alone means it’s obviously not a requirement. In fact, if you really want to learn PHP, I would avoid all frameworks and templating systems like Zend Framework, CakePHP and Smarty, etcetera.
Okay.
[Quote]
Originally Posted by TomTees View Post
3.) What is the best way for a newbie to build a modest Dynamic Catalog?
That’s a slightly ambiguous question, but it highlights that you really don’t know where to start or even what resources to look to for help, which is to be expected from anyone learning a new language or in your case, a new language AND the web.
To start with the obvious, HTML and CSS knowledge is a must have. You won’t get far in the web world without decent (X)HTML and CSS skills and knowledge. Hand-coding is definitely preferred when it comes HTML and CSS, simply because it’s the only way to do it. No WYSIWYG editor will ever match or beat hand-coding.
Moving onto the “dynamic” side of things, or rather, PHP. I would just focus on learning the language before you start thinking about anything larger than a simple script. Once you know the language, then you can apply programming models and paradigms to your fresh PHP skillset and go from there. When your motivation for learning a language, is motivating by the desire to get something made or working (in your case an online store), it’s hard not to look at the bigger picture, but the only way to go about this process of learning is step-by-step. By focusing all your attention on what your learning or doing at this moment, you’ll speed up the process and end up with a significantly better result.[/QUOTE]
Well, I think I know XHTML, CSS, and PHP fairly well. And I do hand code XHTML and CSS.
The ambiguity of my question isn’t as much a lack of technical knowledge of the languages as it is, “Where is the best place to begin?” and “What is the best approach/design to use?”
Having purchased thousands of $$$ of items on Amazon.com, I feel comfortable with how an online catalog looks and works.
At the same time, I feel intimidated about how to build one that is mature, scalable, maintainable, and well-coded.
I figured there must be some general guidelines/approaches/blueprints for creating a robust online catalog.
(The author’s end results look okay so far, but it is also nice to seem other approaches so I can choose what I think is best.)
If all you want to do is create a web shop for your wife, then you might want to start with an e-commerce product (like the already mentioned magento, look here for some others). It’s the easiest way, since you wouldn’t have to do any programming, except maybe some graphical customisation.
And even if you want to learn how to write a webshop all by yourself, you still might want to start using an existing program to get your wife’s shop started, and then begin studying
I’d be more than happy to help you along the way. Actually, building an eCommerce shop was my first significant PHP project, and my first commercial web project for that matter (kind of a risky platform; dealing with credit card transactions and all). I was only 16 when I started the project, although it took me almost 2 years to finish as I was a bit of procrastinator and had other interests. Obviously, looking back at the code, it was pretty bad, but I’m still pretty happy with the user interface; designing websites is what forced me into PHP, I wanted to make my static sites do something.
Anyway, enough about me and my background.
Guido makes a good point. If you really want to get your your wife’s shop online, then a pre-made solution will be a good route to take, at least while your making your own custom solution.
I know exactly what you mean. After programming in PHP for 4 years (and many other languages for the past 6 months), I’m still trying to find the perfect combination of coding paradigms and best-practices. Trying to make something potentially complex, into something simple, while making it very maintainable, scalable and generally easy to work with is a difficult balance to achieve. Designing and coding a complex system or application is one thing, and just about anyone can do it. Making that system as simple as possible while maintaining power and flexibility is the real art in my opinion.
That last paragraph probably didn’t help you from a practical perspective, so let me touch on some of the main points to consider when building an eCommerce application and really any other application for that matter.
Requirements - Know your requirements. Jot down what services the website needs to provide. A good way to do this is to simply list the requirement pages or sections, such as: Category List, Product List, Product Details, Shopping Cart, Checkout, Customer Accounts (creation, management and login handling), etc. Depending on your requirements, you may only need a single list of products and a simple one-product-per-order checkout system, meaning you would only require a product list and a simple checkout.
Planning - While it’s difficult to plan without experience, there’s still much to gain from this initial stage of development. To plan effectively, while experience helps, knowing about the relevant available technologies is arguably more important. For example, considering your requirements, you’ll want to use the PHP PDO class for interacting with your database engine, and you’ll definitely want to learn about SQL transactions which are quite critical when it comes to dealing with credit card transactions and other multi-step processes which either needs to 100% succeed, or completely fail (in other words, where you don’t want half the steps to complete and the other half to fail).
Application Design - Another difficult stage of development for anyone lacking experience. It sounds however that you have programming experience and a decent understand of OOP, so this probably won’t be too hard for you. Still however, designing a robust, maintainable and scalable system is still difficult. Basically, as long as you use some form of MVC pattern, you’ll at least be on the right track to accomplishing those desirable attributes such as scalability and maintainability.
Web Design/User Interface - Depending on personal preference, you can do this before the application design phase or even before any of the other steps if designing is really one your things (I’m normally guilty of designing the look of a site before doing any formal planning or requirement considerations. Like with all the other aspects of web development, you should aim for simplicity over all other things.
The steps after that are pretty self explanatory. You have the actual development of the site (coding) plus of course testing and deployment. I realise I still may not have answered your questions on how to create a “mature, scalable, maintainable, and well-coded” eCommerce application, but to avoid talking about abstract concepts, it would be better if you started with the Requirements and Planning stages. Post back with that information and we’ll go from there (I can help you via PM or email if you’d prefer).
Let me try to give more specific questions about designing an interactive catalog…
Let’s say you have 100 products, and would like to display 9 products/page with a thumbnail, product name, price, and brief description. The “product area” would be surrounded by other permanent parts of the your website (i.e.
top area is a header, and left margin having navigation, TOC, etc.)
The nine products should be displayed in 3 rows and 3 columns. (A scalable site would allow you to change this to 4X4, 5X5, 6X6, etc.)
So how do you do that using PHP (with or with a template like Smarty)?
Presumably, you would do it the same way that photo sites display thumbnails on the fly?! Maybe creating a “grid” and then traversing the webpage from the upper-left corner (of the “product area”) to the lower-right corner in an “S”-like fashion?
Could I program that myself so it works dynamically? Probably with lots of time.
But is there also some “best practice”, “pattern”, and/or “template” that was long ago created to tackle this common problem? Certainly!
And so my original post was trying to get my hands on these common “patterns” that a dynamic catalog and e-commerce site would use.
So what is the purpose of Magento? (Haven’t had time to check out the site yet.)
Is it open-source?
Is it a pre-packaged, finished e-commerce site that you just customize?
Or is it just a framework that makes it easier to build your own e-commerce site?
As far as the “E” part, what would you have to do using Magento to accept credit card payments and have the payments show up in your Merchant Account? (i.e. no 3rd payment processing or funky PayPal stuff)
Have you ever used Magento?
And even if you want to learn how to write a webshop all by yourself, you still might want to start using an existing program to get your wife’s shop started, and then begin studying
I am pretty comfortable with this, but at the same time, I am trying to just learn how to build a generic e-commerce site as a “proof of concept”.
If it is something I think I can do in a reasonable amount of time, and have the features we want (e.g. accepting credit card payments on our site with no 3rd party sites involved), then I can step back with my wife and do some more thorough planning and what-not.
But at this point, I just want to see how realistic it is for me to build a true e-commerce site…
I’d like to dedicate this novel to my two cats that died during the course of writing this book; Sir Joseph and Sir Joseph Junior., and of course I’d like to thank my Mum for never giving up on me along the way.
Similar, yes, the same, no. MVC as you would knows stands for model, view controller (which should really be “CMV” as that’s usually the order of execution). What the author is talking about is slightly more abstract. The presentation layer would be a combination of “View” and “Controller”, where as the business layer would be a combination of “Controller” and “Model”. The database layer would technically be part of your model in MVC, although more specifically, the database layer would normally refer to the API used to interface with the database, where that be the MySQLi or PDO extensions of PHP, or an ORM (object-relational mapping; don’t worry about knowing what this means; google it if you really must know). So PBD as I’ll unofficially call it, does not map 1:1 with MVC. MVC is more of a programming “pattern” where as PBD is more of a programming “ideology”.
It took me quite some time to grasp what MVC was exactly. It wasn’t until I actually had hands-on experience through experimentation that I really understood how it worked and what the advantages of it were. Also keep in mind that there’s many ways to implement the MVC pattern. As long as you separate your “controller” logic (which is usually responsible for talking with the model and the view), your “view” logic (usually HTML + presentation logic like; for example, where or not to display a certain <div> block) and your “model” (the thing that actually does stuff, like retrieve a list of products, insert a blog article into the database, do calculations), from one another, then you’ll be using the MVC pattern.
First of all, to tell you how this may fit into the MVC way of doing things. In such a scenario, the controller may get from the browser (via POST or GET data) the page number to display and the number of products per page, it would then give this information to the model and instruct it to get working. The model, using the provided information, would calculate which products need to be returned from the database. For example, if it was told to retrieve 9 products from page 3, assuming page counting starts at page 1, the model would know that it needs to get products 19 - 27 (inclusive) from the database. The model will the likely return the 9 products as a return value of the method called. So as a simple example, if the controller called the following method on the model: $model->getProducts(3, 9); then the model may return a multi-dimensional array containing information for each product, such as title, price, etc. From here, the controller would provide the view with this information. The view would then generate the html, and send it back to the controller, which may then slot that into the site theme/template, which would ultimately get sent to the browser.
There are no rules as to how the MVC pattern should hang together. I’ve seen MVC implementations where the controller gives a view object to a model, where the model is then responsible for providing the view with the required data and calling it’s “render()” method or something of the likes. I’ve also seen MVC implementations where the “model” object is given to the view. The view is then responsible for calling methods on the model objects such as getProducts(); although if this were the case, using the example given earlier, getProducts() shouldn’t take any arguments in this scenario. The page number and products per page would be given to the model by the controller before the model is given to the view. For example…
$model->setPageNumber(3);
$model->setProductsPerPage(9);
$model->do(); // Model queries the database and gets the result, returning true on success and throwing an exception on failure.
$view = new ViewProducts();
$view->setModel($model);
$html = $view->render(); // View generates HTML output by calling known methods of the model, such as $model->getProducts();
There are no wrong or right ways to implement the MVC pattern. You’ll eventually work out which method suits you best. When you include all the other parts of the picture such as Themes, Error handling, Database Connectivity, etc, you’ll quickly realise how a relatively common problem can be solved in a million different ways, even if a common pattern is shared amongst the millions of possible implementations.
The responsibility for this would fall under either the “View” or the “Controller”. The view may be provided by the controller, a “template” or “theme” object which the view can use to insert the HTML it renders, into the context of an entire web page. It may then output this directly completely bypassing the controller on the way out. Alternatively, the controller could be responsible for inserting the HTML it received from the view, into a site template. Once again, there are many many ways to skin this cat (I don’t condone skinning cats by the way).
The nine products should be displayed in 3 rows and 3 columns. (A scalable site would allow you to change this to 4X4, 5X5, 6X6, etc.)
A scalable site wouldn’t necessarily need to do this dynamically, as in on a per request basis, although it certainly could if you wanted it to. A scalable, or rather, a maintainable site in this case, should allow such a change to be easily implemented by the developer without affecting any other parts of the system, except for the part that determines how the products are displayed. In the case of MVC, that would be the view. That’s a very simple example of why MVC is such a commonly used pattern. It allows you to completely change the how the website or a particular web page looks, simply by changing the view, without having to change the controller or the model in any way. The same applies to the other components. If you wanted to store your products in a text file instead of a database, then you should only have to modify the “model”. The view and controller shouldn’t need to be changed in any way.
I’ve already given plenty of examples above, but to address the subject of “Smarty”, as you can see above, “Smarty”, if you wish to use it, would only be used by the view and the theme system, or maybe even just the page templates.
What the actual resulting HTML looks like would of course be the responsibility of the view. Whether you use tables, or a inline blocks, only the view would need know this.
As mentioned, there are many ways to skin the proverbial cat. There are patterns out there that are very common, but the implementations will always differ. They say don’t re-invent the wheel, but there’s no harm in improving or customising the concept of a wheel. A wooden wheel may good on a cart, but pretty useless on a race car. Depending on the application, the requirements, the developer, etc, the implementation will always differ. An online shop that only ever sells one products at a time, could get away with a very simply MVC implementation. Where as an enterprise-level eCommerce solution would likely require a very complex and much more verbose MVC implementation in order to support the scalability and flexibility requirements of such an application.
This leads me to one important point. Scalability isn’t a desirable attribute for all applications. If we were to make a simple single-product online shop extremely scalable, then it would likely take a very long time to code, be as slow as a dog, and ultimately hard to maintain. Maintainability however, is always a desirable characteristic, with the exclusion of very tiny applications, where maintainability is an unavoidable consequence of such small systems, no matter really how you code it (I’m referring to applications with only a couple of pages and maybe up to 1000 lines of code).
Magento is an open-source eCommerce solution (there is also a commercial version). It’s a ready-to-go online shop in other words. Technically, you don’t need to know a thing about HTML, CSS or PHP to get it up and running. Of course, the level of customisation and flexibility you can get from such a system without knowing any of the aforementioned technologies is extremely limited. Even an expert at HTML, CSS and PHP however would first need to learn the code behind the system before they could start making any changes. Magento’s the biggest and most complex online shop I’ve personally ever seen, so I would imagine it would also be the most unfriendly towards developers (what I’ve reads online backs up this assumption of mine). Magento is overkill for probably 90% of online stores, but on that note, the quality and practicality of available PHP-based open source eCommerce solution is generally quite low in my opinion. Magento is arguably one of the higher quality products out there, but that doesn’t mean I would ever want to touch it. Simplicity is always number one priority for me, and for that reason, I’d have to be force fed Magento before ever playing with the code behind it (the user interface is bloated enough for me).
If you’re mainly interested in proof of concept, then identifying your requirements and doing proper planning is probably even more important. By starting with the requirements and identifying exactly what things would be required to get an online shop up and running, you can better assess whether or not you can actually create an eCommerce site from scratch yourself. When you have a list of requirements and have a decent idea of the functions and services your application will need to provide, then you can start working on “proof of concept” PHP code, to experiment with how you may piece these things together.
I don’t doubt that a year after you build this site (assuming you do), you’ll be quite unhappy with how you went about making it. The code will look ugly, you’ll wonder why you ever did X like that, and you’ll probably be begging your wife to give you permission to start from scratch again
If that doesn’t turn out to be the case, then you’ve either stopped or done very little programming since completing the project, or you have not challenged yourself a single bit since.
You will required to communicate with your service providers API to process credit cards on-line. You will have to work with other peoples code and/or API to do that. No getting around it. Ideally your service provider would offer some type of Web Services API to process credit cards which you can then write your own API to communicate with to do all credit-card processing you want.
