I have a VisualForce page that has three functionalities,
Hence it has three 'public PageReference' subroutines,
That are called when an action happens in the page [i.e. button]
One of the functionalities requires user input [i.e. inputText],
So the main APEX code has a variable declaration for that input:
public String UserInput { get; set; }
Since each task is not really related,
When I hit the button on the other two functionalities,
I get a VisualForce error,
Because the inputText object has no user input,
How can I prevent that from happening,
Another way to solve this,
How do I turn off VisualForce Error messages?
So I can do error handling from APEX,
Looking at the debug log file,
The error is in VisualForce NOT APEX,
Thanks
If you don't want to fire validation you can use the immediate = true attribute on the CommandButton/CommandLink to bypass any validation. - This isn't optimal in my opinion
If you only want to submit part of a page and still fire validation have a look at the ActionRegion. This should allow you to wrap a particular Region for the action call. This is probably best for your purpose.
Sorry I don't have time to post full examples but that should point you in the right direction :)
Related
The specific case I've got in mind is as follows: an AjaxFormComponentUpdatingBehavior("onchange") is added to a TextField in a form. The behavior verifies the text for certain conditions (either the model object or the form component model, doesn't matter), based on which it might display a message (or hide it, if it has already been shown).
The problem is, there are also validators added to the TextField. One of the possible (and likely) scenarios consists of the user typing in, first, a value that causes the message to be displayed by the AJAX request. If, then, he/she types in a value that doesn't pass validation, the message should disappear, but it does not.
Apparently, either the onUpdate() method for the AJAX behavior is not called at all, or I am failing in my attempts to insert a check for non-validated entries (I have tried to test for both null values and empty strings, to no avail; I have no idea what exactly Wicket's validators do to models when data is invalid).
I am wondering if someone who actually understands validators (or AJAX, actually) has any ideas on where the problem could be.
I can post edit and post code if someone tells me this is not a general issue tying validators and AJAX, but most likely a programming mistake. I still believe the former and thus I'll refrain from posting code sections, in order to keep the discussion on an API/theoretical frame.
Thanks.
When using an AjaxFormComponentUpdatingBehavior, if any of the IValidators fail their validation, onError() will be called instead of onUpdate(). Wicket will effectively prevent invalid user input from reaching the IModels in your components, so the component's ModelObject will not be changed at all. The invalid input will probably remain available by means of getInput()/getConvertedInput() (not sure if it will in an AJAX scenario, it sure is in a traditional form submission).
However, take into account that IFormValidators are not executed when using this mechanism. If you've got any, you might be interested in overriding getUpdateModel() so that AjaxFormComponentUpdatingBehavior will not bring maybe-invalid user input into your IModels, and set modelobjects manually when you're certain user input is valid.
Regarding your specific case, you could perform all the required logic in onError() (or rely on Models that will grab data from somewhere else), and just add the components that need refreshing to the AjaxRequestTarget. This is probably what's missing in your scenario.
I know that we can design the layout in *.xml then in the action just invoke loadLayout, and renderLayout to render the blocks/views.
But, I have a question is:
- How can I load the layout at runtime?
If we have an action which does not really design its layout and will be decided how to render at runtime.
You can please consider the answer from the question for more clear.
Writing a new answer because it seems that you actually DO still want to render, you just want to render a different route's layout XML updates. I believe the _forward() method from Mage_Core_Controller_Varien_Action will allow you to do what you are describing with the least amount of pain.
You should add your action controller directory ahead of the catalog directory, create a ProductController with a viewAction, and check customer is not logged in - in this check you would call $this->_forward('customer','account','login');.
This approach though is going to require more effort in order to be usable, as I imagine that you want the user to be sent to the product page upon login. Have you seen Vinai Kopp's Login Only Catalog module? It should do this for you.
loadLayout() and renderLayout() just execute block output method toHtml() (usually) and take the resulting strings and apply them to the response object via appendBody(). In an action controller you can just call $this->getResponse()->setBody('response string'). How you build the string is up to you.
You can also use Mage_Core_Block_Flush to immediately send output to the browser without using the response object.
On a webpage we have the following system of server side form validation. For example, if the user is adding date-details for an event (and an event can contain many such date-details), we call a javascript function on click of the 'Add' button like below.
validateForm('frmName','codelibrary/classes/myclass.php','validationArrName')
where:
#frmName = form name
#codelibrary/classes/myclass.php = location of class file, that contains classes and functions for server side validation
#validationArrName = Type of validation we apply
In the php script, validationArrName is defined as a list of keys (representing form fields) and values (representing the functions we will call to validate that form field).
validationArrName = array ('fieldName1'=>validationFun1,'fieldName2'=>validationFun2);
eg:
fieldName1 = email_address
validationFun1 = validateEmail()
On the html page, we call the server side validation through ajax as follows.
$.post(className,$("form[name="+formName+"]").serialize()+"&isValidate=1&validateArrayName="+validateArrayName,function(data){ ... });
If the validation function reports an error, we display an appropriate error message back on the html page.
The problem is that when we do this for the very first time (eg: after a hard refresh of the page), submitting this date-details form for validation takes a lot of time, as compared to subsequent requests.
We observed that instead of calling the codelibrary/classes/myclass.php file once, it actually refers to this file more than 10 times before jumping to the required location (validationArrName) and running that.
For subsequent requests, it works fine and refers to that file only once.
What could be the issue here? Could there be an issue with our usage of jquery submit ?
the best thing you can do is time stuff.
in javascript:
console.time('post load'):
$.post(className,$("form[name="+formName+"]").serialize()+"&isValidate=1&validateArrayName="+validateArrayName,function(data){
console.timeEnd('post load');
console.log('data');
...
});
in php, use microtime to time different part and echo them. they will be printed in the console.
It should not be cache or include related, as ajax starts a new connection each time.
Following your comments, I edit this answer:
I'm still at loss of what happens. However I see two possibilities. The first one is that you use a "flag" to validate forms or not. When you load the page, all forms flag are unset, and first submit check them all. Subsequent submits works correctly.
Another option is that the first time you submit a form, you dont event.preventDefault() on the submit click, but it's still a loosy explanation.
I would love to see how you call the $.post(...) function (how the submit button is binded, or how $().submit() is called).
Let's start by getting on the same page about MVC on the web. The control receives requests, selects a view, sends a response that it gets from the view. (Maybe the control gets data from the model, maybe the views do it themselves, I don't care.) Errors can occur, so we want to handle the errors and display a message or error page to the browser.
I'm trying to decide if these error messages/pages are part of the control or come from the view. Perhaps it is different for different kinds of errors.
some examples:
The request path is meaningless, so we want to respond with a custom "not found" page.
The control selects the "not found" view and uses its response
The control builds the "not found" page itself
.
The controller selects a view successfully, but the view throws an exception.
The view returns an error status. The controller checks the status and then selects a new view and uses its response
The view returns an error status. The controller build the error response itself.
The view handles the exception and returns a valid error page or message to the controller. The controller blindly sends it as the response.
Now, the difference between the first two options in both cases is technical/organizational, and there is probably no difference to the user. Is there a standard opinion on this (perhaps across MVC frameworks) or is the choice just arbitrary? What is the preferred method?
The controller selects a view successfully, but the view throws an exception.
If the MVC design pattern is followed, this should never happen. The only logic that should be contained in a view is solely display logic (formatting, localizing etc).
Errors should be trapped either at the model or controller level, but it's up to the controller to decide what to do with the user (redirect/404/etc).
Edit:
Of course it's not the only way.. I'm sure that you can find hacked up, bastardized code all over the place that does different things. As far as I'm concerned, yes - your views should be engineered in such a way that errors will not need to be trapped (other than ajax/javascript errors, but that's where they belong anyway).
I usually set it up so that I have a different view for each HTTP error code I want to handle, and a generic one for a catch-all. The controller will be responsible in this case to pass the error data to the view for rendering (usually as an array). Of course, this could also be done using an ErrorModel (which would be the 'correct' way of implementing it - I'm just lazy ;))
The approach I take is to allow the controller to handle your first case (route based errors). Any request made that is either unauthorized or poorly formed gets managed by a "static content" controller that renders the appropriate error view.
For your second class of errors - I'm not sure how/if the view can communicate back to the controller that it's thrown an error. I'm actually interested to see other's opinions, because as far as I know if a view encounters an error, it's up to the view to deal with it.
Okey, this might seem a bit strange question so I will explain.
Do I really need to create a postback that explains what is wrong with form if it's not validated if I also use JS for it?
I am of course validating user input and I use somewhat "general" approach. For instance if something is not validated it will just show "Some error occurred, check your input bla bla..". I am not creating postback for every input so that it will shot "Your username is suppose to be at least 3 characters long etc.." and I don't do this because JS is doing that on the fly.
My server-side validation only is like a guard against stupid/wrong entries where name is empty or something along that, rest is up to jQuery. Form will always be valid if client is running JS. I am doing it to save my time.
My question is - is it a bad idea? I just don't see why because everyone is running JS anyway and my server is not allowing bad/invalid entries to be put in DB even with JS off.
I don't think that's a bad idea, data validation can be client side. If something goes wrong, i just throw a generic error.
I only validate server side the business rules