The activeselect module is a new addition to Drupal contrib, that defines a new type of select form element. Each activeselect element has one or more 'targets' defined: the targets are other form elements - either regular select boxes, or other activeselect boxes. When the user selects a new option in an activeselect element, their selection is immediately sent back to the server (using AJAX), and the server sends back a list of new options with which to populate the 'target' elements. The activeselect module is here: http://drupal.org/node/49976 I am posting this message here, because I think that this kind of functionality could be of immense benefit in many of the UIs in Drupal contrib (and possibly even Drupal core). Activeselect is so far only being used by the category module (http://drupal.org/node/39683), but it has been designed with reusability in mind. It is a component that can increase the usability of complex forms, and if used properly, it can degrade gracefully. I would like to encourage all module developers to consider any user interfaces in your modules that could benefit from select boxes linked by AJAX, and to make use of the activeselect module if appropriate. How you integrate activeselect into a module is completely up to you. All it does is provide the framework and the necessary JS library: the real power of this module depends on what an activeselect callback function is programmed to do. In the case of the category module, it is quite significant. Instructions for developers have now been written, and can be found in the API.txt file included with the activeselect module. These instructions tell you everything you need to know, to start making use of activeselect elements in your module's forms. The module is still quite new, and although it has been thoroughly tested and it functions correctly (in IE and Gecko/FF - feedback on other browsers appreciated), it definitely still has some rough edges. In particular, the code could probably be a bit cleaner than it is (especially in the category module's callback implementation). Please file any and all issues through the issue tracker on drupal.org. Jeremy Epstein GreenAsh Services www.greenash.net.au
Jeremy Epstein wrote:
The activeselect module is a new addition to Drupal contrib, that defines a new type of select form element. Each activeselect element has one or more 'targets' defined: the targets are other form elements - either regular select boxes, or other activeselect boxes.
yes, this sounds like a terrific addition. Please share some demo URLs once they arise ... I'm curious how you implement choice checking when the forms are constantly changing on the client side. I imagine you are implementing the DANGEROUS_SKIP flag.
On 3/16/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
yes, this sounds like a terrific addition. Please share some demo URLs once they arise ... I'm curious how you implement choice checking when the forms are constantly changing on the client side. I imagine you are implementing the DANGEROUS_SKIP flag.
No, actually I wasn't aware of that flag (but I am now - thanks!). At the moment, choice checking is no different to that for a regular select element, as the category module implementation puts all possible options into the element on the server side. The AJAX then (effectively) simply removes a whole bunch of these options. But maybe implementing this flag, and using more intelligent validation, could be a possible improvement... then again, maybe the way it is now is about as good as it can get (since the current method degrades well without JS). Please see the API.txt file for details on this issue. Jaza.
On Fri, 2006-03-17 at 00:19 +1100, Jeremy Epstein wrote:
On 3/16/06, Moshe Weitzman <weitzman@tejasa.com> wrote:
yes, this sounds like a terrific addition. Please share some demo URLs once they arise ... I'm curious how you implement choice checking when the forms are constantly changing on the client side. I imagine you are implementing the DANGEROUS_SKIP flag.
No, actually I wasn't aware of that flag (but I am now - thanks!). At the moment, choice checking is no different to that for a regular select element, as the category module implementation puts all possible options into the element on the server side. The AJAX then (effectively) simply removes a whole bunch of these options. But maybe implementing this flag, and using more intelligent validation, could be a possible improvement... then again, maybe the way it is now is about as good as it can get (since the current method degrades well without JS).
Please see the API.txt file for details on this issue.
Jaza.
ooh, ooh, ooh it degrades!! I was trying to figure that out in 4.6, but was having trouble... Dude you rock.
On Fri, 17 Mar 2006 00:19:42 +1100 "Jeremy Epstein" wrote:
(since the current method degrades well without JS).
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context? normally, i'd think "code that degrades" isn't something to cheer about. ;) if there's a quick 1 sentance explaination (or a link), i'd appreciate it. otherwise, thanks for this contribution. from what i can gather, this seems like it could help a lot of module UI's out there. here's one: i'm thinking of event-enabled nodes... when you enter the start time, the end time could be automatically pre-filled to be some configurable event duration (e.g. 1 hour) into the future from the start time. that'd be a nice feature. don't know if this requires activeselect or not (see http://drupal.org/node/25618), but maybe activeselect would make it easier to do... thanks, -derek (dww)
"Degrade", in the parlance of coders, means "doesn't break other stuff if it's not supported". So, if the user's browser doesn't support AJAX, this module shouldn't prevent the calling module from functioning normally, albeit without the nifty AJAX functionality. -- Dan Ziemecki Philosopher. Curmudgeon. Nerd. On 3/16/06, Derek Wright <derek@dwwright.net> wrote:
On Fri, 17 Mar 2006 00:19:42 +1100 "Jeremy Epstein" wrote:
(since the current method degrades well without JS).
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context? normally, i'd think "code that degrades" isn't something to cheer about. ;) if there's a quick 1 sentance explaination (or a link), i'd appreciate it.
otherwise, thanks for this contribution. from what i can gather, this seems like it could help a lot of module UI's out there.
here's one: i'm thinking of event-enabled nodes... when you enter the start time, the end time could be automatically pre-filled to be some configurable event duration (e.g. 1 hour) into the future from the start time. that'd be a nice feature. don't know if this requires activeselect or not (see http://drupal.org/node/25618), but maybe activeselect would make it easier to do...
thanks, -derek (dww)
On Thu, Mar 16, 2006 at 06:46:56PM -0600, Derek Wright wrote:
On Fri, 17 Mar 2006 00:19:42 +1100 "Jeremy Epstein" wrote:
(since the current method degrades well without JS).
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context?
"Degrades well" means that it works well with older browsers which do not support JS, or with browsers which have it disabled. HTH, -- Keegan Quinn <keegan@thebasement.org> CEO, Producer the basement productions http://www.thebasement.org
On Thu, 2006-03-16 at 18:46 -0600, Derek Wright wrote:
On Fri, 17 Mar 2006 00:19:42 +1100 "Jeremy Epstein" wrote:
(since the current method degrades well without JS).
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context? normally, i'd think "code that degrades" isn't something to cheer about. ;) if there's a quick 1 sentance explaination (or a link), i'd appreciate it.
Degrade, in this context means it works with javascript disabled. Hope that helps.
otherwise, thanks for this contribution. from what i can gather, this seems like it could help a lot of module UI's out there.
here's one: i'm thinking of event-enabled nodes... when you enter the start time, the end time could be automatically pre-filled to be some configurable event duration (e.g. 1 hour) into the future from the start time. that'd be a nice feature. don't know if this requires activeselect or not (see http://drupal.org/node/25618), but maybe activeselect would make it easier to do...
thanks, -derek (dww)
On 17/03/06, Derek Wright <derek@dwwright.net> wrote:
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context? normally, i'd think "code that degrades" isn't something to cheer about. ;) if there's a quick 1 sentance explaination (or a link), i'd appreciate it.
The key is "degrades well" (or "degrades gracefully") rather than just "degrades". ie if it is unsupported it falls back to lower tech ways of working rather than just breaking. -- Cheers Anton
Derek Wright wrote:
pardon my general ignorance of AJAX and JS, but what does "degrade" mean in this context? Well, everyone else covered 'degrade' I think, but you might be happier thinking of it the other way around, and in a more positive way.
Without AJAX and JS the module works, with them it has *enhanced* functionality/usability etc. The key is that JS is used to enhance normal functionality, not replace it. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Op vrijdag 17 maart 2006 11:35, schreef Adrian Simmons:
Without AJAX and JS the module works, with them it has *enhanced* functionality/usability etc.
The key is that JS is used to enhance normal functionality, not replace it.
*This* is tha attitude! :) AJAX is *not* there to be cool and nice, and in case of missing support, you build something less nice. No: you have something nice. And with some AJAX you add extra niceness. It requires developers to thing the right way around too: * buid something that works, and is full functional, with ordinary HTML and forms. * On top of that you add CSS * On top of that JS to alter the DOM. (the J from AJAX) * Make sure you do negative checks, to avoid broken support: not if (in(unsupported.browsers) ) doNothing else doTheStuff; but if (in(fully.supported.browsers) ) doTheStuff else doNothing * On top of that you add asynchronous communication (the A and the X from AJAX) AJAX is then the icing. not the cake. that is the correct attitude IMO. If one does not follow this attitude, you end up with the same crap we saw four-or-five years ago, DHTML document.write("sorry your browser is not supported, please visit microsoft.com for the latest browser, its free") Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
participants (9)
-
AD. -
Adrian Simmons -
Bèr Kessels -
Dan Ziemecki -
Darrel O'Pry -
Derek Wright -
Jeremy Epstein -
Keegan Quinn -
Moshe Weitzman