Discussion:
Form validation discussion
(too old to reply)
Sebastian Riedel
2013-09-30 08:07:08 UTC
Permalink
We've just released Mojolicious 4.42, which includes form validation support, our first experimental feature in 18 months. There's still quite a bit of polishing work to do and much of it depends on user feedback. So if there's anything you like about it, don't like, or think needs to be added, please post it in this thread.

Some points i care most about at the moment:
* Are parameters with multiple values handled correctly.
* If and how file uploads should be handled.
* Which checks should be included by default.

And just in case you have no idea what i'm talking about. :)

http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Form_validation
http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Adding_form_validation_checks

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Charlie Brady
2013-09-30 14:35:55 UTC
Permalink
Post by Sebastian Riedel
We've just released Mojolicious 4.42, which includes form validation support, our first experimental feature in 18 months. There's still quite a bit of polishing work to do and much of it depends on user feedback. So if there's anything you like about it, don't like, or think needs to be added, please post it in this thread.
* Are parameters with multiple values handled correctly.
* If and how file uploads should be handled.
* Which checks should be included by default.
And just in case you have no idea what i'm talking about. :)
http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Form_validation
http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Adding_form_validation_checks
This looks really interesting. Thanks.

I have a couple of questions after reading the
'Adding_form_validation_checks' pod.

1. I would expect to see the form validation in 'post '/' => ...' rather
than the get handler. Isn't Post/Redirect/Get best practice here?

2. A Mojolicious::Lite application could be expected to have multiple
forms. Would it be better to have a validator namespace per form rather
than per app?
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Sebastian Riedel
2013-09-30 14:41:22 UTC
Permalink
Post by Charlie Brady
1. I would expect to see the form validation in 'post '/' => ...' rather
than the get handler. Isn't Post/Redirect/Get best practice here?
It's just an example to get the point across with as little code as possible, not a best practice.
Post by Charlie Brady
2. A Mojolicious::Lite application could be expected to have multiple
forms. Would it be better to have a validator namespace per form rather
than per app?
I don't understand this point, of course multiple actions can have different forms.

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
Charlie Brady
2013-09-30 15:04:11 UTC
Permalink
Post by Sebastian Riedel
Post by Charlie Brady
1. I would expect to see the form validation in 'post '/' => ...' rather
than the get handler. Isn't Post/Redirect/Get best practice here?
It's just an example to get the point across with as little code as possible, not a best practice.
Sure, but I think the example is an excellent opportunity to show best
practice.

I can reframe my question - will the validation errors be displayed
correctly in the get handler, if I validate in a post handler, and
redirect on validation failure?
Post by Sebastian Riedel
Post by Charlie Brady
2. A Mojolicious::Lite application could be expected to have multiple
forms. Would it be better to have a validator namespace per form rather
than per app?
I don't understand this point, of course multiple actions can have different forms.
Yes, but if I understand correctly the validator namespace will be global
across all the forms within a M::L application. I guess that isn't a
problem.
Sebastian Riedel
2013-09-30 15:10:44 UTC
Permalink
Post by Charlie Brady
Sure, but I think the example is an excellent opportunity to show best
practice.
You're welcome to make a proposal, if others think it's a better example for the documentation we can change it.

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
sri
2013-09-30 15:56:24 UTC
Permalink
Post by Charlie Brady
I can reframe my question - will the validation errors be displayed
correctly in the get handler, if I validate in a post handler, and
redirect on validation failure?
I have never heard of this pattern, and there is no magical global state to
make it possible.

--
Charlie Brady
2013-09-30 18:30:48 UTC
Permalink
Post by sri
Post by Charlie Brady
I can reframe my question - will the validation errors be displayed
correctly in the get handler, if I validate in a post handler, and
redirect on validation failure?
I have never heard of this pattern,
Is it not post/redirect/get:

http://en.wikipedia.org/wiki/Post/Redirect/Get

?
Post by sri
and there is no magical global state to make it possible.
I think that flash is sufficient to store validation failures for
redisplay in a get of the form after redirect from a post handler. In
fact, I know it is, because that's what I'm doing in some M::L
applications.
Michael P. Soulier
2013-09-30 18:42:07 UTC
Permalink
Post by Charlie Brady
I think that flash is sufficient to store validation failures for
redisplay in a get of the form after redirect from a post handler. In
fact, I know it is, because that's what I'm doing in some M::L
applications.
And it is exactly what Ruby on Rails does.

