That's not what validations are for. You want custom setter methods.
> A good example would be for a
> world wide auction house type application and to to convert currency
> to one single format, when you validate you check to see if both the
> amount is alright along with the currency type. (This is assuming you
> can type in what type of currency it is, and for this example is
> possible.)
With real-world currencies, it is my understanding that this is a bad
idea.
>
> The application I am developing allows the user to type in multiple
> currencies at one (This is a D20 RPG, and people type in something
> along the line of 12 pp 145 gp 78 sp 21 cp) and so far the validation
> process involves converting it all to the lowest currency type.
Again, don't do this in the validator. What you want is something like
this:
CONVERSIONS = {:sp => 10, :gp => 100, :pp => 1000}
def balance=(string)
# parse the string somehow to get the various amounts, then:
bal = cp
bal += gp * CONVERSIONS[:gp]
# likewise for other currencies
self[:balance] = bal
end
There's room for refactoring here, but you get the idea.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
But
> for the sake of being DRY I would only need to add another line to set
> the variable, but instead it is looking like I would have to repeat
> the whole method and add in the single line and change it that way on
> creation and updates.
--
Posted via http://www.ruby-forum.com/.
That would work, but I think it's conceptually wrong for what the OP
wants.
> -eric
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
Fails in what way?
> Here is a link to show you what I did with the model...
>
> http://pastebin.com/me807521
I'll check it out in detail later on. On cursory inspection, however,
it looks like it has a lot of problems; I'll make some suggestions when
I'm not trying to type on my iPhone. :)
Perhaps Eric's before_save suggestion is the right idea after all.
I'll pay special attention to that, then. Are your tests passing?
>
> On Nov 7, 3:30�pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
Best,
Not an excuse. You should write tests before writing any application
code at all. That way you know your code does what you meant it to.
Read up on test-first development and apply the practice religiously.
> All of my
> methods work however whenever I do an update it doesn't touch the set
> method to change the variable. (Tested with simple outputing text to
> say that it was being used)
Right. I don't think update_attribute would.
>
> On Nov 7, 8:59�pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
Best,
("Method", not "section".)
> I fixed it and it all works
> out, when you use update_attributes it does use the override of the
> set method.
OK. I couldn't remember for sure offhand.
>
> Now then my only question now is where can I put the universal methods
> that are going to be used by Models and Views, and Controllers /
> Helpers if they need to be used by them. I read somewhere where you
> would put it but since then I have forgotten and can't find it again.
What universal methods? You don't need any for the case at hand.
As promised, I've refactored and improved (I hope!) your code. The new
version is at http://pastebin.com/f4b92e46d .
One suggestion I didn't get to make in the source (because the method no
longer exists with that name): convertDNDtoInt is not a Ruby-style name.
The more Rubyish name would be convert_dnd_to_int.
The easiest way to do this, I think, would be to define class Currency,
with subclasses (or perhaps instances) SilverPiece, GoldPiece, and so
on. There's lots of info floating around on handling multiple
real-world currencies; you should be able to do D&D money the same way.
>
> I was going to add some options to where if it was set to something
> below 0 that it would automatically subtract 1 from the one above it,
> add 10 to itself, and continue doing the math while repeating if
> necessary with recursion. However that would be in issue if the one
> above it was 0 since if it was subtracted by 1 it would set the one
> below it to -1 causing it to repeat indefinitely.
>
> I hope this kind of makes since, and I am kind of stumped on doing
> this without an insane amount of repeated coding.
Use the power of a decent object model. I'll try to post a quick
example if I have time.
>
> FYI: I will probably add another class the is an extension called
> BankMoney, since the Bank has no issue converting automatically
> upwards or downwards and they also allow for negative ammounts.
>
>
> On Nov 8, 11:00�pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
Best,
So is what you've just posted -- it's repetitive and unreadable.
There's no point in keeping it all in one class if the code quality
suffers.
>
> Hopefully if I keep it to this one class then I could finally take a
> step forward and continue adding more and more to the database.
The two have nothing to do with each other. Don't be afraid to
introduce classes if it makes life simpler.