Hello together,

...

Is it true that Drupal will utilise AJAX in future versions?

Yes, Ajax support has recently been added to cvs.

...

Will I be able to disable anything related to AJAX if I ever upgrade to an AJAX-enabled version?

You could replace the drupal.js files by an empty file.

That means, Drupal will work as before without Javascript?

When I started with Drupal, it was one of the very few CMS working in all features (especially admin) with "Javscript OFF". While I understand that there are features in AJAX some people do like, I hope Drupal core and main modules will stil not depend on any JS functionality.

Thanks Franz

Hallo Carlos,

...

...

When I started with Drupal, it was one of the very few CMS working in all features (especially admin) with "Javscript OFF". While I understand that there are features in AJAX some people do like, I hope Drupal core and main modules will stil not depend on any JS functionality.

I'm just curious why do you need it with out JS ?

I guess not everybody is eager to discuss it here ;-) but I try a short answer. Its a matter of privacy, security and, yes, comfort.

- While JS can be done securely, of course, I consider it - e.g. - a "damage-multiplicator" if something is going wrong.

- JS can deliver more information about the client (thats my computer) to the (foreign) server than Html alone.

- Surfing the web with "JS on" allows "dumb" sites to modify my browsers (mouse functions changed, fixed windows etc.) more than I want to tolerate. There are browsers which can be configured with some "granularity" about this, but why bother - server side scripting is enough for me ;-)

(some advertising goes away w/o JS as well - but thats not the main point).

Servus Franz

On Fri, 3 Jun 2005, Franz Iberl wrote:

...

...

Is it true that Drupal will utilise AJAX in future versions?

Yes, Ajax support has recently been added to cvs.

...

Will I be able to disable anything related to AJAX if I ever upgrade to an AJAX-enabled version?

You could replace the drupal.js files by an empty file.

That means, Drupal will work as before without Javascript?

Right.

When I started with Drupal, it was one of the very few CMS working in all features (especially admin) with "Javscript OFF". While I understand that there are features in AJAX some people do like, I hope Drupal core and main modules will stil not depend on any JS functionality.

We will be adding more Ajax features, but we are very much interested in keeping Drupal working without JS.

Cheers, Gerhard

On Sat, 4 Jun 2005, NSK wrote:

On Saturday 04 June 2005 09:18, Gerhard Killesreiter wrote:

...

We will be adding more Ajax features, but we are very much interested in keeping Drupal working without JS.

That's a good thing, but isn't it possible to control AJAX/JS functionality from the admin interface or from the config file,

Sure, that would be possible. We generally try to avoid adding settings which aren't neccessary, though.

instead of just hacking the source in order to empty the js file?

echo "" > misc/drupal.js can hardly be considered hacking.

Cheers, Gerhard

Gerhard Killesreiter wrote:

On Sat, 4 Jun 2005, NSK wrote:

...

instead of just hacking the source in order to empty the js file?

echo "" > misc/drupal.js can hardly be considered hacking.

Cheers, Gerhard

Many hosting services do not provide shell access. Requiring shell commands to do an install or set an option is a hack in my humble opinion.

Further thoughts on the broader topic:

We need to find a way to allow much more administrator customization without requiring shell access. Too often the reason for not adding admin option to configure something is the valid and good desire to keep the number of admin options to "manageable" size or the smallest size possible. Perhaps what we really need to do is look at ways to make the admin options more manageable and understandable. Much of that is human factors / interface usability work.

I would suggest that admin options be divided into the "usual" set of options and a "power user / config every possible setting" set of options. Perhaps the latter merely sets lots of values for various variables, so that the person doing the changing is really required to know what they are doing -- the equivalent of editing some of the static variables kept in settings.php.

Yet another simpler possibility is to add many more settings to settings.php for these kinds of things. Then all that is require of the admin is the ability to edit the settings.php file and upload it to his/her hosted site, something they must be able to do anyway to install Drupal. No command line needed.

Then settings.php might have a line that says:

$ajax_subroutines = "misc/drupal.js"; // if blank, JS is disabled.

-- Chris Johnson

On Sat, 4 Jun 2005, Chris Johnson wrote:

Gerhard Killesreiter wrote:

On Sat, 4 Jun 2005, NSK wrote:

...

instead of just hacking the source in order to empty the js file?

echo "" > misc/drupal.js can hardly be considered hacking.

Many hosting services do not provide shell access. Requiring shell commands to do an install or set an option is a hack in my humble opinion.

This was just how I'd do it. Others might want to open the file, empty it, and upload the empty file to their server.

Further thoughts on the broader topic:

We need to find a way to allow much more administrator customization without requiring shell access.

None of the various Drupal admin options currently really depends on shell access.

Too often the reason for not adding admin option to configure something is the valid and good desire to keep the number of admin options to "manageable" size or the smallest size possible. Perhaps what we really need to do is look at ways to make the admin options more manageable and understandable. Much of that is human factors / interface usability work.

We are always interested in people who want to do usability work for Drupal.

I would suggest that admin options be divided into the "usual" set of options and a "power user / config every possible setting" set of options.

I had once suggested the same, but Dries didn't like it. Was some time ago, so he might reconsider this.

Perhaps the latter merely sets lots of values for various variables, so that the person doing the changing is really required to know what they are doing -- the equivalent of editing some of the static variables kept in settings.php.

Yet another simpler possibility is to add many more settings to settings.php for these kinds of things. Then all that is require of the admin is the ability to edit the settings.php file and upload it to his/her hosted site, something they must be able to do anyway to install Drupal. No command line needed.

Then settings.php might have a line that says:

$ajax_subroutines = "misc/drupal.js"; // if blank, JS is disabled.

What we could do is to have variables that are only settable in settings.php, ie

$conf['ajax'] = 1; // if 1 use Ajax

But for the current case I don't see this happening.

Cheers, Gerhard

That means, Drupal will work as before without Javascript?

When I started with Drupal, it was one of the very few CMS working in all features (especially admin) with "Javscript OFF". While I understand that there are features in AJAX some people do like, I hope Drupal core and main modules will stil not depend on any JS functionality.

Just because we add Ajax features doesn't mean that Drupal will not work without. Any Ajax functionality being added must not harm the user in any way when JS is off. As it is now, we only have the Ajax autocompletor: a pure enhancement which is simply not present without JS.

Steven Wittens

On Friday 03 June 2005 12:26, Gerhard Killesreiter wrote:

You could replace the drupal.js files by an empty file.

I'm not sure this is the correct way to implement the non-AJAX mode in future Drupal versions. It sounds like the plans are to make Drupal a JS-required CMS, which would destroy its balance of features and compatibility/user-friendlyness.

I personally wouldn't upgrade to any AJAX-enabled Drupal version. If there are other people like me on this list and you know php, perhaps we could help implement a non-JS mode for Drupal, if the main developers agree.

Who dislikes JavaScript in this list?