Suggestion - Improving client side definitions

businessdad

I was going through the code today to find out where a client side variable was defined, and I stumbled upon the Controller::AddDefinition() method. I noticed that each definition is rendered as a hidden input element, and retrieved by JavaScript gdn class. I was wondering if it would make sense to refactor that part so that it doesn't output html elements, but JavaScript definitions. That could be achieved with a php file that produces a JavaScript output.

For example, let's suppose to have a file called definitions.php, containing the following:

// Ensure that Garden "namespace" exists
var gdn = gdn || {};
// Add Definitions object
gdn.Definitions = {};

    <?php
    $Definitions = array(
        'MyDefinition' => 'SomeValue',
        'MyOtherDefinition' => 'SomeOtherValue',
    );

    foreach($Definitions as $ID => $Value) {
        echo "gdn.Definitions." . $ID . " = '" . $Value . "';\n";
    }
?>

Such file could be linked using <script src="//myforum.com/definitions.php"></script> and it would automatically "attach" the definitions to the global gdn object. Such object would then have to simply return the definitions by looking through its own properties.

The above example is very rough, but it should give an idea of the potential. By using a class to handle definitions, it would also be possible to pass entire objects to JavaScript, using JSON, without having to encode them.

x00

For the broadest compatibility and availability, I'd say no. I think the current solution is better.

definitions.php don't automatically take into consideration the context you are in, it also an extra request, which you will need to ensure doesn't get ached.

It was actually my contribution to made it hidden inputs. it was regionally a ul hidden by css which was not satisfactory, for text readers, et al.

You could make the encoding an decoding easier, but tit is no biggie really it is not exactly hard. I suggest having a set way of doing it, so you can have all your definitions how you want.

You could add an inline script, but I don't see this as more elegant.

At the end of the day this is something that has worked, and worked well.

businessdad

I absolutely agree that current system works (I didn't mean to imply otherwise), I was just thinking if it could be improved by completely separating any JS related stuff from the HTML.

The example I posted doesn't display the final implementation. The definitions would be set with the usual $Sender->AddDefintion(), thus keeping existing logic, with context and everything. The difference would be that, instead of having definitions rendered as hidden inputs, they would be JS variables.

The additional request doesn't look like a big deal to me in terms of performance, but I just realised that the JS file with the definitions could not (and should not) be cached. If it got cached accidentally, it could cause problems, since definitions can change with each request. I didn't think about it, that would definitely complicate the implementation.