Skip to main content
Topic: Separate "Sources" and "Themes" in js too? (Read 12335 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Separate "Sources" and "Themes" in js too?

The new year is having some strange effect on me... ::)

In php we have "Sources" and "Themes". What about having something similar in javascript too?

At the moment several js files have pieces of html around in a more or less random order.
Wouldn't be nice to move all of them into the "theme.js" file in form of functions, so that if someone wants to change something doesn't have to sort of guess where the piece of code he is looking for is?

Something similar to what Sam Clarke did with the latest version of the editor.

Of course I don't mean to have a "sources" and a "themes" directory for javascript, just "some" files corresponding to "sources" and one file that does the "theming".
Bugs creator.
Features destroyer.
Template killer.

Re: Separate "Sources" and "Themes" in js too?

Reply #1

Why would it be nice? Wouldn't it be better to have as few files as possible and cut the number of http requests? That doesn't matter in the case of templates, etc but it is a consideration for any files which have to be downlaoded and cached. Splitting them up, unless absolutely necessary, doesn't seem like a good idea to me.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Separate "Sources" and "Themes" in js too?

Reply #2

Spuds has made a "combiner" class which combines and minimizes the css and javascript files sent to the browser: only sends the "combination". So the number of files we work with, during development, doesn't matter for what is sent over in the end.
(unless the user desactivates that particular optimization, sure, their choice).
Last Edit: January 02, 2013, 03:11:19 pm by TestMonkey
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Separate "Sources" and "Themes" in js too?

Reply #3

Quote from: emanuele – Something similar to what Sam Clarke did with the latest version of the editor.

Of course I don't mean to have a "sources" and a "themes" directory for javascript, just "some" files corresponding to "sources" and one file that does the "theming".
Bugs creator.
Features destroyer.
Template killer.

Re: Separate "Sources" and "Themes" in js too?

Reply #4

Ok, if we're running a compiler by default then sure, split them up if it will help.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Separate "Sources" and "Themes" in js too?

Reply #5

I could see the use of moving the JS that affects layout to its own file, call it what you want, like interface.js or something.  That way its easier to find the js that hides, collapses, activates, validates, etc in a single place.

Re: Separate "Sources" and "Themes" in js too?

Reply #6

Quote from: Spuds – I could see the use of moving the JS that affects layout to its own file, call it what you want, like interface.js or something.  That way its easier to find the js that hides, collapses, activates, validates, etc in a single place.

 IchBin Like this idea the best.

Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Separate "Sources" and "Themes" in js too?

Reply #7

I like the idea of splitting things up. One of the things I did with PureChat was have two separate javascript objects, one for business logic, and the other for template interaction only. The business logic would handle all of the ajax requests, utility functions, and define variables. So you might have files like this:

utilities.js (helper functions)
main.js (a global object holding important variables)
display.js (information and helper methods for display.template.php)
display.ui.js (user interface interaction object)

Some sample code for display.js and display.ui.js
Code: [Select]
// display.js
var DisplayObject = function()
{
    this.quickReply = function(userName, message)
    {
        message = displayObject.validateMessage(message);
       
        $.ajax({
            url: '';
            data: {userName, message},
            type: 'POST',
            success: function(response)
            {
                if (response.success === 'true') {
                    displayUI.showPost(response.data);
                }
            }
        });
    }

    this.validateMessage = function(text)
    {
        // process text.
    }
}
var displayObject = new DisplayObject; // Create and instance of the "class".;

Code: [Select]
// display.ui.js
var DisplayUI = function()
{
    this.showPost = function(postData)
    {
        var html =
            '<div class="post no_display">' +
                '<div class="message">' +
                    postData.text +
                '</div>' +
                '<div class="userData">' +
                    '<ul>' +
                        '<li>' + postData.name + '</li>';

        $.each(postData.posterInfo, function(index, data)
        {
            html .=
                        '<li>' + data + '</li>';
        });

        html .=
                    '</ul>' +
                '</div>' +
            '</div>';

        $('.no_display').slideDown(250, function()
        {
            $(this).removeClass('no_display');
        });
    }
}
var displayUI = new DisplayUI;

Personally, I find that a lot easier to debug and modify, because the working code isn't all mixed in with the template interaction. Just my opinion. :)
~((0040 + 0x20) + (0b111 << 1))
"You never said something, for me, to penny mention work a barbecue pit." ~ Gilligan

Re: Separate "Sources" and "Themes" in js too?

Reply #8

I am a bit worried that you guys are so far into your architecture that you'll end up creating an inpenetrable maze for others.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Separate "Sources" and "Themes" in js too?

Reply #9

I could see that happening if things got super polymorphic or something with a zillion different interlocked objects, but if anything I'd say splitting this up makes it easier. Especially if the files and methods are named well, being descriptive of their purpose. Plus then your theme authors know exactly where to go to find some display code, rather than digging around in a few really huge files.
~((0040 + 0x20) + (0b111 << 1))
"You never said something, for me, to penny mention work a barbecue pit." ~ Gilligan

Re: Separate "Sources" and "Themes" in js too?

Reply #10

Don't forget that you cannot always entirely avoid inline code in the template for very specific cases.

Re: Separate "Sources" and "Themes" in js too?

Reply #11

True, but I would think those cases are few and far between. At least they should be.
~((0040 + 0x20) + (0b111 << 1))
"You never said something, for me, to penny mention work a barbecue pit." ~ Gilligan

Re: Separate "Sources" and "Themes" in js too?

Reply #12

You'd think so, but they're really not. Don't forget how big the codebase really is.

Re: Separate "Sources" and "Themes" in js too?

Reply #13

What, exactly, do you mean by inline code? Event handlers are obviously tied to the markup, but what else?

Edit: I don't mean inline stuff like onclick="someFunction();" Those are evil to the core.
~((0040 + 0x20) + (0b111 << 1))
"You never said something, for me, to penny mention work a barbecue pit." ~ Gilligan

Re: Separate "Sources" and "Themes" in js too?

Reply #14

I mean where you have templates actually outputting markup that's specific to the page. For example, the auto suggest component - it loads suggest.js, but then there's code in the main template to initialise the suggester instance with options specific to the page on which it is being called.

Same goes for all instances of the bbc editor.