ft_load_module_field

This wonderful little function is the module counterpart to the ft_load_field function, found in the core code. It was written to get around having to perpetually pass information via POST and GET, without having to explicitly update sessions on each page. It's basically a simple storage mechanism for information that's only updated IF the information is explicitly passed to the page via GET or POST.

It assumes that a variable name can (or MAY) be found in GET, POST or SESSIONS (or all three). It then return the value stored in the most important variable (GET first, POST second, SESSIONS third), and store the value in sessions at the same time.

The way it works is very simple. It's called like so:

The four parameters are: your module folder, the key with which to later extract this information from sessions, the key of the variable that can be found in GET, POST or SESSIONS, and the default value.

Clear as mud? How about an example.

Imagine the following line is in your PHP.

When a visitor first goes to the page, after this line has executed, $field_id (since it's not in sessions and not being passed via POST or GET) has the default value assigned to it: [NONE!].

After this has been called the first time, the function has created a memory location for it in sessions - and it's automatically namespaced for your individual module, so you don't have to worry about it overwriting any values used in the core script or other modules. So if you click refresh on your page, $field_id will still have a value [NONE!] but it will have ignored the fourth parameter - it will have pulled that value from sessions.

Now, imagine you append ?field_id=100 to the page URL and click enter. On the page refresh, the function will overwrite the old [NONE!] value with 100 and return the new value. $field_id now has a value of 100.

Next, delete the ?field_id=100 from the URL and reload the page. At this point, $field_id will STILL have a value of 100 even though it hasn't been passed in explicitly. The function knows to only update the storage if it's passed via GET or POST.

The same thing works for POSTing the field_id to the page. And what if the field ID is both POSTed to the page and supplied in the query string? Well, in that case it relies on the hierarchy: GET is most important and overrides POST and SESSIONS, POST is second most important and overrides SESSIONS and lastly, if there's nothing in SESSIONS, it'll use the default value.

Good grief. How can this possibly be useful?!

You'd be surprised! It's a very clean way to store simple information like IDs in your pages without having to keep passing the information to and fro by appending to links. It's used throughout Form Tools and it saves hundreds of lines of duplicate code!