Restriction to whole numbers

[designermonkey]

With all the silly little issues I've raised recently, I think that the only genuine one I have is that the limitation of only allowing whole numbers is a wrong decision from a flexibility perspective.

I would like to be able to calculate prices too, not just quantities.

[michael-e]

So you will also need multiplication and compounded interest calculations. :-)

[designermonkey]

Maybe ;o)

Just for now, calculating money to two decimal places would be great. I can do all the maths in xsl, but the storage won't allow me to save the number. I can hack it for this project, but logging it as I think it could be very useful.

Looking through the code, the only limitations are to the count and count-positive keys.

[michael-e]

Give me some hours to wrap my mind around all those additions and changes which have been implemented since I developed the basic idea. I can't say anything of interest right now.

[michael-e]

@designermonkey, @nilshoerrmann: Maybe somebody has a Rested.app test file for me?

[michael-e]

I broke it. This may take a while.

[nilshoerrmann]

What did you break?
And, sorry, I don't have a test file (have been working in Symphony directly).

[michael-e]

First I have to say that it took me less than 2 minutes to find this first bug. :-))

Using a count-positive param and the set-count action, you can set a negative value. While the event's result will be error, the value will still be set.

Still I suggest to wait with fixing things until I have an overview.

[designermonkey]

I thought about this one too, and I think I know where it is happening, so should be able to fix it easily.

[michael-e]

OT: There are two things I really (!) like:

• The XML output is great — the additions and changes introduced by Nils are cool; especially adding the count as an attribute now seems very logical to me.
• The DS editor is cool as well — and I am already sad that it won't work like that for me, in my 2.2.x production system :-(

[nilshoerrmann]

An acclamation with exclamation:
I quit. Good day.

[nilshoerrmann]

So, how do we deal with this request.
I think that using the count for prices is not the right place (that's why the key is called count and not calculate or price).

[michael-e]

We might introduce a delegate (later) which allows to manipulate the items' preprocessing. So you could introduce your own "special keys" using an extension.

I suggest to keep this issue open and come back when all the known bugs have been fixed.

[michael-e]

(I forgot: Passing the items array to another extension using a delegate would also mean that you could introduce your own mathematical rules for "your" keys.)

[nilshoerrmann]

That's a really good idea.

[nilshoerrmann]

To prepare this we should make the check if the given values are integers optional in the code (using some kind of flag in the function call, that can be passed to the delegate and potentially be overwritten by another extension).

[michael-e]

This does make sense if we decide to go for a single count keys and use modes (like you proposed). If we go for separate count-type keys, I'd rather say "use your own custom key, but don't try and manipulate existing ones".

[nilshoerrmann]

But in this case, the restriction to integers shouldn't be part of the main extension and should instead be provided separately. :)

[michael-e]

Unless we say it's a "core feature" (of the Storage). :-))

See you later!

[nilshoerrmann]

The problem is that if it is a core feature that cannot switched off, you'd have to rewrite most of the storage class to be able to add floating-point numbers. Not a good thing.

Have a nice day.

[michael-e]

you'd have to rewrite most of the storage class to be able to add floating-point numbers

No, no. You would use your own key, e.g. "price". Then you could add special pre-processing for this key. You couldn't make it an XML attribute (so it would be a node), but this is not a big problem, is it?

[nilshoerrmann]

I think you are missing my point here:

If we are considering storage add-ons, why should the storage contain any restrictions at all (positives, integers)? Opening the extensions functionality via delegates sounds like a recipe concept to me. In this case, the storage class should not bundle a single recipe by itself – it should just make them possible.

This, of course, doesn't mean that we cannot bundle recipes with the extension. I'm just saying that they should be added the way extension would have to do it (thinking of our main features count, count-positive, integers).

[michael-e]

So we would have auto-detection, just like the Symphony core detects email gateways provided by extensions?

Well, yes, that sounds interesting indeed. Would you like to give this a go?

All I say is: I'd love to have a stable initial version, so let's try and close all other issues first and tag it 1.0.

[nilshoerrmann]

Would you like to give this a go?

I have no idea how to implement that actually – that's beyond my PHP knowledge.
But maybe it could be copied from the email gateways? Or the JIT recipes?

All I say is: I'd love to have a stable initial version, so let's try and close all other issues first and tag it 1.0.

Yes, of course. I thought of this more like a roadmap: If we'd like to make the storage extensible, it just sounds logical to understand the storage class as a simple API that is used by the main extension itself. This will also ensure that the API really works and doesn't just pretend to.

Introducing flexible validation and storage recipes shouldn't be part of the first release.

[michael-e]

I have no idea how to implement that actually

Nor do I. I am better in breaking things. :-)

Agreed on the roadmap (a.k.a. wishlist, for now). Let's keep this thread open.

[designermonkey]

Oh, go on then... When I get some time ;o)

Lets get a stable release out first though

[nilshoerrmann]

When I get some time

You will have plenty of sleepless nights soon, John – the ideal time for programming work.
We pin our hopes on you :)

[patrickyan]

It would be nice to be able to store anything, not just integers.

Some useful applications would be:

• Reservation/travel dates so user doesn't have to re-enter dates
• Basic voting/liking duplication-prevention
• Save visitor preferences like location, currency, opt-out for stuff like ads

[nilshoerrmann]

You can do all this. We are just restricting counts to integers.

[patrickyan]

I just noticed that. The whole read me only talked about count, so I thought the extension only supported counting.

[nilshoerrmann]

Storage allows the creation of nested data arrays of any kind with three restrictions ...