I can upload a file to web server without user interaction? i mean, no dialog asking the user the file for upload!
i'm using an application made in flash that generates a screenshot of the result of some interface, and I need upload this screenshot to the webserver!
it's that possible ??
Not enough information here. Where does your flash application live? Is it on another server than Drupal? On the desktop? Or on the same server? Is it being served from within Drupal? or is it a separate application? How do you want the file uploaded? Does it need to be attached to a node, or otherwise processed using the drupal api? Or does it simply need to get dumped into a server directory?
In general, your best option for interfacing a flash application with the drupal api is via a webservice (xmlrpc, soap). You can have your flash application authenticate to the drupal webservice and have it access exposed methods to upload your file. If you need to create a node with the file attached, you could pull that off, too.
Depending on what you want to do, you may need to write a module or extend an existing one to implement the necessary services hooks.
On 11/01/2010 11:31 AM, Aldo Martinez Selleras wrote:
I can upload a file to web server without user interaction? i mean, no dialog asking the user the file for upload!
i'm using an application made in flash that generates a screenshot of the result of some interface, and I need upload this screenshot to the webserver!
it's that possible ??
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 ...
On 11/01/2010 11:31 AM, Aldo Martinez Selleras wrote:
I can upload a file to web server without user interaction? i mean, no dialog asking the user the file for upload!
i'm using an application made in flash that generates a screenshot of the result of some interface, and I need upload this screenshot to the webserver!
it's that possible ??
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.
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.
Le mardi 02 novembre 2010 à 15:59 -0400, Christopher M. Jones a écrit :
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.
Good, it seems that you have your answers then. Don't forget, if you manually have to do AHAH in your forms, take a look at the ahah_helper module, which works great, and will help you avoid writing hundreds of code lines only for Form API in AHAH handling.
Pierre.
-
Aldo Martinez Selleras -
Christopher M. Jones -
Pierre Rineau