Plugin Development: AJAX form without PAGES_WITH_OBJECTS

[imt_fog]

Hi everyone,

for our new local plugin, I am using a single page without PAGES_WITH_OBJECTS, as we have several different database entities to manage on that one page. I had to look deeply into sources but got it almost up and running.

I noted that there is some hook (I think in the fog.js part) to get “normal POST forms” to work as AJAX forms and it seems to be related to action boxes and PAGES_WITH_OBJECTS.

This brings me to my quick question: how can I use AJAX forms on a more generic page?

Thanks and BR
Martin

[Tom Elliott]

You can use the examples of how we use Ajax and what calls/forms they use to generate your own Ajax based script. I think this would do what you want/need and still allow you to use the hook for the tie in.

[imt_fog]

@Tom-Elliott That’s what I tried the last two days, I am literally “poking in the FOG” sources I more or less got the backend part with FOGPage, FOGBase, FOGController and most of the reflections used, but the JS frontend is a bit mysterious from time to time…

Lets e.g. use this form as an example:
https://github.com/FOGProject/fogproject/blob/348f695c3def03050877c4919e2041f2cf91b965/packages/web/lib/pages/storagemanagementpage.class.php#L1316

What does it make to use AJAX? There is some jQuery magic going on to prevent the default submit event, that’s pretty clear. Unfortunately, it is hard to find out why this is happening. Right now I am assuming setupTimeoutElement() is setting the submithandlerfunc to intercept the form submit, and then one is doing the AJAX stuff?

I’ll give it a try on my dev machine tonight…

[Tom Elliott]

It’s been a while since I wrote that code and I’ve been working hard on trying to get 1.6 to a more functional state (which I believe it’s mostly there now.)

Of note, while you can tie into the common ajax code sitting within for setupTimeoutElement and submithandlerfunc, the common thing to be noted is that you can have your JS code do whatever you need. Those methods are available, but there’s no 100% dedication to using it. Use it where you can, but it’s not a requirement.

The js code get’s loaded automagically in 1.5 via node and sub in the get request.

So let’s say you wanted js code to alter the list page for some reason. Your plugin node code would be say exampleplugin. You would simply need a file named: fog.exampleplugin.list.js (file names are always: fog.<node>.<sub>.js)

Hopefully this makes sense.

So in keeping with that file scheme, common files I can think of for a plugin named exampleplugin would be:

fog.exampleplugin.js //base js for all exampleplugin node items.
fog.exampleplugin.list.js //exampleplugin's list page.
fog.exampleplugin.add.js //exampleplugin's create/add item page.
fog.exampleplugin.edit.js //exampleplugin's edit item page.

While I’m sure this doesn’t answer any of your questions, it should help with getting something functional.

You can use other plugin’s to help in the understanding of the js files too. A common one I like to use that interacts with both groups and hosts is the location plugin. This should give a pretty good understanding of what to do, and how to do it. If you still have questions please ask and try to be detailed in exactly what you’re looking for.