I’m a bit confused as to how I came to this solution but thought it
might
need some review.
I have a number of fields that can be edited by the user. As an
example,
let’s say I have 5 text fields where
a user can list up to 5 of their favorite Rails books, in order of
favorite.
Tomorrow they edit the form, move 4 and 5 off, so they are down to three
books
A few weeks later, The put Ruby and Rails Up and Running as number 1 and
Agile Web D. as number 3
So you get the point. Well, while I sort of know I can do some
comparing ,
size, value checking and so forth, it seems easier
to just delete the current entries on update and treat the changed
selections as new.
I wanted to get some opinions and see if this is an okay thing to do ?
I’m a bit confused as to how I came to this solution but thought it
might
need some review.
I have a number of fields that can be edited by the user. As an
example,
let’s say I have 5 text fields where
a user can list up to 5 of their favorite Rails books, in order of
favorite.
Tomorrow they edit the form, move 4 and 5 off, so they are down to three
books
A few weeks later, The put Ruby and Rails Up and Running as number 1 and
Agile Web D. as number 3
So you get the point. Well, while I sort of know I can do some
comparing ,
size, value checking and so forth, it seems easier
to just delete the current entries on update and treat the changed
selections as new.
I wanted to get some opinions and see if this is an okay thing to do ?
TIA
Stuart
–
Stuart,
I think your current method is just fine. It is simple and inherently
“error resistant”. That’s a good thing.
I think for you to question it at this point is an example of something
referred to as “premature optimization”. That’s considered a bad thing.
In general, one should do something in a simple and intuitive way, and
then at some point in the future if there are performance problems, the
right thing to do is to profile the code and see what is causing the
performance problems and go after that specifically. Trying to imagine
it ahead of time and design the code accordingly is the “old way”, and
has been replaced by rapid application development and later profiling
and dealing with any performance issues. This way is usually a more
efficient use of programmers time.
That said, experience enters in at some point. If you were doing this
for a form with thousands of line items and only one is expected to
change each time, then you might want to go ahead and do some obvious
optimization during the design.
jp
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.