kudos to Steven, and how to get rid of the resizing JS.
Hello there. I do not mean this mail as a rant. So if it sounds like that, just reread this first sentence :) Steven has made really cool ajaxy stuff, and javascript features for Drupal. His last addition for Drupal was a cool form-field resizer. but ehh. I *personally* don't want it. My client got (a little) angry because it broke his (development) site; its due to a theme/CSS issue, but still. I have to bill him for a fixing a feature he never asked for. Also, I certainly don't want it on none-admin areas like the feedback form. That is again, a personal decision. But I think end-users (those filling in their address in a feeback for, for example) should not get all that JS shazam, but a properly pre-sized textfield. I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it". Used for the sake of using it. Not that I am saying Drupal is going that way, but we must certainly be aware of it. And certainly start sticking dubious JS stuff in contrib (or even core) modules. Anyway. the form resizer broke on my theme. It broke my quicktags and it broke one version+theme of tinyMCE. All of wich I think are not bugs in core but in my theme, module and that version of mce with the specific theme. I was told before to make a patch to switch off the JS globally. But IMO that is not the correct route. Switching on and off development stuff on a user interface is not a good option, IMO. So, anyone here who knows how I can not have js in Drupal? Do I really need to develop a no_js.module that uses alter hooks for the forms? Or does anyone know a better route? Sorry to start about RoR again. But RoR is amoungst the forefighters of AJAX. It offers a lot of ajax apis in "core". Yet it is up to the developer to implement it or not. I think that this might be a route worth looking at: provide modules, and apis to use in themes and modules for AJAX stuff. Instead of deploying it by default. Though that is for a future, not for now. :) Now I just want to know if there's an easy way of switching off AJAX and JS stuff so that i can fix up themes and modules that break. then slowly deploy it where i like to deploy it ;) Bèr
Steven has made really cool ajaxy stuff, and javascript features for Drupal. His last addition for Drupal was a cool form-field resizer.
but ehh. I *personally* don't want it. My client got (a little) angry because it broke his (development) site; its due to a theme/CSS issue, but still. I have to bill him for a fixing a feature he never asked for. Also, I certainly don't want it on none-admin areas like the feedback form. That is again, a personal decision. But I think end-users (those filling in their address in a feeback for, for example) should not get all that JS shazam, but a properly pre-sized textfield.
I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it". Used for the sake of using it. Not that I am saying Drupal is going that way, but we must certainly be aware of it. And certainly start sticking dubious JS stuff in contrib (or even core) modules.
Well, textarea resizing is not AJAX, and the form element collapsing is also not AJAX.
Now I just want to know if there's an easy way of switching off AJAX and JS stuff so that i can fix up themes and modules that break. then slowly deploy it where i like to deploy it ;)
You can override how textareas are displayed in your theme and can turn off this JS thing there too. Goba
Hi, I have to agree with Bèr 100%, this is really should be in contrib, and not in core. I feel that this is if we were to include, htmlarea, tinymce or fckeditor into core with no way of turning them off. This is a feature that should be left to the site admins to enable, or as a possible choice that they can include into their site. Not be default. Please remove this from core, or disabled by default with the option to enable it if the admin/user wants too. This doesn't break Xinha, but does cause issues. Gordon. On Mon, 2006-01-02 at 22:24 +0100, Bèr Kessels wrote:
Hello there.
I do not mean this mail as a rant. So if it sounds like that, just reread this first sentence :)
Steven has made really cool ajaxy stuff, and javascript features for Drupal. His last addition for Drupal was a cool form-field resizer.
but ehh. I *personally* don't want it. My client got (a little) angry because it broke his (development) site; its due to a theme/CSS issue, but still. I have to bill him for a fixing a feature he never asked for. Also, I certainly don't want it on none-admin areas like the feedback form. That is again, a personal decision. But I think end-users (those filling in their address in a feeback for, for example) should not get all that JS shazam, but a properly pre-sized textfield.
I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it". Used for the sake of using it. Not that I am saying Drupal is going that way, but we must certainly be aware of it. And certainly start sticking dubious JS stuff in contrib (or even core) modules.
Anyway. the form resizer broke on my theme. It broke my quicktags and it broke one version+theme of tinyMCE. All of wich I think are not bugs in core but in my theme, module and that version of mce with the specific theme. I was told before to make a patch to switch off the JS globally. But IMO that is not the correct route. Switching on and off development stuff on a user interface is not a good option, IMO.
So, anyone here who knows how I can not have js in Drupal? Do I really need to develop a no_js.module that uses alter hooks for the forms? Or does anyone know a better route?
Sorry to start about RoR again. But RoR is amoungst the forefighters of AJAX. It offers a lot of ajax apis in "core". Yet it is up to the developer to implement it or not. I think that this might be a route worth looking at: provide modules, and apis to use in themes and modules for AJAX stuff. Instead of deploying it by default. Though that is for a future, not for now. :)
Now I just want to know if there's an easy way of switching off AJAX and JS stuff so that i can fix up themes and modules that break. then slowly deploy it where i like to deploy it ;)
Bèr
!DSPAM:1000,43b9a274136512601091748!
Bèr Kessels wrote:
I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it".
"Wordpress does it" was apparently the reasoning in this case. :p I haven't tried it yet, but I fail to see the usefullness of browser textareas for more than two or three sentences anyway. It is probably a case of "oh, shiny!!!!1!".
Used for the sake of using it. Not that I am saying Drupal is going that way, but we must certainly be aware of it. And certainly start sticking dubious JS stuff in contrib (or even core) modules.
Anyway. the form resizer broke on my theme. It broke my quicktags and it broke one version+theme of tinyMCE. All of wich I think are not bugs in core but in my theme, module and that version of mce with the specific theme. I was told before to make a patch to switch off the JS globally. But IMO that is not the correct route. Switching on and off development stuff on a user interface is not a good option, IMO.
So, anyone here who knows how I can not have js in Drupal? Do I really need to develop a no_js.module that uses alter hooks for the forms? Or does anyone know a better route?
You can simple replace drupal.js by an empty file, I think. But I actually like some of the JS stuff, but would like to maybe switch some of them off (depending on the site). How do I do that? Cheers, Gerhard
Is it just me, or am I the only one who didn't receive the original e- mail? I only got some follow-ups. I can't find the original in the archives either: http://lists.drupal.org/archives/development/2006-01/ index.html. On 02 Jan 2006, at 23:49, Gerhard Killesreiter wrote:
I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it".
-- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
Is it just me, or am I the only one who didn't receive the original e- mail? I only got some follow-ups. I can't find the original in the archives either: http://lists.drupal.org/archives/development/2006-01/ index.html.
I think it is the one berkes sent that began with "Hello there." I don't see it in the archives. Interestingly, I sent a reply to another of berkes's emails which did show up in the archives, http://lists.drupal.org/archives/development/2006-01/msg00022.html, but I never got it. -- Neil Drumm http://delocalizedham.com/
On Mon, Jan 02, 2006 at 11:04:30PM -0800, Neil Drumm wrote:
Dries Buytaert wrote:
Is it just me, or am I the only one who didn't receive the original e- mail? I only got some follow-ups. I can't find the original in the archives either: http://lists.drupal.org/archives/development/2006-01/ index.html.
I think it is the one berkes sent that began with "Hello there." I don't see it in the archives.
I got it too.
Interestingly, I sent a reply to another of berkes's emails which did show up in the archives, http://lists.drupal.org/archives/development/2006-01/msg00022.html, but I never got it.
Another quirk: some time ago I've sent an email to the list, and it just sunk somewhere. Had to resend it. Problems with ML? -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Neil Drumm wrote:
Interestingly, I sent a reply to another of berkes's emails which did show up in the archives, http://lists.drupal.org/archives/development/2006-01/msg00022.html, but I never got it.
I sent a mail to the devel-list yesterday that never appeared. -Robert
Robert Douglass wrote:
I sent a mail to the devel-list yesterday that never appeared.
Sorry for the "me too" post - but me too (except it was a couple of days ago). Seems there is a ML issue that needs investigating. andre ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
Strange indeed. I did have some mail issues over the weekend (the newyear fired backup scripts that brought the server down). Maybe that is causing all this? Ber Op dinsdag 03 januari 2006 08:04, schreef Neil Drumm:
Dries Buytaert wrote:
Is it just me, or am I the only one who didn't receive the original e- mail? I only got some follow-ups. I can't find the original in the archives either: http://lists.drupal.org/archives/development/2006-01/ index.html.
I think it is the one berkes sent that began with "Hello there." I don't see it in the archives.
Interestingly, I sent a reply to another of berkes's emails which did show up in the archives, http://lists.drupal.org/archives/development/2006-01/msg00022.html, but I never got it.
Op maandag 02 januari 2006 23:49, schreef Gerhard Killesreiter:
You can simple replace drupal.js by an empty file, I think. But I actually like some of the JS stuff, but would like to maybe switch some of them off (depending on the site). How do I do that?
Yes, sorry. This is what I meant too. I know I can do it in an all or nothing fashion. But I prefer to be able to roll out separate JS or AJAX (note that in my original mail I used Js and AJAX, not just AJAX). I have been thinking and reading code. It looks like a separate contrib module to handle (switch on and off) core and additional (prototype.js) AJAX is the route to take here. Bèr
Bèr Kessels wrote:
Op maandag 02 januari 2006 23:49, schreef Gerhard Killesreiter:
You can simple replace drupal.js by an empty file, I think. But I actually like some of the JS stuff, but would like to maybe switch some of them off (depending on the site). How do I do that?
Yes, sorry. This is what I meant too. I know I can do it in an all or nothing fashion. But I prefer to be able to roll out separate JS or AJAX (note that in my original mail I used Js and AJAX, not just AJAX).
I have been thinking and reading code. It looks like a separate contrib module to handle (switch on and off) core and additional (prototype.js) AJAX is the route to take here.
Ber I think this is a themeing issue. Whether someone likes to see some JS in one theme and no JS in another used on the site is his decision. So if you or someone else contributes a module to do it, it is logical to do per theme settings (which shows that this is a themeing issue and not something for a module). It is even possible that a theme providing an admin and a public view turns JS magic on in the admin view while turns off most of the JS magic on the end user view. So this can even differ inbetween the different views provided by a single theme. Goba
Op dinsdag 03 januari 2006 11:09, schreef Gabor Hojtsy:
Ber I think this is a themeing issue. Whether someone likes to see some JS in one theme and no JS in another used on the site is his decision. So if you or someone else contributes a module to do it, it is logical to do per theme settings (which shows that this is a themeing issue and not something for a module). It is even possible that a theme providing an admin and a public view turns JS magic on in the admin view while turns off most of the JS magic on the end user view. So this can even differ inbetween the different views provided by a single theme.
Yes. So do i think. Apparantly this is not the common idea, though. * Drupal itself has APIs for nice AJAX and DHTML stuff * Drupal itself does NOT use them. Not by default * A theme can implement autofills, resizers, CoolHoverEffects, StuffWeNeedBecauseWordpressHasIt and so on. * A theme can also not implement these and then ship with the core defaults, wich is, no AJAX DHTML stuff. This is my opinion. And though I may feel this way, there is no way i feel like turning back all the hard work done, in patches of whatevers. Not untill I know that at least a vast mayority thinks this is good. Wchih, i fear, will be never :) So as i said before, i will do all this in a prototype module. A module that removes the ajax JS from core and re-implements stuff on a themed basis. It feels a bit weird but at least its the easiest route, Another todo :) Ber
Yes. So do i think. Apparantly this is not the common idea, though.
* Drupal itself has APIs for nice AJAX and DHTML stuff * Drupal itself does NOT use them. Not by default * A theme can implement autofills, resizers, CoolHoverEffects, StuffWeNeedBecauseWordpressHasIt and so on. * A theme can also not implement these and then ship with the core defaults, wich is, no AJAX DHTML stuff.
Well, now it is the other way around. Drupal does provide these cool stuff, and a theme does have the option to disable these cool stuff. It is just that you need to write some theme code to disable this, not that it is not possible, or that it needs core patching or whatever magic. Goba
Hi, Just to further my email that I sent before. I have looked at the code, and you can disable this by not including the class resize on the testarea. What I have done for htmlarea is that to any of the text area fields that I am converting, I have added #resizable = false which then turns this feature for this textarea. The same thing may want to be done for tinymce. BTW, has tinymce been updated for 4.7? Gordon. On Mon, 2006-01-02 at 22:24 +0100, Bèr Kessels wrote:
Hello there.
I do not mean this mail as a rant. So if it sounds like that, just reread this first sentence :)
Steven has made really cool ajaxy stuff, and javascript features for Drupal. His last addition for Drupal was a cool form-field resizer.
but ehh. I *personally* don't want it. My client got (a little) angry because it broke his (development) site; its due to a theme/CSS issue, but still. I have to bill him for a fixing a feature he never asked for. Also, I certainly don't want it on none-admin areas like the feedback form. That is again, a personal decision. But I think end-users (those filling in their address in a feeback for, for example) should not get all that JS shazam, but a properly pre-sized textfield.
I have, personally filed the term AJAX next to Flash and DHTML. Under usefull, but too often misused and overhyped. Too often it is used just because "everyone does it". Used for the sake of using it. Not that I am saying Drupal is going that way, but we must certainly be aware of it. And certainly start sticking dubious JS stuff in contrib (or even core) modules.
Anyway. the form resizer broke on my theme. It broke my quicktags and it broke one version+theme of tinyMCE. All of wich I think are not bugs in core but in my theme, module and that version of mce with the specific theme. I was told before to make a patch to switch off the JS globally. But IMO that is not the correct route. Switching on and off development stuff on a user interface is not a good option, IMO.
So, anyone here who knows how I can not have js in Drupal? Do I really need to develop a no_js.module that uses alter hooks for the forms? Or does anyone know a better route?
Sorry to start about RoR again. But RoR is amoungst the forefighters of AJAX. It offers a lot of ajax apis in "core". Yet it is up to the developer to implement it or not. I think that this might be a route worth looking at: provide modules, and apis to use in themes and modules for AJAX stuff. Instead of deploying it by default. Though that is for a future, not for now. :)
Now I just want to know if there's an easy way of switching off AJAX and JS stuff so that i can fix up themes and modules that break. then slowly deploy it where i like to deploy it ;)
Bèr
!DSPAM:1000,43b9a274136512601091748!
Hello, Gordon, I'm currently using the cvs version of tinymce with a 4.7 beta 2 test site, and have not encountered any issues. Cheers, Bill ------- Bill Fitzgerald FunnyMonkey -- Tools for Teachers http://www.funnymonkey.com Gordon Heydon wrote:
BTW, has tinymce been updated for 4.7?
Op dinsdag 03 januari 2006 06:16, schreef Bill Fitzgerald:
I'm currently using the cvs version of tinymce with a 4.7 beta 2 test site, and have not encountered any issues.
My TinyMCE issues were due to me hacking it trough the theme. All the problems outlined were due to my own doings. There is nothing wrong with the Javascripts in core! It is just that i would like to keep the power not to use it for whatever reasons i see fit. :) (one of these reasons could be that I have code that breaks on the core JS) Ber
Hi, On Tue, 2006-01-03 at 10:42 +0100, Bèr Kessels wrote:
Op dinsdag 03 januari 2006 06:16, schreef Bill Fitzgerald:
I'm currently using the cvs version of tinymce with a 4.7 beta 2 test site, and have not encountered any issues.
My TinyMCE issues were due to me hacking it trough the theme.
All the problems outlined were due to my own doings. There is nothing wrong with the Javascripts in core! It is just that i would like to keep the power not to use it for whatever reasons i see fit. :) (one of these reasons could be that I have code that breaks on the core JS)
I see how it is added, tinymce uses hook_elements() instead of hook_form_alter like htmlarea. I may actually change to use this method, it look nicer. Gordon.
On 1/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
I see how it is added, tinymce uses hook_elements() instead of hook_form_alter like htmlarea.
I may actually change to use this method, it look nicer.
Gordon, Yeah I'm the one that upgraded TinyMCE to 4.7 and have been keeping up ever since. I did prefer the hook_elements() instead of form_alter(), seemed quite cleaner and I worked with Karoly to fix a couple bugs with #suffix overrides in that arena. Made that #resizable issue a cinch too. Cheers! ted (m3avrck)
Hi, On Tue, 2006-01-03 at 13:18 -0500, Theodore Serbinski wrote:
On 1/3/06, Gordon Heydon <gordon@heydon.com.au> wrote:
I see how it is added, tinymce uses hook_elements() instead of hook_form_alter like htmlarea.
I may actually change to use this method, it look nicer.
Gordon,
Yeah I'm the one that upgraded TinyMCE to 4.7 and have been keeping up ever since. I did prefer the hook_elements() instead of form_alter(), seemed quite cleaner and I worked with Karoly to fix a couple bugs with #suffix overrides in that arena. Made that #resizable issue a cinch too.
I am going to take a look at it, maybe I will change, but I think that I can't because I need to also alter any collapsible fieldsets that are collapsed so that they are open. It does look like a nice interface. Gordon.
On Jan 2, 2006, at 6:36 PM, Gordon Heydon wrote:
What I have done for htmlarea is that to any of the text area fields that I am converting, I have added #resizable = false which then turns this feature for this textarea.
The same thing may want to be done for tinymce.
BTW, has tinymce been updated for 4.7?
TinyMce is ready to go on both accounts. Thanks for the heads up though :-) Matt Westgate - http://www.lullabot.com/
On 03/01/06, Bèr Kessels <ber@webschuur.com> wrote:
but ehh. I *personally* don't want it. My client got (a little) angry because it broke his (development) site; its due to a theme/CSS issue, but still. I have to bill him for a fixing a feature he never asked for. Also, I certainly don't want it on none-admin areas like the feedback form. That is again, a personal decision. But I think end-users (those filling in their address in a feeback for, for example) should not get all that JS shazam, but a properly pre-sized textfield.
I would also prefer to have all this JS magick as optional. When I first encountered the resizable textarea, it was broken (in FF 1.5 on Linux), and I was seeing two draggable bars. This was apparently a caching issue as it magically fixed itself the next time I encountered it. But I a) don't really need it and b) if I do need it, I would like to decide for myself.. Similarly, with the autocomplete functionality, I would personally prefer to see it being triggered only after a minimum of 3 characters have been typed. I would also like to decide for myself whether my user fields and search boxes should have autocomplete enabled or not. All that said, I really do think that all these additions are very neat and my thanks to the developers behind it. But I would like to have complete control over it :) And I also realise that all these myriad options are going to clutter things up. Perhaps Drupal can have the equivalent of Firefox's "about:config" page - a be all and end all of options pages. All seldom used options can be stuck in here in a semi-organised layout. While we are on the issue of JS, I really think that all the node/trackback etc. management forms can use some JS goodness in the form of "Check all"/"Select Inverse" and related options. These forms can become quite unusable when trying to manage large amounts of data, and this will ease the pain somewhat while for e.g., trying to sift through 30 pages of spammed trackbacks.. And greater control over which fieldsets are open/closed (by default) would also be excellent. But, I digress, and this email is turning into a wishlist :/ Thanks for reading this far ;) -K
participants (13)
-
andre -
Bill Fitzgerald -
Bèr Kessels -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
Gordon Heydon -
Karthik -
Matt Westgate -
Neil Drumm -
piotr＠mallorn.ii.uj.edu.pl -
Robert Douglass -
Theodore Serbinski