[Nitro] Validations, was re: 0.26.0 preview
George Moschovitis
george.moschovitis at gmail.com
Mon Dec 19 04:25:55 EST 2005
Bryan,
seems you have attached the wrong patch (validation_key). Can you please resend?
-g.
On 12/18/05, Bryan Soto <bryan.a.soto at gmail.com> wrote:
> Hi,
>
> I had some time last night, so I came up with two options for pending
> release.
>
> Option 1, add_unique_error_msgs adds only unique error messages to the
> errors list for the field. Validations size still increases (in debug mode
> only due to auto-reload), but error messages list doesn't contain multiple
> copies of the same message.
>
> Option 2, validation_key converts validations list to a hash and creates a
> key object. Validations size doesn't increase but is a bit of a bigger
> change.
>
> Both pass unit tests (at least the ones that run. I'm not able to complete
> the one's for og).
>
> Anyone want to give them a try for testing purposes?
>
> bryan
>
>
> On 12/16/05, Bryan Soto < bryan.a.soto at gmail.com > wrote:
> > <code>
> >
> > require 'nitro'
> > require 'og'
> > require 'user'
> >
> > require 'dev-utils/debug'
> >
> > Og.setup
> >
> > class ValidationTest
> > def index
> > out = "The number of validations for User is
> #{User.validations.length}.<br />"
> > u = User.new
> > u.username = 'bryan'
> > u.password = 'bryan'
> > if u.valid?
> > u.save
> > else
> > out << "<br />#{u.errors.errors.inspect}<br />"
> > end
> > out
> > end
> > end
> >
> > Nitro.run ValidationTest
> >
> > </code>
> >
> > Run against gems and dev version.
> >
> > Touch user.rb. Await reload message on console, then refresh browser.
> >
> > Notice how in gem version, the number of validations increases, but the
> number of errors remains unchanged.
> >
> > Repeat using dev version. Notice that the number of validations increases
> as well as the number of error message entries.
> >
> > Basically, the gem version evals the code _once_ in eval_validate
> (glue/lib/validations.rb) the first time #valid? is called, so it ignores
> the repeated validations.
> >
> > Hope this clears things up as too what I'm talking about. I need to brush
> up on my communication skills. It all made sense to me every single time I
> wrote 8^).
> >
> > --
> >
> > As too future design, I was thinking something more like:
> >
> > <code>
> >
> > class ValidationKey
> > attr_reader :validation
> > attr_reader :field_name
> >
> > def initialize(val, field)
> > @validation, @field_name = val.to_s, field.to_s
> > end
> >
> > def hash
> > "#{@validation}-#{@field_name}".hash
> > end
> >
> > def ==(other)
> > self.validation == other.validation and self.field_name ==
> other.field_name
> > end
> > end
> >
> > vk = ValidationKey.new(:validate_unique, :username)
> >
> > validations[vk] = validate_unique_proc_goes_here
> >
> > </code>
> >
> > as the key and the proc as the value in the hash. Then the new key would
> just overwrite the old. No more duplicate entries.
> >
> > And as for application level validations, I was thinking someone with a
> shopping cart might have written their own validate_credit_card_number. Or
> validate_password, where password requires at least one number. Basically,
> some sort of validation that only makes sense in their particular
> application. Though I suppose most people just use aspects for that.
> >
> > bryan
> >
> >
> >
> > On 12/16/05, Brian Bugh <brian at xsi-design.com > wrote:
> > > I'm not sure I understand what you mean. The new code is functionally
> > > identical to the old way, only it's using blocks and Proc objects
> > > instead of using eval. Try this simple Nitro app with both the old and
> > > new code:
> > >
> > > require 'nitro'
> > > require 'og'
> > > require 'user'
> > >
> > > Og.setup
> > >
> > > class ValidationTest
> > > def index
> > > "The number of validations for User is
> > > #{User.validations.length}."
> > > end
> > > end
> > >
> > > Nitro.run ValidationTest
> > >
> > > Check it in the browser, and it will say 2, then touch user.rb and it
> > > will say 4. The old way basically copy and pasted code into a function,
> > > whereas now that code is a list of anonymous methods in an array that is
> > > iterated. That array is only iterated when validate or valid? is called
> > > - the same times as the long function was called before. Hopefully that
> > > helps clarify the issue for you.
> > >
> > > --
> > >
> > > I have thought about your suggestion, and I think it is a possibility.
> > > Do you mean only store the validation list and each field like this:
> > >
> > > {:validate_unique => [:username], :validate_value => [:password]}
> > >
> > > If so, how would we determine what a validation code block was? One
> > > option is to have a list of private instance methods (like
> > > validate_values) that check the fields in question, but I am not sure if
> > > having one function to declare it and one function to check it is ideal.
> > > The names could be confusing because of their similarity. Using a
> > > hashed set like that could possibly move the validation logic solely to
> > > when valid? is called, rather than when the validation is first
> > > declared. I like the idea and will try to think of some solutions.
> > >
> > > By the way, what are application level validations? Nitro application
> > > or Og/Glue? I am not familiar at all with Nitro, because the project
> > > I'm doing that got me interested in Og in the first place doesn't use
> > > anything else.
> > >
> > > Brian B.
> > >
> > >
> > > On Thu, 2005-12-15 at 23:20 -0800, Bryan Soto wrote:
> > > > Interesting... I guess noone ever noticed since the code was eval'd on
> > > > the first call made to #valid? in the previous implementation. The
> > > > array was only iterated through when defining validate(). Now it's
> > > > being iterated through on every call.
> > > >
> > > > Perhaps if, instead of an array, validations were stored in a hash
> > > > with the key consisting of the validation type and field name, it
> > > > would avoid the duplication and performance hit? It might make
> > > > application level validations a bit more complicated, though I'm not
> > > > sure if anyone actually uses them. Does anyone?
> > > >
> > > > On 12/15/05, Brian Bugh < brian at xsi-design.com> wrote:
> > > > Ah, I see. The current release gem package does this as well,
> > > > so it's a
> > > > general issue with the way validations are handled. I'm
> > > > innocent! ;)
> > > >
> > > > I've tested with extend_object and append_features methods and
> > > > the
> > > > on_included block, and I can't seem to find a reliable way to
> > > > check if
> > > > the file is being loaded/extended again. The problem is that
> > > > when it is
> > > > reloaded, the class is just reopened and declared the same way
> > > > it was
> > > > before.
> > > >
> > > > Any logic I can think of to add to validations for uniqueness
> > > > checking
> > > > will have a performance penalty in production, even though
> > > > production
> > > > doesn't have the reload issue.
> > > >
> > > > I will spend more time on this tomorrow to see if I can find
> > > > a
> > > > easy/quick solution for your upcoming release.
> > > >
> > > > Brian B.
> > > >
> > > >
> > > > On Thu, 2005-12-15 at 13:24 -0800, Bryan Soto wrote:
> > > > > Sorry if I wasn't clear. In debug mode, i.e. webrick, files
> > > > are
> > > > > automatically reloaded on change. I noticed after adding and
> > > > removing a
> > > > > field to test Mysql evolution that my validations had
> > > > increased. Something
> > > > > along the lines of:
> > > > >
> > > > > # user.rb
> > > > > class User
> > > > > property :username
> > > > > property :password
> > > > >
> > > > > validate_unique :username
> > > > > validate_value :password
> > > > > end
> > > > >
> > > > > User.validations.size # => 2
> > > > >
> > > > > # touch user.rb
> > > > >
> > > > > User.validations.size # => 4
> > > > >
> > > > > assuming user.rb is a model class in a Nitro application.
> > > > Basically, after
> > > > > the touch is performed, the file is reloaded and the
> > > > validations are added
> > > > > anew to the already existing validations array (speculation
> > > > on my part as to
> > > > > your implementation) in the already existing User class.
> > > > >
> > > > > As I said, it's not that a big a deal. A stop and restart of
> > > > the webrick
> > > > > server clears it up. I just happended to notice twice as
> > > > many error messages
> > > > > as I expected from a form. Just make sure your production
> > > > apps aren't in
> > > > > debug mode.
> > > > >
> > > > > bryan
> > > > >
> > >
> > >
> > > _______________________________________________
> > > Nitro-general mailing list
> > > Nitro-general at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/nitro-general
> > >
> >
> >
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>
>
--
http://www.gmosx.com
http://www.navel.gr
http://www.nitrohq.com
More information about the Nitro-general
mailing list