line return "within" text area

Legacy Dynamo
21

Okay, so now, instead of dumping them right into the order and payment
form after they click a button, you want them to be able to continue
shopping, maybe order something else? You would need to modify your
form handler page a little, and maybe offer a choice: Check out? or
Continue shopping?

To add a product purchase to your session, you would need to take all
the inputs sent to the form handler and put them in a recognizable
shape. I would probably do this:

$id = array($price => $qty);

If they order the same thing a second time, that would overwrite the
current quantity with the new one. I’m not sure I would even accept
the price sent by the form, that’s just making it too easy for someone
to rob you. Look it up again from a known standard, like an include
file that you use in both the shopping page(s) and the order processor
page. So you could just store $id = $qty and be done. There’s one tiny
thing that you have to attend to, though, and that is that a variable
name cannot start with a numeral. So you’ll have to prepend a string
to it to make it safe as a name:

session_start();
if(isset($_POST['id'])){
	$_SESSION['id_' . $_POST['id']] = $_POST['qty'];
}

//$id_123 = '4' or something like that.

Then you just have to loop over your product ids and get the quantity
for each while building your display of products ordered:

$products = array('123' => array('5-string Banjo','25'),
	'456' => array('Beaver-shaped shoe scraper','45')
	'789' => array('Plate glass window','750')
);
$total = 0;
$cart = '<p>';
foreach($products as $id => $product){
	if(isset($_SESSION['id_' . $id])){
		$qty = $_SESSION['id_' . $id];
		$extended = ($qty * $product[1]);
		$cart .= . $product[0] . ' quantity: ' . $qty .  ' subtotal: $' .  
$extended '<br />';
		$total += $extended;
	}
}
$cart .= '</p>';

That’s very rough, but it should show you the beginnings of how this
works.

Walter

On May 28, 2010, at 2:44 PM, David Owen wrote:

I have not got round to doing anything on the session code yet, just
exploring what is possible (I’ll try and take a look this weekend)

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

22

You’re right not risk doing it this way if they were selling 48" plasma screens. But for small stuff that has to go past “a real person” for checking its probably OK, providing you create suitable terms and conditions to decline orders that are fraudulent.

Just to explore this issue a bit further for the sake of it. WebYep stores the price field in a flat text file on the servers, the problem is, it looks like its taking that data along with the URL and relative position in the loop it performs on the page to get the right data, so just using the API code on the form page would not work unless sending all relative stuff that along with the form which mean understand exactly what is working in the WebYep system ;(

I suppose a work round for this would be to take a known value from the server or the cart page URL to authenticate the POST is coming from the right place? And only display the order form if that is true ~ would that be secure enough?

–

David

On 28 May 2010, at 20:24, Walter Lee Davis wrote:

I’m not sure I would even accept the price sent by the form, that’s just making it too easy for someone to rob you. Look it up again from a known standard, like an include file that you use in both the shopping page(s) and the order processor page.

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

23

Basically, what I am doing here is only trusting the customer to say
“how many, and of what”. The other value (price) comes always from the
server. The customer can send the price to the form handler if they
like (you don’t have to change your current form) but your form
handler should ignore it. If WY has the price on the server, that’s
great. If your form handler can pull the price data from the same
place, then you will have the same degree of security as my example
(which didn’t use WY to make the form).

Walter

On May 29, 2010, at 4:59 AM, David Owen wrote:

You’re right not risk doing it this way if they were selling 48"
plasma screens. But for small stuff that has to go past “a real
person” for checking its probably OK, providing you create suitable
terms and conditions to decline orders that are fraudulent.

Just to explore this issue a bit further for the sake of it.
WebYep stores the price field in a flat text file on the servers,
the problem is, it looks like its taking that data along with the
URL and relative position in the loop it performs on the page to get
the right data, so just using the API code on the form page would
not work unless sending all relative stuff that along with the form
which mean understand exactly what is working in the WebYep system ;(

I suppose a work round for this would be to take a known value from
the server or the cart page URL to authenticate the POST is coming
from the right place? And only display the order form if that is
true ~ would that be secure enough?

–

David

On 28 May 2010, at 20:24, Walter Lee Davis wrote:

I’m not sure I would even accept the price sent by the form, that’s
just making it too easy for someone to rob you. Look it up again
from a known standard, like an include file that you use in both
the shopping page(s) and the order processor page.

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

24

I don’t really think this is an option as being a CMS you would have
to track which button was being selected on which dynamic page related
to the file and the position in the loop created by WebYep ~ I’ll look
at the datafile to see how it’s formatted.

David Owen

On 29 May 2010, at 15:26, Walter Lee Davis email@hidden wrote:

If WY has the price on the server, that’s great.

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

25

When you click one of these buttons, you are sending a form (one form
per product) to the handler script. One of the elements in that form
is a hidden field called ‘id’. That will tell you which product is
being sold. Does that help you?

Are you making these form elements with WY? Is that a standard part of
WY, or something you wrote yourself?

Walter

On May 29, 2010, at 10:47 AM, David Owen wrote:

I don’t really think this is an option as being a CMS you would have
to track which button was being selected on which dynamic page
related to the file and the position in the loop created by WebYep ~
I’ll look at the datafile to see how it’s formatted.

David Owen

On 29 May 2010, at 15:26, Walter Lee Davis email@hidden wrote:

If WY has the price on the server, that’s great.

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

26

The form button I’m creating in Freeway. Any ID would be duplicated as
WepYeb is creating a loop as the user adds his products. Adding
another loop for each product.

Protecting the POST like Freeway/Mals actions using GET, would be the
only way. Or sending a key? along with the form.

David Owen

On 29 May 2010, at 16:23, Walter Lee Davis email@hidden wrote:

Are you making these form elements with WY? Is that a standard part
of WY, or something you wrote yourself?

dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options