f.select - disabling option based on the first one selected in Rails - ruby-on-rails

I have a form in which user can select two players from a list (two separate select fields). I managed to do it using options_for_select helper, but
user shouldn’t be allowed to select the same player twice - it obviously can't be something like player1 vs player1. I was experimenting with ‘disabled’ option, but without success, because list of available users should change dynamically after selecting first user, which probably can't be done in Rails?

This is a very broad question, with little details, hence my answer will be generic to cover the majority of cases.
You'll have to use JavaScript to hide the same options from the other list. Rails works server-side, therefore you should reload the page if you want Rails to re-render the list without the selected option. But this is a terrible user experience.
However, you should also perform a server-side check. Even if you add the JS in place, it will still be possible to send a crafted request where the players are the same. This is something that must ultimately be verified at server-side level, in your Rails controller or wherever you have the logic to handle the comparison.

Related

Is it possible to have options on select change from when other select changes without javascript

There are a bunch of question on this but no answers on how to do it without javascript.
If you have one form that has 2 select boxes. The second select box has different options based on what you choose for the first select box. Here is a js example. Not all users have js enabled so for these users this option would be unavailable.
Can this be achieved solely using CSS3, HTML5 and Ruby? I would show what I've got so far in trying this but I got nothing.
What you are asking is how to manipulate the DOM after it has loaded without a client-side scripting language. This is not possible as far as I am aware; unfortunately that is not what you want to hear.
The proper solution in this case would be to have the user submit the page and generate the second selection box at that time. You will have to rely entirely on server-side logic to handle the problem. So basically something like:
Serve a page with just a single selection box
When the page is posted generate a similar page where the first selection is locked and display a second selection box with the possible options.
Continue the iteration until you have all of the required selections filled out by the user.
Serve the result that the user requested.

Concept for a grails app

I am working on a Grails project, its an accounting project. We have multiple clients and they can have multiple types of accounts. I have to create the 'create' page for client, there should be a way to add multiple types of account to the client.
So I was thinking of making a drop-down list with account types and few text boxes to enter account name and other info about account. Also, as a client can have multiple accounts, so I want to create a 'add' button, when clicked it would display a new row to add a new client. I have done this kind of UI before using javascript but in this case, as there is a drop-down list and other components, I think it would be very hard and may not work.
I was thinking of creating a partial view which would render each time user clicked the 'add' button with additional row, problem with this would be during validation errors, edit page and i would also have to pass all values each time user clicks 'add' button.
Is there any other for doing this?
For the template approach you must use ajax if you don't want to carry on the params that the user has already set.
It is possible to make new drop-down lists appear (or any group of elements inside a <div>) when a user clicks a button, since Grails already comes with jQuery you might want to take a look at the .clone() method.
The problem with the two listed approeaches is that it will be possible to have duplicates.
Now, another option is to use checkboxes, so you can check just the type of account you want.
But to be honest it does seems a bit odd or even inapropiate to let the user choose the type of account he wants with such freedom.

Keep some information between different "new" forms

I have a form where the user can choose options from a lot of select boxes. The form is used to register several items from an RSS feed. The user fills in the form, clicks create and is presented with the same form for the next item in the list.
Sometimes, the same options are valid for several items in the list, and I would like to be able to save some of the selections done so the user doesn't have to make the same selection for the next items.
What is the best way of doing this? I've identified four ways of doing it:
Sessions
Just keep the values in the session hash. This will of course work and is very simple, but I have some undefined feeling that it is a bad idea. It will also not work if the user is using the form from different tabs in the browser.
Cookies
Basically the same as keeping them in the session, I think.
Profile
Can't be done in this case I believe, since profiles are shared between several users.
Database
The most complex way I've come up with is to keep the information in the database and use a query parameter to keep track of which information should be used. This is probably overkill, but in some ways the best way to me. I don't like the idea of keeping this kind of state in session or cookies.
Am I missing some way? Or something?
If after filling first form, some data is saved to db (object is created) then you can use this data from db to fill up new form.
If after filling first form, nothing is saved to db, then you can create in memory some objects based on params from previous post and based on this (on just on params) you can prepare new form. But of course data from previous form should be added as hidden fields in second form.