Mike
David Stevenson
2013-09-30 18:43:21 UTC
Permalink
Does it redirect after a validation fail?
Post by Michael P. Soulier
snip
And it is exactly what Ruby on Rails does.
Mike
sri
2013-09-30 18:56:15 UTC
Permalink
Post by David Stevenson
Does it redirect after a validation fail?
No, it doesn't, redirect after failed validation makes absolutely no sense.

--
David Stevenson
2013-09-30 18:58:32 UTC
Permalink
Post by sri
No, it doesn't, redirect after failed validation makes absolutely no sense.
Quite! As the referenced Wiki article said, it's about protecting against double form submissions, so not needed on validation fail
Charlie Brady
2013-09-30 19:01:37 UTC
Permalink
Post by sri
Post by David Stevenson
Does it redirect after a validation fail?
No, it doesn't, redirect after failed validation makes absolutely no sense.
You're probably right. Doing the validation in a get handler also makes no
sense. Form handling should be done in a post handler. You're right
though - the form can be re-presented by the post handler in the case of
validation failure.

If there are no failed validations, the post handler can then change the
system state, then re-direct back to a get URL.
Michael P. Soulier
2013-09-30 19:25:30 UTC
Permalink
Post by David Stevenson
Does it redirect after a validation fail?
No, it doesn't, redirect after failed validation makes absolutely no sense.
Seems to depend on the implementation. In Rails, yes. In Django, no.

Rails does so for consistency, the point being to always redirect after a POST operation. It's a more purist approach, but really not necessary, since there's no danger of double submission.

Mike
Charlie Brady
2013-09-30 14:37:24 UTC
Permalink
Post by Sebastian Riedel
* Which checks should be included by default.
CSRF checks.
Sebastian Riedel
2013-09-30 14:42:29 UTC
Permalink
Post by Charlie Brady
Post by Sebastian Riedel
* Which checks should be included by default.
CSRF checks.
That's completely unrelated to form validation and i doubt we will see CSRF support in core anytime soon, but of course i'm open for sensible proposals.

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
AVM
2013-09-30 16:36:56 UTC
Permalink
Not all check can be foresee.

How to send a check of multiple rules?

my $rule = [
age => [ # paramter name1
'not_blank', # constraint function1
'int' # constraint function2
],

name => [ # parameter name2
'not_blank', # constraint function1
{'length' => [1, 5]} # constraint function2
]
];
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-09-30 16:56:25 UTC
Permalink
Post by AVM
How to send a check of multiple rules?
This might address what you meant, i'm having a hard time understanding
though.


https://github.com/kraih/mojo/commit/ef1528d8c9444a1f60b470bbe5b6c68f91193019

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
AVM
2013-09-30 17:44:42 UTC
Permalink
# Validate parameters ("pass_again" depends on "pass")

$validation->required('user')->regex(qr/^[e-t]+$/);
$validation->required('user')->size(1, 20)->regex(qr/^[e-t]+$/);
$validation->required('pass_again')->equal_to('pass')
if $validation->optional('pass')->size(7, 500)->is_valid;

It is a single check


As put them in the rule?


# Parameter
my $param = $self->req->params->to_hash;

# Validation Rule
my $rule = [
age => [ 'not_blank', 'int' ],
name => [ 'not_blank', {'length' => [1, 5]} ]
];

# Validate
my $vresult = $vc->validate($param, $rule); # I want to make
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-09-30 19:07:46 UTC
Permalink
This is not turning out to be the kind of discussion i had in mind, perhaps
it is best to keep design topics on IRC, lets end this here.

--
Charlie Brady
2013-09-30 21:04:32 UTC
Permalink
Post by sri
This is not turning out to be the kind of discussion i had in mind, perhaps
it is best to keep design topics on IRC, lets end this here.
I would think this was more of a specification and documentation
discussion than design discussion. But you don't seem all that interested
in what I have to say, and I don't do IRC, so we'll have to end this here.

Best wishes

---
Charlie
Łukasz Lewandowski
2013-10-02 15:35:32 UTC
Permalink
@Sebastian,

Is there any way to combine Form::Validator with I18N?

I create a plugin "CustomValidatorChecks", where I register some additional
checks (for exampe: "email"),
but I have no idea, how to combine custom error messages with
internationalization plugin?

This is easy when I register errors in controller, but I wan't to register
my checks once...
Post by sri
Post by sri
This is not turning out to be the kind of discussion i had in mind,
perhaps
Post by sri
it is best to keep design topics on IRC, lets end this here.
I would think this was more of a specification and documentation
discussion than design discussion. But you don't seem all that interested
in what I have to say, and I don't do IRC, so we'll have to end this here.
Best wishes
---
Charlie
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
--
Łukasz Lewandowski

