Symphony.

I think it is perfectly possible to do the calculations in XSLT, but it's not trivial. :-)

So would you rather keep the price field or create a dependency (with the Number Field)?

just off the top of my head, when you're inside shopping-cart:

<xsl:value-of select="sum(item/@sum)" />

should do the trick. just plain old xslt 1.0

cheers,
daniel

Ha, there wouldn't be any @sum if there was no price field. :-)) You would have to add another datasource with your section data (filtered by cart item IDs) and ideally use keys to grab the data you need.

Wouldn't sum(/shopping-cart/item/@sum) give you the total?

Too slow, Nils.

You would have to add another datasource with your section data (filtered by cart item IDs) and ideally use keys to grab the data you need.

I think the exslt solution i mentioned is the other alternative...
I've used it before and works well.

But all together i would vote for keeping the price field, it makes it alot more accessible... Or the extension should have some example xslt in the readme for calculating?

@michael-e: sure thing :) i was just referencing to Cremols example.

if we get rid of the field altogether one would have to create a relation between ones shopping-cart and the product data-source where the prices are managed. probably cleaner, but a bit more work on the backend. you probably want to always be able to count the items and sum their value if you use a shopping cart, wouldnt you? so i dont see the point in removing the values.

Too slow, Nils.

I'm getting older.

you probably want to always be able to count the items and sum their value

No, not really. I may have a "shop" containing free items only.

Basically, a shopping cart is just items and their numbers. The price (and calculations on it) is an additional "comfort-feature". I just wonder if and how it should be baked in.

one would have to create a relation between ones shopping-cart and the product data-source where the prices are managed. probably cleaner, but a bit more work on the backend.

One could do that in XSLT. Or we could keep the price feature, but drop the dedicated field and add a configuration option which (standard Input or Number) field of section should be used as price field.

No, not really. I may have a "shop" containing free items only.

I think this is an exception, 99% you would want to use the price field.
A good alternative would be to make the pricefield optional.
So you can choose to use the calculating or not...?

Michael, don't you suggest converting the Shopping Cart extension to a more flexible Clipboard extension that stores data lists in the current session?

No, not really. I may have a "shop" containing free items only.

Basically, a shopping cart is just items and their numbers. The price (and calculations on it) is an additional "comfort-feature". I just wonder if and how it should be baked in.

ok you're right. additionally to go with symphony's functions-not-features approach, dropping the values is probably the right choice.

i was just wondering if it's the right choice to exclude something that is theoretically not always needed to manually include it because it is practically always needed.

i personally would have no problem with adding my own prices via ds filtering from a dedicated section.

just my two cents
daniel

I think this is an exception, 99% you would want to use the price field.

Don't make assumptions. :-)

A good alternative would be to make the pricefield optional.

Indeed I thought of that.

Michael, don't you suggest converting the Shopping Cart extension to a more flexible Clipboard extension that stores data lists in the current session?

I just think about the price feature. If it is a desired feature, there are still two ways to deal with it:

• keep the dedicated Price Field
• use a different field (e.g. a number field)

The Price Field has two advantages:

• automatically validating the input (requires input like 123.45)
• a range filter (is this used by anybody?)

Using a different field would simply require less code (which generally is a good thing, isn't it?).

Another thought regarding the price field: It should indeed allow more digits (cause you might have item prices like 0.886 $) and negative numbers (for "voucher" items), shouldn't it? This is exactly what the number field allows, right?

As far as I have seen, the number field has X to Y support and Equal to or less/greater than X support in the datasource filter. Can anybody explain if the Price Field has any advantages here? (I never used it, so this is a serious question.)

BTW: From what I see at the moment, supporting non-english numbers, e.g. the German "20.000,95" notation, will not be (easily) possible with either of these. (It has never been a supported feature, however.)

@michael: IMO the numbers stored should be regular floating numbers (20000.95 in your example). You'll be able to mark this up with XSLT and the format-number function. The conversion from float to money can be done with the NumberFormatter class.

This way you can display a nice number in the backend and frontend, but still keeping the number itself a float, so you can do calculations on it easily.

Yes, it's rather simple in XSLT. Regarding the backend, I think that using the NumberFormatter class would be an interesting addition (to the Number field in the first place), but this class requires PHP 5 >= 5.3.0. I don't think it's very important though. Clients get used quickly to writing decimal dots instead of commas.

Depending on tax, etc., it's sometimes necessary to store four decimal places to avoid rounding errors. So I don't think the price field should arbitrarily limit to two.

@michael: doesn't Symphony require 5.3 already?

@david: true, which is why I suggested to store the value as a float (which has more precision than you will ever need), and just format that number when you need to show it.

Symphony 2.3 dropped support for PHP 5.2 so the requirements of the class shouldn't be a big problem in the long run.

Why don't you do the following:

• Remove the price field from the Shopping Cart extension.
• Update the number field to accept international decimal numbers.
• Create the price field as a separate extension that extends the number field and interacts with the Shopping Cart extension.

+1

edit even though I think bundling the price field isn't a bad idea either. If you name the extension shopping cart, having a price field makes sense - otherwise it should be name lists stored in session :-)