Storing Product List through out session

Im using MVC ASP.NET C#, jQuery
I'm building what could be decribed as the simpliest shopping cart in the world.
Basically My Clients wants users to be able to browse the site, Click on a product they want and it be added to a "list" and then when they "Checkout" they simply fill in a form and it emails my client with the list of products they had chosen!
I was thinking of something like storing them in a cookie. So as the user browses they won't be lost, Then have a jQuery dialog appear when they choose to view/checkout their cart. and it can list all products and then they simply fill in a simple form..
Is this the best way to go about it. Its a cheap website and I would like the simplest way to do this? All i guess I would need to sort is the product Id's..
Any ideas of better ways or any opinions at all!
Using Session depends on whether you think the users will pick the products in one go. Or will they leave the page and come back in an hour? The problem being that if they come back in an hour, the Session State may have been garbage collected to free up resources on the server, or the session might have expired.
To get around this, if all the products are on one page, you could store the chosen products in a hidden field, encrypted and all, that will stay there until the user closes the app.
You just need to serialize the list of product Ids, pass that serialized string to the view and put it in a hidden field.
Another option would be to store it in the users session. A benefit of this is if the user has cookies turned off and the site caters for cookieless session state then they will still be able to select products and checkout.
The thing to look out for is how much you could potentially end up storing in session. From the sounds of it this will not be an issue but if this could potentially use up an unacceptable amount of memory then you would probably need to consider a database approach anyway rather than cookies.
I'd say to go for the Session object. You can always configure the location of Sessions at runtime
I think some may dislike this storage method (it breaks testing isolation, if i'm not mistaken), but it's there for free :)
If you're using jquery, you could store the basket as a json array inside the $('body').data() element (or actually as i do, under a div called '#storage'). this works as a fantastic local storage mechanism, tho' would only be relevant to the current page that the user was on and would be cleared on moving to subsequent 'new pages' unless of course, your design was such that the shopping page was ALWAYS the same page and only refreshed by ajax methods. this way, you could continually append/modify the json structure on the 'worksurface' page.
i use this technique for a different application of the logic, but virtually for the same reason.
here's a snippet of the kind of thing i do:
/* example of data params key*/
var keyParams = "Data-Search-type-" + $('#searchtype').val();
/* add json to body with key*/
$('#storage').data(keyParams, jsonData);
/* get same data back later */
var jsonData = $('#storage').data(keyParams);
When i 'save' the data to the server, i then clear the data() element back to null. There is of course the other option of localstorage itself which can be used well, especially in disconnected environments (such as mobile apps).
another way to skin the many skinned cat!!

Different Editors for one column in EditorGridPanel ExtJS

I am trying to show/load different editor on different rows of a editorgridpanel. Like a textbox on one row combobox/superboxselect on another and it could be any order, random.
The conditions which dictate which editor will be shown reside in the database.
Please tell me if this is possible and if so, how do i go about it.. I have tried pulling the conditions asynchronously which are pulled on a click event for the respective column, but calling it async causes problems. Please advise
Anything is possible, but what you want to do would take a bit of work. The basic idea would be to configure the needed grid editor(s) dynamically and update the columns with the new editors when needed. Now... what would be required to make that actually work I couldn't say offhand without digging into the Ext source -- it would almost definitely require overriding default behavior in the grid and/or column model.
Pulling your conditions asynchronously would (I imagine) be too slow for the interaction of clicking on a row to edit inline. If it takes a second or more from click to configured editors, that would not be acceptable performance. I would try to find a way to send your conditions down along with the other row data if at all possible (they can be in the store's data model on the client without having to be shown in the grid).
Without knowing more about your business requirements, it might be more appropriate to ditch the editable grid and instead go with a dynamically-configured FormPanel tied to the grid. This way the interaction of clicking and then pausing slightly while the form is configured would appear to be more natural. Also, the functionality of rendering a form with a particular configuration is perfectly standard and would require nothing fancy on your end. See this example as a starting point (your form would be dynamic, but maybe the same type of interaction could work?)

Resources