-- mts
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Sebastian Riedel
2013-10-02 15:57:00 UTC
Permalink
This is easy when I register errors in controller, but I wan't to register my checks once…
I have no solution for this at the moment, proposals would be very welcome.

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-02 16:01:51 UTC
Permalink
Post by Sebastian Riedel
I have no solution for this at the moment, proposals would be very welcome.
I wanted to avoid passing the controller instance as an argument to checks
and error generators, but that might be the only option.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-02 16:47:56 UTC
Permalink
Post by sri
I wanted to avoid passing the controller instance as an argument to checks
and error generators, but that might be the only option.
This is actually such a big problem that it might result in the removal of
form validation from Mojolicious for now. The validation instance persists
for the whole request, while the controller instance does not.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Łukasz Lewandowski
2013-10-02 16:46:30 UTC
Permalink
Solution?

1. You could change errors in Mojolicious::Validator:
from: sub { q/Lorem $_[1] ipsum/ }
to: sub { [ q/Lorem %s ipsum/, $_[1] ] }

2. Add message translator (callback) to Mojolicious::Validator::Validation,
by default:
sub { return sprintf @_ }

In this way, it would be possible to replace error messages with gettext
msgs & message translatow with something like this: sub { $c->l( @_ ) }.

Sorry for shortcuts, but it's horrible to write code on mobile phone! :-P
Post by Łukasz Lewandowski
This is easy when I register errors in controller, but I wan't to
register my checks once

I have no solution for this at the moment, proposals would be very welcome.
--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Sebastian Riedel
2013-10-02 16:49:27 UTC
Permalink
Post by Łukasz Lewandowski
Solution?
from: sub { q/Lorem $_[1] ipsum/ }
to: sub { [ q/Lorem %s ipsum/, $_[1] ] }
Multiple layers of message generation callbacks is a pretty horrible solution.

--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
sri
2013-10-02 16:58:55 UTC
Permalink
Post by Sebastian Riedel
Multiple layers of message generation callbacks is a pretty horrible solution.
Another possibility would be to get rid of message generation in core and
just return the name of the failed check with arguments.

$validation->errors('foo') => [['size', 'name', 'value', 2, 10], ...]

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-02 17:54:57 UTC
Permalink
Post by sri
Another possibility would be to get rid of message generation in core and
just return the name of the failed check with arguments.
This is what i went with for now.


https://github.com/kraih/mojo/commit/f84d17ff0fce12fb56cf5132e443bbab1f62b4aa

Personally i won't miss dynamic message generators, since i've only used
field-with-error based styling with descriptive labels, but i'm open for
well thought out proposals to bring them back.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-02 19:17:42 UTC
Permalink
Post by sri
This is what i went with for now.
And released to CPAN with Mojolicious 4.43, lets see how it goes.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-08 13:24:20 UTC
Permalink
Post by sri
And released to CPAN with Mojolicious 4.43, lets see how it goes.
Mojolicious 4.45 is now out, changing the return value of validation checks.


http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Adding_form_validation_checks

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-13 11:35:31 UTC
Permalink
There have been no more changes to validation recently and i think we might
be pretty close to removing its experimental status. So i'm really
interested in feedback from those already using it, even if it's just a
quick "I'm using it and i like it".

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Łukasz Lewandowski
2013-10-14 10:13:10 UTC
Permalink
Is there any way to add "custom" error after validation?
It would be very usefull...
For example, I try to insert user into users db table. Insert fails with
error message - "unique index violation on...", so I know, that user email
already exists in db. I would like to add message about email duplication
to "email" validation errors...
Post by sri
There have been no more changes to validation recently and i think we
might be pretty close to removing its experimental status. So i'm really
interested in feedback from those already using it, even if it's just a
quick "I'm using it and i like it".
--
sebastian
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
--
Łukasz Lewandowski

-- mts
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Sebastian Riedel
2013-10-14 10:22:30 UTC
Permalink
Post by Łukasz Lewandowski
Is there any way to add "custom" error after validation?
Error messages have been completely removed, you are responsible for
generating them yourself.

http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Adding_form_validation_checks
--
Sebastian Riedel
http://mojolicio.us
http://github.com/kraih
http://twitter.com/kraih
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-16 20:30:34 UTC
Permalink
Post by sri
There have been no more changes to validation recently and i think we
might be pretty close to removing its experimental status. So i'm really
interested in feedback from those already using it, even if it's just a
quick "I'm using it and i like it".
We are planning to remove the experimental status from form validation
support with the 4.49 release. So if you believe there is anything wrong
with the implementation, now is the time to speak up!


