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.

CommentFileSizeAuthor
#1 common.inc_9.patch1.83 KBjbond
common.inc_8.patch1.83 KBjbond

Comments

jbond’s picture

jbond commented
StatusFileSize
new common.inc_9.patch1.83 KB

Apologies. the first patch had ms win line endings. This one should be unix line endings.

gordon’s picture

gordon commented

-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.

dries’s picture

dries commented

I was about to suggest the same as Gordon. IMO, these hooks aren't really necessary.

Bèr Kessels’s picture

Bèr Kessels commented

-1 from me too. More hookss are unnecasary.
What *is* neccesary, thoiugh, is to mve the "pre" to inbetween the title and the area!

jbond’s picture

jbond commented

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.

chx’s picture

chx commented

-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.

gordon’s picture

gordon commented

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 the javascript debugger.

Bèr Kessels’s picture

Bèr Kessels commented

I meant "Post title" INSTEAD of pre. So:

hook_textare('pre'):

TITLE
<-- Here goes the hook_textare('pre'): output
+------------------------------+
| |
| |
| |
+------------------------------+

Bèr Kessels’s picture

Bèr Kessels commented

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.

tangent’s picture

tangent commented

See my patch in this issue for an example of how to add event handlers.

jbond’s picture

jbond commented

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

Steven’s picture

Steven commented

When specifying event handlers, you need to either specify function names, or strings which are pieces of code:

ta.onclick = "setCaret(this)";
or
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.

jbond’s picture

jbond commented

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.

killes@www.drop.org’s picture

killes@www.drop.org commented

remaining issue dealt with in:
http://drupal.org/node/18828