[drupal-devel] [feature] 2 additional hooks to form_textarea to support module writers who are extending it.

jbond drupal-devel at drupal.org
Mon Mar 7 19:00:13 UTC 2005

Issue status update for http://drupal.org/node/18417

 Project:      Drupal
 Version:      4.5.0
 Component:    base system
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  jbond
 Updated by:   jbond
 Status:       patch

Well after much faffing around, I've managed  to attach event handlers
to the textarea. Hooray! It turns out that IE6 and possibly firefox
will only do this in a body onLoad function. And the attachEvent and
addEventListener calls take a function pointer not a string so there's
no way to pass parameters in. So my handler functions needed to find
out what they were being called from.
So that gets rid of my need for one of my suggested hooks.
The second one is the same as Ber's request for hook_textarea('pre') to
be between the title and textarea. I can't see at the moment any way of
reversing these in javascript, except possibly getting the textarea,
getting it's parent, getting all the child nodes, walking down the list
and deleting, appending my toolbar.  This again seems an awful lot of
work compared with moving the hook. I'll happily submit a patch to do
this. but I won't bother if it's just going to be chucked out.
I'm tempted to say that the post hook should be between the textarea
and the $desc as well but this would break the HTMLarea module.
ps. Although I've learnt things in this process, it still seems to me
to be a bit perverse to force us to work like this. form_item has an
$attributes parameter. So does form_textarea. But there's no way for
hook_textarea to get in there and add a $attributes entry. There you
go. moan over.


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

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
Following your logic there's no need for "pre" either, because you can
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
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:


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
[2] http://drupal.org//node/16204


March 6, 2005 - 17:19 : jbond

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
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);


March 7, 2005 - 14:03 : Steven

When specifying event handlers, you need to either specify function
names, or strings which are pieces of code:
ta.onclick = "setCaret(this)";
ta.onclick = setCaret;
But not:
ta.onclick = setCaret(this);
This last piece of code will in fact execute setCaret(this) and assign
the return value to ta.onclick, which is not what you want.
JavaScript is really quite logical and a powerful language, especially
when it comes to run-time method definitions.

More information about the drupal-devel mailing list