> Just wondering if anyone has given any thought to a way to disable all
> auto_validations for a model? It might be handy in alot of
> circumstances rather than putting :auto_validation = false on every
> property.
Do you have ideas for syntax? Will simple disable_auto_validations!
class method be good enough if added?
MK
> I guess a better idea might be to use it as a block
>
> class Model
> include DataMapper::Resource
>
> property :id, Serial
>
> without_auto_validations do
> property :x, String
> property :y, String
> end
>
> property :name, String
> end
>
> Any thoughts?
What if we just add something like default_property_options? It can be
used just like
default_repository class method. This would be much simpler to
implement and to follow
(since scope does not change).
Then each property call will simply merge given values with a hash of
defaults you defined on your class.
It won't affect performance either, because it is a boot time code, so
we can extend it to idea of contexts used
by other parts of DM.
What do you think?
MK
> Yeah, I see what you're saying. default_property_options should
> probably be a block though rather than a method to allow different
> sets of defaults
block will sure give you more flexibility, but how often would you
need it?
I personally have an app with 50+ models and I never used many sets of
default values,
usually just one, that I already implemented as
default_property_options in a plugin not yet open sourced.
MK
> i've already got a project where I could use atleast two blocks of
> default options in more than one model. it would certainly make them
> arrid extra-DRY!
Alright I am convinced about block form. Next question is, I am going
to add it
to dkubb/dm-core, is it fine with you, or you want a backport to sam/
dm-core?
Dan's tree may or may not have a work-in-progress refactorings and
maybe it'd be
better to go with a stable/old tree if you don't want to be an "Early
Adopter" movie start ;)
MK
> Thing is though, either default_property_options or a
> with_property_options {:x => :y, :a => :b} do block is a dm-core
> change though right?
Yes, it belongs to dm-core since it is no longer limited to
validations (and that is my whole idea).
MK
> On another note. Have you any concept objections to dynamic eval
> messages?
>
"Dynamic eval" gave me some creeps initially (I appreciate having
as little magic as possible in the code), but if what you mean is
> I was going to have a look and see at valid? time if the :message is a
> Proc and just execute it within the models scope?
just a way to do
class SubversionOperation < ScmOperation
#
# Validations
#
validates_present :network_connection, :when
=> :committing, :message => proc { |record| "what you think I am, a
Git?!" }
end
then keep in mind message already handles this case:
validates_present :prop, :when => [:update, :create], :message => {
:create => "message for create context",
:update => "message for update context"
}
That is, you need to keep multiple contexts in mind, and thus think
about keeping code simple. I call this feature
"callables expansion" usually. But I am all for it.
I am in the process of rewriting dm-validations spec suite from
scratch, so I'd take on it as soon as I finish with most of it. I am
done with 3 validators
already, and have pretty good set of fixtures to get up to speed with
those left.
MK
> I'd imagine (though Michael can verify this) that the block should
> look something like this
>
> with_default_options {:precision => 8, :scale => 2, :nullable =>
> false} do
> property :minimum, BigDecimal
> property :maximum, BigDecimal
> end
>
> with_default_options {:size => (10..100), :nullable => false} do
> property :firstname, String
> property :lastname, String
> end
Correct
MK
This particular feature can be a plugin. It would require some simple
refactoring in -core,
but this is what -core is all about: being open for extension.
What we end up with for now:
http://datamapper.lighthouseapp.com/projects/20609-datamapper/tickets/771
On 14.01.2009, at 18:18, heda wrote:
> too messy when you have sets of options
>
> opts = {:auto_validation => false}
> opts_string = opts.merge({:size => 50})
> opts_decimal = opts.merge({:precision => 10, :scale => 4})
>
> property :firstname, String, opts_string
> property :lastname, String, opts_string
>
> property :minimum, BigDecimal, opts_decimal.merge({:nullable =>
> false})
> property :maximum, BigDecimal, opts_decimal
>
> =====
>
> much cleaner and easier to read with something like
>
> with_default_options {:auto_validation => false} do
>
> with_default_options {:size => 50} do
> property :firstname, String
> property :lastname, String
> end
>
> with_default_options {:precision => 10, :scale => 4} do
> property :minimum, BigDecimal, :nullable => false
> property :lastname, BigDecimal
> end
>
> end
MK