[wp-hackers] Including javascript in the footer

[Philip Walton]

Thanks Mike, that method probably would work and does seem better than 
calling wp_print_scripts() in the footer.

The reason there are factors I can't control is because I'm talking 
about a development framework I use. In my framework the 
add_settings_page() callback loads and outputs a view file and that view 
file could contain any number of form objects and (since it's a 
framework that is reused) I don't know whether or not the form in that 
particular view file is going to require ajax validation before the form 
object or subclass is instantiated.


On 5/11/11 9:55 AM, Mike Little wrote:
> On Wed, May 11, 2011 at 17:38, Philip Walton<philip at philipwalton.com>wrote:
>
>> On 5/11/11 6:57 AM, Otto wrote:
>>
>>> I'm going to go ahead and categorically state that there is no
>>> situation where it is *necessary* to enqueue a script halfway down the
>>> page. All the normal data is loaded into memory, the main query has
>>> executed, the autoloader has occurred for options... what else do you
>>> need?
>>>
>> I can agree that it's not absolutely necessary to enqueue a script at the
>> point in the page load that I'm wanting to. But I still maintain that
>> there's nothing "wrong" about it. Putting a script in the footer is a very
>> reasonable thing to do, so as long as I'm making that decision before I
>> output the footer markup, I see nothing categorically wrong with it.
>>
>> I'm also not making the decision to include the script based on the post
>> content (maybe that was unclear). I'm doing so on a settings form form the
>> admin side.
>>
>> The add_settings_page() includes a callback to output the contents of the
>> form, and that callback is fired after the admin_enqueue_scripts hook. In
>> that callback I'm creating a form object and deciding and at that point
>> (based on factors I don't control) whether or not I need to either use a
>> script to do ajax form validation.
>>
>> The most logical place for me to make that decision is in the
>> add_settings_page callback. Could I do it before? Yes, but in my opinion,
>> that would be doing it the "wrong" way.
>>
>> Philip
>>
>>
> I still don't see why your "factors you don't control" aren't known earlier
> in processing, but I saw a discussion recently on this list (I think it was
> about conditional tags round css) whereby the idea discussed was to always
> enqueue (a script) on the page, marked to go in the footer, and then you
> could decide to remove it from the queue during processing of the page. I
> think that may satisfy your requirement (with the caveat that dependencies
> may have already been injected)
>
>
> Mike