[support] Writing ahah callbacks to a

Christopher M. Jones cjones at partialflow.com
Tue Nov 2 19:59:06 UTC 2010


On 11/02/2010 02:52 PM, Pierre Rineau wrote:
> On Tue, 2010-11-02 at 14:33 -0400, Christopher M. Jones wrote:
>> I have a custom cck widget. I want part of that widget to open in a
>> modal window (modalframe api), which uses an iframe. I have a function
>> that encapsulates the portion of the form array in question. There are
>> ahah elements througout the form, including in the portion that opens in
>> the modal frame.
>>
>> I want the use of the frame to be optional. So, in case the user has
>> elected to use the frame, I want to render a button in the widget that
>> activates the frame, rendering the rest of the form. But I need ahah
>> actions in the frame to effect changes in the parent. So, when the ahah
>> callback returns a new element, I need that element to be passed back to
>> the parent.
>>
>> I'm stuck here. I'm new to CCK widgets and new to ahah. I've read so
>> much that my head is spinning. I'd love it if someone could outline for
>> me the best method for accomplishing this.
>>
>> Here's some brain vomit, for anyone who cares to read further:
>>
>> Should the ahah responses be stored somewhere within the child document,
>> to be dumped into the parent when the window is closed?
>>
>> I'd rather have changes to the parent be incremental, so that the parent
>> page is already updated by the time the user thinks to close the window.
>> But I'll settle for anything, at this point.
>>
>> Or, since the form cache is being updated by the ahah callback, then
>> couldn't one re-render the whole form when the window is closed?
>>
>> Is there a way to rebind ahah in the child window to ahah in the parent?
>> Pass contexts around?
>>
>> ... and so forth ...
>
> I did some tricky stuff, a long time ago. I did put AHAH stuff on a
> whole form (or the most top level element I could put it), but instead
> of puting it on a known event (such as 'click' or 'change'), I put it on
> a custom event, which does not exists, such as 'my_magnificient_event'.
>
> The good thing about this, is then, when your user closes the window,
> you can trigger manually the "non existing event" using jQuery, such as
> $("#myform .the_element_where_I_did_put_the_ahah_event").trigger("my_magnificient_event"); and hop, you win!
>
> For the incremental stuff, it may be more difficult. Think about one
> thing, which is quite annoying, when you open a modal, most APIs will
> append the real DOM element representing the dialog at the body's
> bottom, so it won't be within the form, so submitting the form won't
> submit the values that are in the dialog. If you experience such
> problem, you may have to implement your own modal by writing some JS (it
> looks like much more complicated that it is really). Then, you can do
> whatever you want even embed you form parts within the dialog without
> worrying about this.
>
> Pierre.
>
Pierre, thanks. I like the custom event. I didn't know I could do that. 
I think the incremental stuff is a chimera, anyway. As content.module 
explains (in the comments on the add more-related functions) tabledrag 
won't let us simply add a row to the widget. So content.module rewrites 
and reattaches the whole widget every time an element is added. Might as 
well do that once, rather than over and over. So, I guess what I can do 
is use the close event handler provided by modalframe to post to a 
callback and write the response to the parent window, which I  know how 
to access from there. The ahah events in the modal-contained form will 
already have updated the form cache. So all I need to do at close time 
is pull the cache and rebuild the form.


More information about the support mailing list