Need better understanding of the framework

1. A form has an ACTION attribute which determines where the POST'd data goes
2. The recieving *ASP* page has server-side functionality at the top of that page that fetches the arriving variables
3. At this point you might have local-scope variables or session-scope variables or even application-scope variables
4. At this point you're free to use code to write them to the database if you wish
5. The ASP page then has static HTML and inline dynamic data from those various types of variables

• In the shipping/payment areas it doesn't look like the Comment form field is being email'd or stored in the Order or Order_History tables at all. Why ask the information if it's not being stored? I actually need this data and have been fruitlessly trying to get it stored in the order_history table, for example.
• I've searched throughout the many pages and I see references to: $data['comment'], $this->session->data['comment'], $comment, nl2br($this->session->data['comment']), there's a comment field in order_history. I've attempted to use any of these in an attempt to store the data and they keep showing up empty.
• I'm interested in a form submission from the "checkout/payment" page to the "checkout/confirm" page. In theory, somewhere in the controller I'm going to store to variables those form elements that I've submitted. In theory, somewhere upon the "checkout/confirm" submission it goes... SOMEWHERE to server-side code. Where is this?

Qphoria wrote:Take a look at this... its high-level but may fill in some gaps
http://forum.opencart.com/viewtopic.php?f=20&t=4113

	public function confirm() {
		$this->language->load('payment/creditcard');
		$this->load->model('checkout/order');
		$comment = $this->session->data['comment'];
		$this->model_checkout_order->confirm($this->session->data['order_id'], $this->config->get('creditcard_order_status_id'), $comment);
	}

Qphoria wrote:From there, I am going to be doing a screencast of things like this in the upcoming week or so that will better clarify things.

JustinCase wrote:Hi,

I've been programming since 1984 and have felt pretty comfortable in almost every new language I've tackled over the years. I've written some incredibly complex software for the stock market industry so I wouldn't say that I'm a beginner programmer. Most of my experience over the last ten years has been in Microsoft ASP pages, my current task to add a payment into this website--if it were done in ASP pages--would have probably taken me no more than about three hours of work.

That said, I've already spent at least five full days of pulling my hair out trying to understand what is going on with OpenCart. I wouldn't say that any of this is "easy", having just read now all the glowing information about the benefits of MVC+L. So far, I'm mostly impressed by the obsfucation that's been added by this. For example, I was decyphering one page's output and what would normally be static text was coming from 1) the language file, 2) the controller/model code from the mysql db and 3) the template itself. You suggest that this code should only come from the language file itself. And yes, I know why you might put some text in the database--I've designed countless systems.

I need to add a payment method. It's really that simple. In fact, why on earth wouldn't you include a standard credit card processing method for people who have a brick-and-mortar store and have a POS system? You could just store the credit card information. But instead you only offer the ability to sign up with yet another middle man who wants a cut of the transactions.

So here I am, coding up another payment method. This should be simplicity itself. I should be able to duplicate one of the existing payment methods, change the names, change the variable names themselves and "install" it in the admin section. I've done this but now I'm completely flummoxed by the lack of documentation about HOW the pages submit data from a form back to itself.

In ASP page terms:

1. A form has an ACTION attribute which determines where the POST'd data goes
2. The recieving *ASP* page has server-side functionality at the top of that page that fetches the arriving variables
3. At this point you might have local-scope variables or session-scope variables or even application-scope variables
4. At this point you're free to use code to write them to the database if you wish
5. The ASP page then has static HTML and inline dynamic data from those various types of variables

That, to me, is easy and understandable. If I wanted to separate the MVC+L I'd do that by separating things in server-side includes, mostly. And yet, the work would be done.

--------------------------

So here I am with this OpenCart.

• In the shipping/payment areas it doesn't look like the Comment form field is being email'd or stored in the Order or Order_History tables at all. Why ask the information if it's not being stored? I actually need this data and have been fruitlessly trying to get it stored in the order_history table, for example.
• I've searched throughout the many pages and I see references to: $data['comment'], $this->session->data['comment'], $comment, nl2br($this->session->data['comment']), there's a comment field in order_history. I've attempted to use any of these in an attempt to store the data and they keep showing up empty.
• I'm interested in a form submission from the "checkout/payment" page to the "checkout/confirm" page. In theory, somewhere in the controller I'm going to store to variables those form elements that I've submitted. In theory, somewhere upon the "checkout/confirm" submission it goes... SOMEWHERE to server-side code. Where is this?