https://github.com/kraih/mojo/commit/1f4773ef320490970c3dda72e32007bafce5d89f

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-17 16:57:59 UTC
Permalink
Post by sri
We are planning to remove the experimental status from form validation
support with the 4.49 release.
And released, form validation is now stable. \o/

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Łukasz Lewandowski
2013-10-02 17:04:05 UTC
Permalink
Ok, another solution, much simplier...
Move default error message "Value is invalid" from
Mojolicious:Validator::Validation::_error to Mojolicious::Validator::errors.
This allow to change ALL messages for example on "before_routes" hook.
At the moment, this one can not be "translated" before validation!
Post by Sebastian Riedel
Post by Łukasz Lewandowski
Solution?
from: sub { q/Lorem $_[1] ipsum/ }
to: sub { [ q/Lorem %s ipsum/, $_[1] ] }
2. Add message translator (callback) to
Multiple layers of message generation callbacks is a pretty horrible solution.
--
Sebastian Riedel
http://github.com/kraih
http://twitter.com/kraih
http://mojolicio.us
--
You received this message because you are subscribed to the Google Groups
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
AVM
2013-10-02 20:05:32 UTC
Permalink
the validation must be such

https://github.com/koorchik/LIVR
apl
2013-10-23 13:46:00 UTC
Permalink
Is there any chance of some kind of error-class-setter being implemented?
sri
2013-10-23 14:30:14 UTC
Permalink
Post by apl
Is there any chance of some kind of error-class-setter being implemented?
What's are the use cases and is there an elegant way to implement it?

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
apl
2013-10-24 07:51:31 UTC
Permalink
When using frontend frameworks like Twitter Bootstrap it is much easier to
use the given CSS-classes than to redefine/rename them (I think that would
need a compilation of Bootstrap's LESS-code.).
Post by apl
Is there any chance of some kind of error-class-setter being implemented?
What's are the use cases and is there an elegant way to implement it?
--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-24 15:46:48 UTC
Permalink
Post by apl
When using frontend frameworks like Twitter Bootstrap it is much easier to
use the given CSS-classes than to redefine/rename them (I think that would
need a compilation of Bootstrap's LESS-code.).
Can't say this argument convinces me, but lets see if there's more interest
first. There are also no proposals for an actual implementation yet.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Luc Didry
2013-10-24 16:01:37 UTC
Permalink
Post by sri
Post by apl
When using frontend frameworks like Twitter Bootstrap it is much easier to
use the given CSS-classes than to redefine/rename them (I think that would
need a compilation of Bootstrap's LESS-code.).
Can't say this argument convinces me, but lets see if there's more interest
first. There are also no proposals for an actual implementation yet.
--
sebastian
This would be a great feature. I can't propose any implementation, but I
wanted to show that Alexander is not the only Mojolicious user that
wants it.
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
apl
2013-10-25 09:24:45 UTC
Permalink
How about making "_validation"
(https://metacpan.org/source/SRI/Mojolicious-4.50/lib/Mojolicious/Plugin/TagHelpers.pm#L225)
look for a configuration variable before falling back to "field-with-error"?

Recompiling frontend frameworks can be a lot of work. If you update them
regularly dependency- and versionmanagement becomes a nightmare.
Post by apl
When using frontend frameworks like Twitter Bootstrap it is much easier to
Post by apl
use the given CSS-classes than to redefine/rename them (I think that would
need a compilation of Bootstrap's LESS-code.).
Can't say this argument convinces me, but lets see if there's more
interest first. There are also no proposals for an actual implementation
yet.
--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 12:30:11 UTC
Permalink
How about making "_validation" (
https://metacpan.org/source/SRI/Mojolicious-4.50/lib/Mojolicious/Plugin/TagHelpers.pm#L225)
look for a configuration variable before falling back to "field-with-error"?
You mean like this?

app->config(validation_error_class => 'my-field-with-error');

I suppose that would work, but it would also be our only built-in
configuration setting (aside from the hypnotoad key). Anyone else like this
idea?

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Luc Didry
2013-10-25 12:36:01 UTC
Permalink
Post by sri
How about making "_validation" (
https://metacpan.org/source/SRI/Mojolicious-4.50/lib/Mojolicious/Plugin/TagHelpers.pm#L225)
look for a configuration variable before falling back to "field-with-error"?
You mean like this?
app->config(validation_error_class => 'my-field-with-error');
I suppose that would work, but it would also be our only built-in
configuration setting (aside from the hypnotoad key). Anyone else like this
idea?
--
sebastian
Yes, me!
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
sri
2013-10-25 13:09:41 UTC
Permalink
Post by sri
app->config(validation_error_class => 'my-field-with-error');
I'm not 100% sure about this feature yet, so it might still go away, but it
is in our GitHub repo for now.


https://github.com/kraih/mojo/commit/a7fc72cfd41a5dc01bc0167cd230a60c232edb98

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 13:53:16 UTC
Permalink
Post by sri
https://github.com/kraih/mojo/commit/a7fc72cfd41a5dc01bc0167cd230a60c232edb98
We now have more people who have spoken up against this implementation
(here and on IRC) than in favor, so i've removed it again for now.


https://github.com/kraih/mojo/commit/f1ff9bf5c98ae40b0c014067e9b27d0b98d48295

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Myf White
2013-10-25 13:13:23 UTC
Permalink
Post by sri
You mean like this?
app->config(validation_error_class => 'my-field-with-error');
Anyone else like this idea?
--
sebastian
Not particularly.

I'm _very_ keen on this feature request, because I use Twitter Bootstrap
quite a bit, and sometimes struggle with styling client side and server
side validation to look the same.

However, having a global variable for this introduces some other problems.
A nicer solution could be to pass it to the the tag helpers. Downside:
slightly more verbose form views. Upside: more flexibility if you have many
forms across a system, with different styling requirements. Another good
thing about this is you could pass a different class to the label_for and
input_tag.


Kind Regards,
Myf White
*
Email:* ***@gmail.com
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 13:38:47 UTC
Permalink
Post by Myf White
slightly more verbose form views. Upside: more flexibility if you have many
forms across a system, with different styling requirements. Another good
thing about this is you could pass a different class to the label_for and
input_tag.
And what would an implementation of this look like that didn't totally
break backwards compatibility?

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Luc Didry
2013-10-25 14:04:57 UTC
Permalink
Post by sri
Post by Myf White
slightly more verbose form views. Upside: more flexibility if you have many
forms across a system, with different styling requirements. Another good
thing about this is you could pass a different class to the label_for and
input_tag.
And what would an implementation of this look like that didn't totally
break backwards compatibility?
--
sebastian
What about this:
my $validation = $self->validation(error_class => 'my_custom_error_class');

(Like in
http://mojolicio.us/perldoc/Mojolicious/Guides/Rendering#Form_validation)

I don't know what it needs to change in the code. Would it be possible?
What do you think?
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
Myf White
2013-10-25 14:16:36 UTC
Permalink
Post by sri
And what would an implementation of this look like that didn't totally
Post by sri
break backwards compatibility?
Maybe
%= input_tag 'username', error_class => 'has-error text-danger'

And then in the TagHelpers _validation method is passed the parameter, and
either uses it or falls back to 'field-with-error' if there are errors.
Seems like it would be backwards compatible unless TagHelpers code has
substantially changed.

Myf
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 14:23:40 UTC
Permalink
Post by Myf White
%= input_tag 'username', error_class => 'has-error text-danger'
Congratulations, now you've broken the code of everyone who generates tags
with an attribute called "error_class" and introduced a whole new concept
to the framework that has the potential to break a whole lot more and will
be really hard to explain in documentation.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 14:31:57 UTC
Permalink
I have to admit that i'm slowly losing interest in this discussion (would
be much easier to have on IRC), but will take a look again later to see if
you all managed to agree on one of the proposals.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-25 16:43:16 UTC
Permalink
Here's also a 4th proposal, add a helper "tag_with_error" as alternative to
"tag" that can be redefined to generate whatever you like.

--
sri
2013-10-25 16:45:20 UTC
Permalink
I don't expect everyone to agree on a single proposal, but to implement
something we would need at least rough consensus. I'm impartial on this
feature, so can't dictate one solution, it's all up to you now.

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-27 14:18:27 UTC
Permalink
And another proposal, this time from Joel Berger. Have a helper to get/set
the class.

% validation_error_class 'my-field-with-error';

--
sri
2013-10-27 20:21:12 UTC
Permalink
Post by sri
% validation_error_class 'my-field-with-error';
This might actually not be such a bad idea, since as of today there is no
real cost associated with having a lot of helpers.


https://github.com/kraih/mojo/commit/d38bf39293ad67649150c5705b9fba44da339b13

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
sri
2013-10-28 01:02:49 UTC
Permalink
Since no consensus could be reached, i'll dictate a solution, and you're
going to like it, or else! :)


https://github.com/kraih/mojo/commit/9f32bd3688e81f17eb2ba61cba8576ee556bbb34

--
sebastian
--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.
Continue reading on narkive:
Loading...