Fix part of API docs
rconstantine - July 10, 2007 - 17:47
| Project: | Active Select |
| Version: | 5.x-1.x-dev |
| Component: | Documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
As I showed in another issue, this sentence in the API docs:
It is very important that the values defined in the '#options' array for each target element include EVERY POSSIBLE OPTION that could be outputted by your activeselect callback function.
is not really correct. In the issue titled This is how to do true AJAX... I point readers to an example of a module that I built using this Activeselect module that does not require that EVERY POSSIBLE OPTION be shoved through the '#options' array.
I think it would be beneficial for all users of this module if the author of the module could look over my module and update the API documentation of Activeselect to reflect how to do this.
#1
I also have a workaround for this problem that is different.
if(empty($edit)) {unset($edit);
$edit = $_POST;
}
While it's not graceful and probably has its own security implications, it allows you to generate the choices for the form that the API is validating against. This preserves the FAPI security routine for matching input to the available choices.
So say you have a State->City AS, you can pull $edit/$_POST values (depending on whether you're using this in a node form or not) to get the State variable. With the state variable you can populate the initial SELECT element with the cities in that state, meaning that upon validation the user's choice will be in there.
#2
So do your cities change dynamically when you select a different State? You mentioned setting "initial" values only. But if so, it seems we've come up with two solutions to the same problem. Does your method ensure that both the city and the State are valid after submission by the user? I ask because you only mentioned that the State is checked.
I'd be interested in seeing how you do yours for security comparison. Although my method puts the onus on the programmer to rigidly verify the submitted data, it isn't that difficult to do. Would you say that your method 'tricks' FAPI into not caring where the choices originated?
Interesting.
#3
Are you sure this would work for users who do not have JavaScript enabled?
#4
@Darren - How's it going? Was your comment direct at #1, or #2? I am not in front of my code right now, but I seem to recall filling the regular FAPI select box with all values if javascript isn't there, but I could be mistaken. Or maybe the activeselect module does that already and I'm just remembering that. I seem to recall reading that.
#5
In rereading the API.txt, I see that it mentions listing all possible values so that it CAN degrade nicely. I know that I check for the presence of activeselect in my module and degrade gracefully if IT isn't there, but perhaps I don't do that if the user has turned off javascript. What is the normal browser check code to check for that? That would be an easy thing for me to check in the same if that I'm checking for activeselect's presence.
I'm glad you brought it up.
Oh, and I meant 'directED at', not 'direct at', above.
#6
I was wondering how either method would avoid the need to include every possible option in the initial array. The activeselect module appears to depend entirely on JavaScript to modify the options array. How would you know the user requesting the form doesn't have JavaScript enabled?
P.S. Great work on OG Forums!
#7
I seem to have found something along the lines of if (Drupal.js_enabled) or something. I don't remember the specifics, but it seems Drupal has a built-in function to test for it.
I'll be working on the release version of og_forum beginning tomorrow. :-)
#8
Right. The jsEnabled function is a jquery thing it looks like. So you don't know if it's enabled until the page loads, and if you didn't send all of the options, then there's no way to get them. It would be cool if there was an environment variable (is that the right terminology?) similar to $user or $_menu that had the browser's javascript-enabled-ness stored before we even got to needing it. Then it could be checked in php and the proper arrangements made for that second (or third, or fourth, etc) drop down list. Maybe there already is and I don't know about it. It might be good to track other data about the users system and browser as well. Perhaps each page load could update these data.
Anyway, it looks like my method (don't know about Fool2's) requires javascript.