Guys, this isn't simple. You have multiple layers/shims of controllers and languages and views per page. *When* each gets called seems to be significant. The "checkout/confirm" page in theory has a server-side before rendering aspect to it and also a server-side after form submission aspect to it. So what/where is that anyway?

To make matters worse you sometimes have injected AJAX code into the button submissions. The ACTION aspect of the form submission is also obsfucated so much that it's difficult to tell where the page is going.

In a nutshell then my question is: When the customer clicks the final CONFIRM button on the "checkout/confirm" page, where does it go? What server-side code processes and writes the data? Why isn't COMMENT written? How do I know that my stored data from the "checkout/payment" page is preserved somehow?

My suspicion is that all these layers are each attempting to save the comment field in their own way and one is eventually overwriting my attempts to save this data. I'm weary of this project.

What is the difference and scope of these variables?
$data['comment']
$this->session->data['comment']
$comment
nl2br($this->session->data['comment'])

When is the order written? (Is it after "checkout/confirm" itself is submitted back to the server?) In theory, if I know that the order has been written to the database then I can make the SQL call to update the order_history table myself.

Seriously guys, the documentation needs a diagram of what happens during a form submission back to itself. There is nothing easy about the end of the point-of-sale process since it includes layers of modules in a stack: product, shipping, address, payment, coupon. It's not clear when a particular CMV set is being used to render a page itself and whether/not it processes the submitted form itself.

You have methods like confirm() in some of the payment extensions. But most of these extensions are dedicated to exporting the data to someone else's website in EDI fashion. All my attempts to keep the data here and store it are flummoxed by what is, to me, an overly complicated system.

Sorry for the bad review of OpenCart but I just felt you ought to know what it's like to use it as a long-time developer.

I imagine that the first question you'll ask is what version of OpenCart I have. Unfortunately I have inherited all this mess from an outsourced project from India. There doesn't appear to be version information written anywhere throughout. I actually had to google some of the error messages to deduce that it is OpenCart. Suggestion: Couldn't you just write the OpenCart version information into the META tags in the header like other developers do?

JustinCase wrote: What I find as odd behavior is that it's apparently /catalog/controller/payment/mypayment.php's duty to tell the database to write the record as an order and not code in something like /catalog/controller/checkout/confirm.php or /catalog/controller/checkout/success.php or similar.

Xsecrets wrote:I don't see how MVC is all that complicated it's very common place nowdays. If I'm not mistaken even many asp frameworks utilize it. Besides that if all you need is an offline credit card module you should have searched Q has a commercial one available at a very reasonable price I can't imagine that the cost would more than have been offset even if you did only take 3 hours to write it. Unless you are charging $5/hour.

Xsecrets wrote:what can you not submit a form to the same page in asp?

Xsecrets wrote:can't really argue too much here I have no idea why Daniel feels the need to have every button activated by javascript, and that has been complicated quite a bit in 1.5 with the onepage checkout you have to dig through all the javascript at the bottom of the checkout.tpl file to figure out what each button click does under different circumstances, but much of that complication is required to have a one page checkout.

Xsecrets wrote:well you are dealing with the most complicated portion of the system, an most of it is by necessity. each time you click one of the buttons it uses ajax to send that data back to the next controller and return the next step.

Xsecrets wrote:Opencart does have version number as the first variable in the index.php and admin/index.php by default.

JustinCase wrote:Why didn't I notice this when I went in to add the checkbox? There's no sourcecode formatting in the TPL files themselves since they likely have the UNIX-style hard returns in them. Without any sourcecode formatting of whitespace then everything's just a mess and you're unlikely to see a block of Ajax scripting at the bottom.

Xsecrets wrote:well you are dealing with the most complicated portion of the system, an most of it is by necessity. each time you click one of the buttons it uses ajax to send that data back to the next controller and return the next step.

...hence the need for some documentation about the various ways that navigation happens within OpenCart. Having just gone through this with a fine-tooth comb it looks like there are default (non-Ajax) navigation-related pieces that are being ignored when the designed has now decided to drop in some Ajax. The net effect is that the person like myself sees the standard navigation, thinks that it's what is supposed to happen, and then is surprised when some other behavior is happening instead.

Xsecrets wrote:Opencart does have version number as the first variable in the index.php and admin/index.php by default.

Looks like it's 1.4.8 then.

I guess the short version of my rant is: don't suggest that all this is EASY given the way it was implemented. If you subtracted all the Ajax and JavaScript submission eccentricities out of OpenCart then you could try to claim that all this is straightforward.

I do understand that it is opensource and nobody is obliged to assist...