On 7 March 2012 12:37, Si Hobbs <simon@hobbs.id.au> wrote:
> Part of my problem is not being able to define my own "delivery
> callback" in hook_menu because my form is in a block.
>
> If I cannot have my own "delivery callback", I'm struggling to work
> out how to return my own series of ajax_comment_X() in my
> ajax_callback. I can only seem to return a renderable array, or some
> static content.
>
> Si
>
>
>
> On 7 March 2012 12:26, Si Hobbs <simon@hobbs.id.au> wrote:
>> Oh yes, I'm talking about Drupal 7. I used to do all this with ctools
>> in Drupal 6.
>>
>> Yes it works if I clean up the $form_state['values']. It feels a
>> little weird but thanks heaps for that.
>>
>> Simon
>>
>>
>> On 7 March 2012 12:12, David Metzler <metzler.dl@gmail.com> wrote:
>>> Tools are substantially different for the based on drupal 6 vs. 7. Could you specify the version?
>>>
>>> Is there a reason not to simply alter $form_state['values'] as part of your submit handler? I would've done it the other way around. Imbed the thank you message in the form as a markup item, rather than trying to put it outside of the form.
>>>
>>> On Mar 6, 2012, at 4:57 PM, Si Hobbs wrote:
>>>
>>>> Hi
>>>>
>>>> I am doing an ajax callback, and I want to return a fresh version of a
>>>> form as content. This is after the form has successfully submitted.
>>>>
>>>> So instead of something like:
>>>> return 'Thanks for your submission';
>>>> Which works, I want to do:
>>>> return 'Thanks for your submission' . drupal_render(drupal_get_form('foo'));
>>>>
>>>> However when I get that that form, it is not fresh. The form system
>>>> reprocesses the form, re-runs the submit handler, and returns a form
>>>> with the $form_state['values'] all populated.
>>>>
>>>> So, I've been trying to work out how to reset the form. For example,
>>>> this sort of thing doesn't successfully clear the form:
>>>>
>>>> cache_clear_all('form_' . $form_state['values']['form_build_id'],
>>>> 'cache_form');
>>>> cache_clear_all('form_state_' .
>>>> $form_state['values']['form_build_id'], 'cache_form');
>>>> drupal_static_reset('drupal_retrieve_form');
>>>>
>>>> Thanks for any tips.
>>>>
>>>> Simon
>>>
3/6/12
Re: [development] resetting a form
Re: [development] resetting a form
callback" in hook_menu because my form is in a block.
If I cannot have my own "delivery callback", I'm struggling to work
out how to return my own series of ajax_comment_X() in my
ajax_callback. I can only seem to return a renderable array, or some
static content.
Si
On 7 March 2012 12:26, Si Hobbs <simon@hobbs.id.au> wrote:
> Oh yes, I'm talking about Drupal 7. I used to do all this with ctools
> in Drupal 6.
>
> Yes it works if I clean up the $form_state['values']. It feels a
> little weird but thanks heaps for that.
>
> Simon
>
>
> On 7 March 2012 12:12, David Metzler <metzler.dl@gmail.com> wrote:
>> Tools are substantially different for the based on drupal 6 vs. 7. Could you specify the version?
>>
>> Is there a reason not to simply alter $form_state['values'] as part of your submit handler? I would've done it the other way around. Imbed the thank you message in the form as a markup item, rather than trying to put it outside of the form.
>>
>> On Mar 6, 2012, at 4:57 PM, Si Hobbs wrote:
>>
>>> Hi
>>>
>>> I am doing an ajax callback, and I want to return a fresh version of a
>>> form as content. This is after the form has successfully submitted.
>>>
>>> So instead of something like:
>>> return 'Thanks for your submission';
>>> Which works, I want to do:
>>> return 'Thanks for your submission' . drupal_render(drupal_get_form('foo'));
>>>
>>> However when I get that that form, it is not fresh. The form system
>>> reprocesses the form, re-runs the submit handler, and returns a form
>>> with the $form_state['values'] all populated.
>>>
>>> So, I've been trying to work out how to reset the form. For example,
>>> this sort of thing doesn't successfully clear the form:
>>>
>>> cache_clear_all('form_' . $form_state['values']['form_build_id'],
>>> 'cache_form');
>>> cache_clear_all('form_state_' .
>>> $form_state['values']['form_build_id'], 'cache_form');
>>> drupal_static_reset('drupal_retrieve_form');
>>>
>>> Thanks for any tips.
>>>
>>> Simon
>>
Re: [development] resetting a form
in Drupal 6.
Yes it works if I clean up the $form_state['values']. It feels a
little weird but thanks heaps for that.
Simon
On 7 March 2012 12:12, David Metzler <metzler.dl@gmail.com> wrote:
> Tools are substantially different for the based on drupal 6 vs. 7. Could you specify the version?
>
> Is there a reason not to simply alter $form_state['values'] as part of your submit handler? I would've done it the other way around. Imbed the thank you message in the form as a markup item, rather than trying to put it outside of the form.
>
> On Mar 6, 2012, at 4:57 PM, Si Hobbs wrote:
>
>> Hi
>>
>> I am doing an ajax callback, and I want to return a fresh version of a
>> form as content. This is after the form has successfully submitted.
>>
>> So instead of something like:
>> return 'Thanks for your submission';
>> Which works, I want to do:
>> return 'Thanks for your submission' . drupal_render(drupal_get_form('foo'));
>>
>> However when I get that that form, it is not fresh. The form system
>> reprocesses the form, re-runs the submit handler, and returns a form
>> with the $form_state['values'] all populated.
>>
>> So, I've been trying to work out how to reset the form. For example,
>> this sort of thing doesn't successfully clear the form:
>>
>> cache_clear_all('form_' . $form_state['values']['form_build_id'],
>> 'cache_form');
>> cache_clear_all('form_state_' .
>> $form_state['values']['form_build_id'], 'cache_form');
>> drupal_static_reset('drupal_retrieve_form');
>>
>> Thanks for any tips.
>>
>> Simon
>
Re: [development] resetting a form
Is there a reason not to simply alter $form_state['values'] as part of your submit handler? I would've done it the other way around. Imbed the thank you message in the form as a markup item, rather than trying to put it outside of the form.
On Mar 6, 2012, at 4:57 PM, Si Hobbs wrote:
> Hi
>
> I am doing an ajax callback, and I want to return a fresh version of a
> form as content. This is after the form has successfully submitted.
>
> So instead of something like:
> return 'Thanks for your submission';
> Which works, I want to do:
> return 'Thanks for your submission' . drupal_render(drupal_get_form('foo'));
>
> However when I get that that form, it is not fresh. The form system
> reprocesses the form, re-runs the submit handler, and returns a form
> with the $form_state['values'] all populated.
>
> So, I've been trying to work out how to reset the form. For example,
> this sort of thing doesn't successfully clear the form:
>
> cache_clear_all('form_' . $form_state['values']['form_build_id'],
> 'cache_form');
> cache_clear_all('form_state_' .
> $form_state['values']['form_build_id'], 'cache_form');
> drupal_static_reset('drupal_retrieve_form');
>
> Thanks for any tips.
>
> Simon
[development] resetting a form
I am doing an ajax callback, and I want to return a fresh version of a
form as content. This is after the form has successfully submitted.
So instead of something like:
return 'Thanks for your submission';
Which works, I want to do:
return 'Thanks for your submission' . drupal_render(drupal_get_form('foo'));
However when I get that that form, it is not fresh. The form system
reprocesses the form, re-runs the submit handler, and returns a form
with the $form_state['values'] all populated.
So, I've been trying to work out how to reset the form. For example,
this sort of thing doesn't successfully clear the form:
cache_clear_all('form_' . $form_state['values']['form_build_id'],
'cache_form');
cache_clear_all('form_state_' .
$form_state['values']['form_build_id'], 'cache_form');
drupal_static_reset('drupal_retrieve_form');
Thanks for any tips.
Simon
3/5/12
Re: [development] Remove Meta Tag Generator
Hi Richard,
From: webmaster
already exists and I'm using it: http://drupal.org/project/remove_generator
You got my point: I'd like to have something in the core without
having to install workarounds
Re: [development] Remove Meta Tag Generator
> Hi Richard,
> already exists and I'm using it: http://drupal.org/project/remove_generator
> You got my point: I'd like to have something in the core without
> having to install workarounds
It isn't a work around to install or write a module that adjusts the
defaults. It is the way it works. You can also use project/metatag
to insert per node meta tags and remove or modify the generator tag.
As Richard said, "why do you even care about this?" In other words,
why do you want to hide the fact that your content is being generated
by Drupal?
--
Earnie
-- https://sites.google.com/site/earnieboyd
Re: [development] Remove Meta Tag Generator
already exists and I'm using it: http://drupal.org/project/remove_generator
You got my point: I'd like to have something in the core without
having to install workarounds
Thanks,
Domenico
2012/3/5 Richard Burford <lists@freestylesystems.co.uk>:
> You could make a small module that does this with a settings form, a conf variable, and (as described in the link you posted) using hook_html_head_alter() to unset or otherwise alter the generator element.
>
> But, it begs the question - why do you even care about this?
>
> On 5 Mar 2012, at 09:49, webmaster wrote:
>
>> Hi,
>> I noticed that by default this tag is written:
>> <meta name="Generator" content="Drupal 7 (http://drupal.org)" />
>>
>> I'm perplexed about that and I discover that someone else is sharing
>> my point of view: http://drupal.org/node/982034
>>
>> Do you think it would be possibile to add an option in the admin panel
>> to switch off this feature?
>>
>> Regards,
>> Domenico
>
[development] Remove Meta Tag Generator
I noticed that by default this tag is written:
<meta name="Generator" content="Drupal 7 (http://drupal.org)" />
I'm perplexed about that and I discover that someone else is sharing
my point of view: http://drupal.org/node/982034
Do you think it would be possibile to add an option in the admin panel
to switch off this feature?
Regards,
Domenico
3/1/12
[development] Invitation to connect on LinkedIn
| Fred Jones requested to add you as a connection on LinkedIn: Anupom,
WHY MIGHT CONNECTING WITH FRED JONES BE A GOOD IDEA? Fred Jones's connections could be useful to you After accepting Fred Jones's invitation, check Fred Jones's connections to see who else you may know and who you might want an introduction to. Building these connections can create opportunities in the future. © 2012, LinkedIn Corporation Re: [development] Node reference in core?
On Thu, Mar 1, 2012 at 12:53 PM, Daniel F. Kudwien wrote:
> Am 01.03.2012 17:19, schrieb Karl Giesing: > >> Furthermore, we also need the ability to add Track nodes as we are >> creating an Album node - that is, we need the ability to create multiple >> nodes, and their references, all from the single form used to create an >> album. What should NOT happen is that the user has to create each track >> individually before they create an album that has those tracks - this is >> a workflow nightmare. (And it's currently how Pushtape works.) >> >> There are currently three D7 modules used to create node references: >> References, Entity Reference, and Relation. References is the only one >> not currently in beta - and it's being depricated in favor of one of the >> other two. Furthermore, as far as I can tell, none of the above allow >> you to create the references unless the nodes already exist. > > > Creating 0-n other entities as part of the initial creation/form flow of a > parent entity, and handling that correctly in terms of what data to store > where and what to do in case of validation errors down the line, is the > tricky part. > How about taxonomy? You could have a term for the album and each -- Re: [development] Node reference in core?
Am 01.03.2012 17:19, schrieb Karl Giesing:
> Furthermore, we also need the ability to add Track nodes as we are > creating an Album node - that is, we need the ability to create multiple > nodes, and their references, all from the single form used to create an > album. What should NOT happen is that the user has to create each track > individually before they create an album that has those tracks - this is > a workflow nightmare. (And it's currently how Pushtape works.) > > There are currently three D7 modules used to create node references: > References, Entity Reference, and Relation. References is the only one > not currently in beta - and it's being depricated in favor of one of the > other two. Furthermore, as far as I can tell, none of the above allow > you to create the references unless the nodes already exist. Creating 0-n other entities as part of the initial creation/form flow of That's a conceptual problem. Before even thinking of moving module X or AFAICS, there are two possible ways to approach it: 1) Form-stacking or multiple form-states The parent entity creation form additionally needs to contain the This requires a proper and clean encapsulation of form structures Furthermore, the entire reference validation between the children That said, we've prepared at least Field API in Drupal 7 for this chx created http://drupal.org/project/multiform as an attempt to In any case, this approach is very complex and has a high potential
Instead of dealing with the complex problem at all, solve it in the Save the parent entity when entering the parent entity creation Apparently, a couple of other CMSs, and even more so, offline and There's merely one giant show-stopper: form validation of required I don't want to pretend that this approach would be easier, but in
Thanks, Re: [development] Node reference in core?
I havent done alot of work in relations recently but from what ive
seen and used the relations module will probably be the way to go to establish the relationship longer term but references gets thejob done today for you. You might want to consider using a ctools multistep form with an onscreen link on the "add album" edit page that links to "add a track modal/multistep" and have it return the nid that is created for relation to add it to the relation on the node youre making in the last step. I think this might be best handled as a custom multistep form that -- Re: [development] Node reference in core?
On Thu, Mar 1, 2012 at 11:19 AM, Karl Giesing <khzmusik@hotmail.com> wrote:
> > His module is track-centered, whereas mine is album-centered. In order to > have tracks and albums as separate nodes, we need to have some sort of > reference to multiple track nodes from an album node. > > Furthermore, we also need the ability to add Track nodes as we are creating > an Album node - that is, we need the ability to create multiple nodes, and > their references, all from the single form used to create an album. What > should NOT happen is that the user has to create each track individually > before they create an album that has those tracks - this is a workflow > nightmare. (And it's currently how Pushtape works.) > The first thing that came to my mind is -- [development] Node reference in core? Hello, all. This is Karl, aka Karlheinz, the developer for the Discogs module.
I'm trying to work with Zirafa, author of the Pushtape module, to come up with a centralized discography framework for Drupal. (I'm also going to see if the Spotify module wants to get on board with this.) We have, however, run into a snag. His module is track-centered, whereas mine is album-centered. In order to have tracks and albums as separate nodes, we need to have some sort of reference to multiple track nodes from an album node. Furthermore, we also need the ability to add Track nodes as we are creating an Album node - that is, we need the ability to create multiple nodes, and their references, all from the single form used to create an album. What should NOT happen is that the user has to create each track individually before they create an album that has those tracks - this is a workflow nightmare. (And it's currently how Pushtape works.) There are currently three D7 modules used to create node references: References, Entity Reference, and Relation. References is the only one not currently in beta - and it's being depricated in favor of one of the other two. Furthermore, as far as I can tell, none of the above allow you to create the references unless the nodes already exist. I had hoped that the new Fields API in D7 would have included this functionality, but alas it was not the case. (I was actually very surprised at this; frankly, I believe it should have been in Drupal since day 1. A "node" is just a piece of information, after all, and there's a reason everyone uses a "relational" database for information.) So, I'm wondering if there isn't the possibility of moving this functionality into Drupal core. If not for D7 (which seems like a lost cause), then for D8 at the very least. In the meantime, is there any one of the three aforementioned node reference modules that the folks at Drupal core think is most promising? We absolutely, positively need this functionality, and we don't want to have to change dependencies - again - due to issues with third parties. p.s. I've been reading all the posts about re-purposing this list to include module developers. We've had this conversation before, but if it's being considered again, I am all for it. The support list is ABSOLUTELY NOT useful in any way for us, and there is currently NO appropriate mailing list for module developers to use. In the meantime, I've been using the Module Development and Code Questions section of the forum, when I need to. 2/29/12drupal.org mailing list memberships reminder
This is a reminder, sent out once a month, about your drupal.org
mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or In addition to the URL interfaces, you can also use email to make such If you have questions, problems, comments, etc, send them to Passwords for gruz_@bigmir.net: List Password // URL documentation@drupal.org difiusur Re: [development] Was, write a simple field type for CCK, now module development
OMG, we're all a bunch of pedantic buffoons! We've got a mailing list called "development@drupal.org". It gets one email a week. And someone asks a question about how to properly do drupal CCK development, and we send them to another mailing list whilst arguing about whether this list should be re-tasked?
Seems to me we're killing ourselves here, unneccessarily. Look, development is development. CCK is mostly in core anyway, so where does a questions like that belong? In the contrib-development mailing list or the core-development mailing list? ;) Carry on, mate.
Re: [development] Was, write a simple field type for CCK, now moduleAgreed, as well. Given that most core discussion has moved elsewhere, I don't see the problem in repurposing this list for general module development (as opposed to support being general Drupal "how-do-I" questions). Regards, Todd On 29 February 2012 09:45, Sam Tresler <sam@treslerdesigns.com> wrote: I agree as well. There is a valid use case for a list that addresses development of modules and actual problems people encounter when developing new functionality that is separate from support. This would hopefully end the pattern, of late, of the list being dead until someone has a support question and someone else smacks it down. Re: [development] Was, write a simple field type for CCK, now module developmentI do agree in this particular case that the question would be more appropriate for the support list. But I also think there should be a development list for programming questions that aren't specific to core. Most of the questions at this level go unanswered on the support list. How many would need to agree to retasking the list before we would be able to ask webchick to make the change? Cameron
Re: [development] Was, write a simple field type for CCK, now module
I agree as well. There is a valid use case for a list that addresses
development of modules and actual problems people encounter when developing new functionality that is separate from support. This would hopefully end the pattern, of late, of the list being dead until someone has a support question and someone else smacks it down. Regards, On 02/29/2012 08:06 AM, Richard Burford wrote:
Subscribe to:
Posts (Atom)
|
