- Development - lists.drupal.org

[drupal-devel] Search.module and minimum version of PHP
by Steven Wittens 07 Mar '05

07 Mar '05

Some of you may have noticed that the 4.6 RC announcements has some comments about php version in it. The cause is the new search.module which requires Unicode/UTF-8 support in the perl-compatible regular expressions (PCRE) library. The PHP documentation says compatibility was added to PCRE with PHP 4.1 on Unix and PHP 4.2.3 on Windows (and this is why I thought it was reasonable to use it). But it seems that the /real/ support wasn't added until PHP 4.3.3. I've done some testing with Gerhard and the UTF-8 support in the PCRE in PHP 4.3.2 (or earlier) is pretty broken as far as I can tell on both Windows and Linux The reason behind all this is that the search now supports characters in the entire Unicode range when it splits up text into words. This is in fact important for every language, as more and more 'high' unicode characters are used every day (anything outside ISO-8859-1/Latin-1, e.g; smart/curly quotes, euro sign, math symbols, and any language that does not use the accented latin script). In theory we could convert the character-based regular expression into a byte-based one, but this would require an insane amount of coding to do the conversion programmatically. The result would be a truly monstrous regular expression, so I really don't see it happening in practice. Or we could write our own UTF-8 compatible tokenizer, but again this would be a large piece of code that is slow to boot. An alternative is to ignore high unicode characters in the searching. This means that sites with western-european content will still be indexed in a somewhat working fashion (just behave badly around curly quotes and euro signs), but any other language will be broken. It is certainly not something we can implement in Drupal core, but I can make a patch which does this for those that are stuck on an old PHP install. Or we could just say "search.module and thus Drupal requires PHP 4.3.3". What do you guys think about it? Steven

6 7

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by jbond 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: jbond Status: patch I wonder if there's a compromise in here. The trick is to get hook_textarea('pre') to get new attributes[] back into form_textarea so they can be merged in. - Global $attributes //Yuk! - return array($html, $attributes); //Will break existing uses. Yuk again! Others? Secondly, my efforts to set event handlers in javascript are not working in IE6. I need to end up with onClick = "setCaret(this)" in the textarea definition. ta.addEventListener('select', storeCaret(this), false); doesn't seem to work. neither does ta.onclick = setCaret(this); jbond Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 09:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 10:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 09:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 10:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 12:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 12:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. ------------------------------------------------------------------------ March 6, 2005 - 12:32 : chx -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM. ------------------------------------------------------------------------ March 6, 2005 - 12:59 : gordon When the textarea hook was first implemented it was only used in the post. But using the pre for functions other then javascript wil allow you to place html above the title, which maybe wanted, depending on the use. Javascript is the primary use, but I think there is other things that use it. As for debugging javascript, this is made extremely easy, actually easier than php by itself with the use of firefox/mozilla and venkman [1] the javascript debugger. [1] http://www.mozilla.org/projects/venkman/ ------------------------------------------------------------------------ March 6, 2005 - 13:31 : Bèr Kessels I meant "Post title" INSTEAD of pre. So: hook_textare('pre'): TITLE ------------------------------------------------------------------------ March 6, 2005 - 13:32 : Bèr Kessels hrm, my cool ascii art example got lost. :( Hoever: i meant that we should change the behavious of form pre, to be rendered after the TITLE. and *not* to introduce a third form hook. ------------------------------------------------------------------------ March 6, 2005 - 16:49 : tangent See my patch in this issue [2] for an example of how to add event handlers. [2] http://drupal.org//node/16204

1 0

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by gordon 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: gordon Status: patch -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. gordon Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 19:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 20:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings.

3 5

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by tangent 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: tangent Status: patch See my patch in this issue [1] for an example of how to add event handlers. [1] http://drupal.org//node/16204 tangent Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 04:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 05:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 04:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 05:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 07:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 07:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. ------------------------------------------------------------------------ March 6, 2005 - 07:32 : chx -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM. ------------------------------------------------------------------------ March 6, 2005 - 07:59 : gordon When the textarea hook was first implemented it was only used in the post. But using the pre for functions other then javascript wil allow you to place html above the title, which maybe wanted, depending on the use. Javascript is the primary use, but I think there is other things that use it. As for debugging javascript, this is made extremely easy, actually easier than php by itself with the use of firefox/mozilla and venkman [2] the javascript debugger. [2] http://www.mozilla.org/projects/venkman/ ------------------------------------------------------------------------ March 6, 2005 - 08:31 : Bèr Kessels I meant "Post title" INSTEAD of pre. So: hook_textare('pre'): TITLE ------------------------------------------------------------------------ March 6, 2005 - 08:32 : Bèr Kessels hrm, my cool ascii art example got lost. :( Hoever: i meant that we should change the behavious of form pre, to be rendered after the TITLE. and *not* to introduce a third form hook.

1 0

Re: [drupal-devel] A Folksonomy module
by Boris Mann 06 Mar '05

06 Mar '05

On Sun, 6 Mar 2005 08:39:30 +0000, Julian Bond <julian_bond(a)voidstar.com> wrote: > I've been thinking a lot and writing code to experiment with a > Folksonomy module. > The Taxonomy on the fly module really isn't the same. The key bit of > del.icio.us style tagging is the free form entry of multiple keywords. > There should be no onus on the user to force them to select from a list > and create new entries in the list if one's missing. It should just > happen. AFAIK, you've got it a bit wrong. The user doesn't *have* to select from a list, although the existing taxonomy terms are displayed. Anything the user enters is checked against existing terms (there is an option whether to be case sensitive or not) -- so, by suppressing the display of the term list, isn't this much like a folksonomy? But, one of the biggies that I have seen come up is personal vs. global tags. I don't see it as much of an issue, or rather, it just means that the user is a filter on the existing terms in some UI displays. There is also the awtags.module --> http://www.autowitch.org. I haven't looked at this at all. -- Boris Mann http://www.bryght.com

