The question is: is it a good way of programming using the method addFieldError OUTSIDE the validate method?
Suppose that:
my validate method only checks if some textfields are empty or not, and if they are, my addFieldError makes some fieldErrors to show up.
my execute method, after processed the login request by calling a method of the right Java Bean, knowing that the username and/or the password were incorrect, needs to call addFieldError with an appropriate error message.
Of course, that the execute method will return INPUT in case of wrong username/password and SUCCESS if Log in was successful.
Is this approach okay?
It would make not much sense to write the field error wrong username aside the username textfield, or wrong password aside the password textfield, because one of them may be correct, and you can't know (or better, should not let user know) which one. Also it would be ugly to write two times the same message like username or password wrong...
In these cases, you should use Action Error:
addActionError("Username or password incorrect.");
And in (generally the top part of) your JSP page, check for it, and then display it correctly:
<s:if test="hasActionErrors()">
<div class="feedError">
<s:actionerrors />
</div>
</s:if>
read more on this answer.
Related
(ZF2) Is there a possibility to check in view that the form is displayed for the first time, or "returned" because of errors?
Of course I can in controller base on isValid add additional variable, but I'm curious if there is a ready solution to this?
You can check if the form has been validated with $form->hasValidated() if it hasn't you prob can be pretty sure it's displayed for "the first time".
Additionally you could check if the form contains any error messages $form->getMessages(). That way you could tell if it is validated and contains validation errors.
I have User model which includes 7 fields. for all these fields validation is written.i have two form where i am displaying fields depend on condition. in one form i have name password and city and other form i have role,phone and name.
When i try to submit the first form i got the error which says phone and role field are required resulting into failure of form.
Is there any way by which i can submit both form without getting the validation errors ??
Note : i want my logic to be in model only.. Please help me with this problem.
You could use a conditional validation to achieve what you want:
See here: http://guides.rubyonrails.org/active_record_validations.html#conditional-validation
However, this can quickly get hard to manage. Depending on the condition you're switching on, it'd probably be a cleaner design to use a 'Form Object' which will give you more control and let you do validations without the messy conditional logic.
See section #3 of this blog post for more detail:
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
Using this pattern, you would check for your condition in the controller then determine which form object to send to the view.
I've searched a lot to try and solve this problem, but I'm not quite sure what to search for. I didn't really manage to find anything.
Essentially I'm working on a website in which users can register for an event. However, if the user is not logged in, I need to redirect them to the registration screen. This much I've been able to accomplish without much difficulty. However I need to redirect back to the event that they attempted to register for.
My real problem is that the URL of the page I need to return to contains an a parameter, and I'm not sure how to make the registration page take that parameter into account when it redirects back.
Currently when an anonymous user tries to go to
http://[...].com/drupal/?q=civicrm/event/register&id=6
I have it redirect you to
http://[...].com/drupal/?q=user/register&destination=civicrm/event/register&id=6
However, once the form is submitted the "&id=6" is not taken as part of the destination parameter, which means you just go to.
http://[...].com/drupal/?q=civicrm/event/register
Which is not a valid page.
Is there a way for me make the destination parameter include "&id=6"?
On a whim I've also tried.
[...]destination='civicrm/event/register&id=6'
[...]destination="civicrm/event/register&id=6"
[...]destination=civicrm/event/register#id=6
You need to url-encode the value for your destination. Try this:
[..]destination=civicrm/event/register%3Fid%3D6
%3F is hex code for question mark (?), %3D is code for equals (=).
I ask this because I have a form with a radio button set to nil :
= f.radio_button :estimate_type, nil
I have debugger right at the beginning of my method call :
def create
debugger
When I hit the debugger, I check out my params, and they say the value is on not nil.
Enter Insanity wolf. Somehow this is getting converted on click. And I've scoured the entire app looking for possibly a leaky javascript file, or anything closely resembling the word 'on'. I've checked all my bases. Defaults in schema.rb, jquery click events, model validations, you name it. Nothing with the word "on" anywhere.
So the real question is, is there a way I can throw a debugger in a place in which if I were to click submit, the debugger would appear before the model validation, and then hopefully where the params are still what they are in the form. And then I can follow it down the trail and see where it goes wrong.
It doesn't have anything to do with your JavaScript. This is something that I've experienced before as well, but I'm not sure why it converts nil to 'on'. I do know that passing in :nil as a symbol returns a null string, as well as just simply passing in false.
A better approach to trying to solve your problem may be to put the debugger in the validation callback itself.
Nothing to do with rails - you could verify this by using your browser's network inspector to see that the browser is actually sending the parameter value "on".
By trying to set the value to nil (which doesn't really make sense - parameter values are always strings) you're suppressing the value attribute entirely from the generated HTML.
The standard says that in this case the default value for the input shall be "on" and so that is what your browser submits.
there is this code below in sfDoctrineGuardPlugin.
$a = sfConfig::get('app_sf_guard_plugin_success_signin_url');
var_dump($a);
$signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));
var_dump($signinUrl);
var_dump($user->getReferer($request->getReferer()));
It prints this:
null
string
'http://rs3.localhost/frontend_dev.php/'
(length=38)
string
'http://rs3.localhost/frontend_dev.php/miembros' (length=46)
I don't know why the the second and the third lines are different..any idea?
Regards
Javi
Weird. Spooky.
I wonder if maybe the two calls to getReferer() are in different contexts? Maybe the first (as the second arg to sfConfig::get()) implicitly uses __toString() whereas when you use var_dump(), maybe it's printing the raw value of the referer object?
Hrmm... the API says getReferer() returns a string, so that's probably not it.
What are you trying to do, BTW? Is it not honoring your app_sf_guard_plugin_success_signin_url setting from app.yml?
sfDoctrineGuardPlugin sets a referer attribute in the user, so that it can redirect back to the page originally requested. When you call getReferer it removes the attribute. (This is causing bugs for me, which is what brought me here.)
yitznewton pointed me towards a solution. The sfGuardSecurityUser class uses a method setReferer that saves a referer attribute but only if one is not yet set.
If somehow you manage to get to the executeSignin method in the sfGuard actions twice only the first referer attribute will be saved, this means that the second time the referer in the request and the referer in the user attribute can be different.
The getReferer method removes that attribute, and falls back to the request referer when the attribute is not set. this explains why calling $user->getReferer($request->getReferer()) twice returns different values sometimes.
The solution i found was to overwrite the setReferer method of the sfGuardSecurityUser in the myUser class:
public function setReferer($referer) {
$this->setAttribute('referer', $referer);
}
So far i have not found any side effects, this change ensures the user attribute will allways be the most recent, however there has to be a reason to explain why the symfony folk chose to implement this as it was.
Ive tested this by switching between apps on the login screen, allowing the session to die, killing the session manually and normally using the application and so far i have not found any side effects.