Panorama views with parameters are very common wherever mass Panorama-based development is made. Some use it within websites and others let the users change the parameters using Panorama WebAccess. When using such views within websites, a common thing that we do is to change those parameters ourselves using the Panorama SDK, where the values are based on the current status of the user, the current time or other parameters which come from outer source such as XML files, Databases, etc.
The main challenge when using parameters within web sites is that you must think of end cases for the parameters' values. When you send a bad parameter to a view using the SDK, the view will sometimes go off and it will stop responding to other things you may do with it in the website. I'll describe it with a life-experience example: We've built a website with panorama paramertized views. Some of the views had FromDate and ToDate parameters, which define the time period for the view to be sliced on. By the way, this is in fact an error by itself - we can use other dedicated functions to do that as described here. The source of these parameters came from a database. The values inside the DB were given from a power user which is the only one who can change them. In some cases, the power user changed these values and the views weren't sliced at all. Debugging it, we've seen that the period between FromDate and ToDate has no data at all so the view wasn't changed. The problem was that once the view was trying to slice on empty period and failed, it stopped responding to other actions (it can be also changed from other controls on the page). So again - think of the end cases when you create parameters-based views.
What I written so far is easy to say, but sometimes you have to do it. The views have to have parameters and sometimes they will get bad data from the users. We have no control over it and we can't deny it. What can we do? A simple approach I use from time to time is to create shadow views. A shadow view is a hidden view (or 1x1 pixel sized) that cannot be seen by the user. Everything that the user tries to do on the real view will be tested before that on runtime on the shadow view. Only if the action succeeded on the shadow view it will be made on the real view. Otherwise, no action will be made on the real view and instead the user will get a message (using Javascript's alert() function, for example) describing why his request cannot be made. The way to check if the user's action succeeded on the shadow view is using output from Panorama SDK functions, but this subject is a little bit wider for this post and it's very case-specific. There are no generic solutions for this problem that I know of, but if I'll find something I'll write another post about it.
To conclude: Think twice about end cases when using parameters inside your views. If you have no choice use the shadow view approach. Write and run tests to check the different values that you'll send to your views.