3 2

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by Bèr Kessels 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: Bèr Kessels Status: patch hrm, my cool ascii art example got lost. :( Hoever: i meant that we should change the behavious of form pre, to be rendered after the TITLE. and *not* to introduce a third form hook. Bèr Kessels Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 10:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 11:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 10:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 11:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 13:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 13:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. ------------------------------------------------------------------------ March 6, 2005 - 13:32 : chx -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM. ------------------------------------------------------------------------ March 6, 2005 - 13:59 : gordon When the textarea hook was first implemented it was only used in the post. But using the pre for functions other then javascript wil allow you to place html above the title, which maybe wanted, depending on the use. Javascript is the primary use, but I think there is other things that use it. As for debugging javascript, this is made extremely easy, actually easier than php by itself with the use of firefox/mozilla and venkman [1] the javascript debugger. [1] http://www.mozilla.org/projects/venkman/ ------------------------------------------------------------------------ March 6, 2005 - 14:31 : Bèr Kessels I meant "Post title" INSTEAD of pre. So: hook_textare('pre'): TITLE

1 0

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by Bèr Kessels 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: Bèr Kessels Status: patch I meant "Post title" INSTEAD of pre. So: hook_textare('pre'): TITLE Bèr Kessels Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 10:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 11:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 10:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 11:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 13:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 13:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. ------------------------------------------------------------------------ March 6, 2005 - 13:32 : chx -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM. ------------------------------------------------------------------------ March 6, 2005 - 13:59 : gordon When the textarea hook was first implemented it was only used in the post. But using the pre for functions other then javascript wil allow you to place html above the title, which maybe wanted, depending on the use. Javascript is the primary use, but I think there is other things that use it. As for debugging javascript, this is made extremely easy, actually easier than php by itself with the use of firefox/mozilla and venkman [1] the javascript debugger. [1] http://www.mozilla.org/projects/venkman/

1 0

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by gordon 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: gordon Status: patch When the textarea hook was first implemented it was only used in the post. But using the pre for functions other then javascript wil allow you to place html above the title, which maybe wanted, depending on the use. Javascript is the primary use, but I think there is other things that use it. As for debugging javascript, this is made extremely easy, actually easier than php by itself with the use of firefox/mozilla and venkman [1] the javascript debugger. [1] http://www.mozilla.org/projects/venkman/ gordon Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 19:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 20:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 19:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 20:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 22:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 22:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. ------------------------------------------------------------------------ March 6, 2005 - 22:32 : chx -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM.

1 0

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by chx 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: chx Status: patch -1 the way JS should be that you insert an onload handler and there is no other trace of JS in your code. use DOM. chx Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 10:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 11:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 10:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 11:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 13:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area! ------------------------------------------------------------------------ March 6, 2005 - 13:23 : jbond I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me.

1 0

[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.
by jbond 06 Mar '05

06 Mar '05

Issue status update for http://drupal.org/node/18417 Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jbond Updated by: jbond Status: patch I'd agree with you, perhaps, about the attributes tag. I don't think I agree about "post-title". I think it's highly likely that a module would use "pre" or "post- title" but not both. And since these are all in memory hooks I hardly see that calling 4 module hooks instead of 2 is going to make any performance difference at all, at all. Following your logic there's no need for "pre" either, because you can implement that in javascript from "post". Better and cleaner? I find php a hell of a lot easier to code and debug in than Javascript. But then that's just me. jbond Previous comments: ------------------------------------------------------------------------ March 5, 2005 - 09:54 : jbond Attachment: http://drupal.org/files/issues/common.inc_8.patch (1.83 KB) This patch is for common.inc function form_textarea(). It adds two additional hooks for module writers. 1) A new hook "post-title" which works the same as "pre" and "post" but allows html to be inserted between the title of the element and the textarea. This makes it easier to insert a row of buttons (say) that sit just on top of the textarea. 2) A new hook "attributes" which takes an array() from modules that provide it and merges it into the $attributes array for the textarea. Wysywig editors typically need to add javascript handlers for things like onClick and this provides a simple way for the module to add them. ------------------------------------------------------------------------ March 5, 2005 - 10:00 : jbond Attachment: http://drupal.org/files/issues/common.inc_9.patch (1.83 KB) Apologies. the first patch had ms win line endings. This one should be unix line endings. ------------------------------------------------------------------------ March 6, 2005 - 09:17 : gordon -1 I do not think that these 2 additional hooks are needed. This will really add alot of additional overhead as it is going to call every textarea hook 4 times for every textarea on a page. Besides these modifiaction can be handled better and cleaner in the javascript. If you take a look at Xinha/HTMLArea or FckEditor they both manipulate the dom once the page has loaded, and not during. This is a much better and cleaner method as it means that you can attach to any textarea with only a few commands. This is what javascript excels at. So I don't think this is needed. ------------------------------------------------------------------------ March 6, 2005 - 10:03 : Dries I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary. ------------------------------------------------------------------------ March 6, 2005 - 12:04 : Bèr Kessels -1 from me too. More hookss are unnecasary. What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area!

1 0