Symphony.

Create the price field as a separate extension that extends the number field and interacts with the Shopping Cart extension.

I thought of something very similar: Keeping the Price Field in the extension, but make it extend the number field, without overriding any relevant Number field methods. So there would be no "special price field features" for now, but we might add them in the future. And we would be pretty backwards-compatible (cause the DB table has the same structure, despite the value's type which might be changed by the updater function).

even though I think bundling the price field isn't a bad idea either

Yep.

Update the number field to accept international decimal numbers.

I don't have very much time, so let's make this a different project (for someone else).

BTW: Still waiting for @designermonkey to jump into this discussion.

Sorry to delve in on this so late in the conversation, been a busy 13hr day.

As far as I am concerned, the price field should be separate and shouldn't be an extension of the number field, it needs a float column fo a start, so should build its logic separately. Although I can see the benefits of bundling it, I may want a price field but not a cart.

This ext should be renamed to basket as it then covers more use cases, like wish lists etc... I have a huge project coming up that will mean lots of development on baskets and wish lists, so this field will be getting lots of designermonkey-love (TM) anyway. I have yet to review the pull request.

If it were a separate field, it could have so many more features:

• default currency
• List of available currencies
• Auto lookup and cache of currency conversion form a 'provided' api call

Also, the cart shouldn't link to a price by default and instead shoul rely on Symphony logic to just reference the section and entry by id, allowing more logic for price calculation based on location, kind of like a session sbl, so a transient data sbl. All the extra logic that was added to this extension has just narrowed its usefulness to just a shopping cart, not, as described earlier, a session list extension (but better as a transient sbl).

I hope this makes sense, I'm soo tired and on an iPad.

Again.. late to the convo.. been to an Eletric Six gig.. dont ask ;) Basket extensnsion does sound like a good idea. I'd agree with separate price field for many reasons that have already been mentioned. Would love to see progress here.. shall I send pull request from my code.. It's a repo without weight field.

No, you have built upon a different repo, not the original one.

In order to make this effort successful, please wait until we have cropped the 2.2.x branch. Then we can integrate the changes for Symphony 2.3.x.

Ok no worries.

@designermonkey:

Hmmm, all the others voted for the price field being baked into the extension. If we make it a separate extension, we create an additional dependency. And we may have to give up calculating prices in the cart, because maybe the cart can't understand nor replicate the price field's magic.

So do you propose to give up calculating prices in the extension? Or would you prefer to have an (optional) selector to choose a field (be it a Number or a Price field, even an Input field), then try and do calculations if possible? Or require at least one price field extension to be installed? :-)

As soon as we allow for multiple carts (which is very high on my personal wishlist), selecting price fields will be difficult anyway.

And couldn't a cart (or should I say "basket"?) even contain items from different sections? So where is the price field then? (Hey, here is only one of several cool ideas of the original extension: Data added to the cart will only pass validation if a price field can be found for the item. So the dedicated field type has the benefit of "activating/allowing" a section's items for the cart.)

Like I was saying, but not making sense by the sounds of it....

This extension should be brought back down to it's basic function, which is providing a basket area in a session. Forget any fields, they were additions at a later date.

So do you propose to give up calculating prices in the extension?

Yes. Calculations should be done in xslt as far as I would have thought. It's not a big deal to do, and sometimes the pice calculations may need doing wholly different to how the extension does them; VAT? Discounts? Multi-product discounts?

Definitely want to work on the multiple sections and baskets, this adds additional functionality to the core use cases for this extension. It will make the price calculation almost impossible, but as I say, I think this is too narrow a use case scenario for something that should be flexible and simple.

I must say however that I'm not willing to wait for a 2.5.x work to be done as we are moving further into 2.3.x so I personally think it a pointless exercise.

Irrespective of the decisions here by the team, I will be doing this work as I think it should be done for a project anyway, whether that be the code that we use in the future or bespoke to the project.

I hope to have a project coming up that will need this functionality, so I've been giving this a bit of thought lately. You guys have this thread on fire!

I've read through everything and my initial thoughts were along the line of @designermonkey. I'm not convinced that fields are necessary. I believe adding fields will make this extension work within a narrower focus.

I think it's best to keep this basket extension basic and provide helper functions for advanced developers to bake into their specific, more advanced use cases.

I also think development should be focused on 2.3.x

@designermonkey:

I must say however that I'm not willing to wait for a 2.5.x work to be done as we are moving further into 2.3.x so I personally think it a pointless exercise.

Great, so feel free to start right away. I will build my own, private 2.2.x extension then, which saves me a lot of time at this point.

(If you knew my app, you wouldn't volunteer for updating it to Symphony 2.3. This is something that has to wait a bit. Moving forward is great, sure, but it's not always simple with Symphony.)

I don't think that all of us are on the same track, although we have put some work into this discussion (and the analysis of the existing extension's ideas). In addition, our current needs regarding the Symphony version are different.

Since my time is very limited at the moment, I propose the following: Let's create "private" versions for now (and actually try to implement them), then reanimate this discussion. It might be a good idea to have different names for these projects, like the Basket extension (@designermonkey) or the Bag extension (@michael-e). Just in case anything gets released later. :-) Since theses extensions won't get too complicated, they might be merged (manually) as well.

Sounds like a plan Michael, you know me, I'm not trying to be obstinate and no, I wouldn't like to upgrade one of your sites ;)

When I have some Internet at home ill do some work on this.

I really think that the output will be interesting, and we'll have something really cool!

I already worked on this a bit, and noticed the following:

• Things are much more difficult than they seem to be (as always, haha, nothing new here...).
• Without any bad intentions, I have actually moved away form the original concept more and more. I still think that there are very good ideas in this extension, but if you spend a bunch of time on it (even without installing anything, just coding), you feel that some questions have not been answered or could be answered in a more flexible and/or simple way.

BTW: The biggest shortcoming of the Shopping Cart — in my eyes — is the inability to deal with arrays (i.e. multiple items) — except when using the dropall method (which is kind of obvious).

BTW #2: I will be building something called "Item Storage", or even "Storage" (if I get it really flexible, yesss). Of course I don't know if there will ever be an official release of this, but at least I really learn a lot. :-)

Hi Michael, did you manage to begin any work on an 'item storage' field at all?

It's currently still in alpha-ish, and being tested by Nils H, Michael and myself.

It's up to Nils when it's released I think.

No worries, just curious :)

Okay, I have to say that we didn't plan to release this publicly (at least not now) but here we go. Michael and I have been working on this for our own projects so please don't expect any fancy additions in the near future. It does all we need. This release is stable and tested but we won't offer any support: https://github.com/hananils/storage

Use it with pleasure but at your own risk.

Oh, sorry, I thought the plan was to eventually release it.

No worries.

Guys, how do you deal with the clearing of the basket if the user doesn't action any purchase after a while?

Just concious that the cart data stays until it is cleared.. is there a timeout method so the cart gets cleared after a period of time that you guys use?