MVC - Control Module - Version 2

Question

All models are in the model namespace and follow a naming convention. This makes it easy to consolidate control into cType() as shown below.

All control passes through cTYpe() which calls the correct model. It does this by way of the type parameter which is set by the call back function for the specified event.

Calls to Model

model[type].pre()

model[type].post()

Controller and Model

var model = {};
model.user_try =
{
    pre : function()
    {
    },
    post : function( text )
    {
    }
};
function cType( type, param )
{
    var m_response = model[type].pre();
    if( m_response )
    {
         cServer( param, function( text, type ){ model[type].post( text ); }, type );
         return true;
    }
    else
    {
         return m_response;
    }
}

PostScript

Because this is a small prototype/app I have preferences or things I will consider when I will have a working prototype, they are - testing, try/catch/throw handling of errors, advanced abstractions / design patterns, defensive coding against programmer error / malicious users. Will add these later if the project matures.

Answer 1

Disclaimer: I'm here at behest of the OP. I'm not all that proficient at JS, just enough to do some basic things, but I am fairly well versed in PHP. That being said, the knowledge should be fairly universal and I said I'd lend my point of view on the subject. Please feel free to point out my mistakes. I'd love to know more myself.

Edit: You can't have structure without syntax, so I ignored that bit. But I did edit my answer per your request for no comments on your naming scheme. I do still think its relevant so I left it, however I hid it so you may skip over it if you wish.

Descriptive Code (Naming Scheme)

I'll be honest, I'm not sure what exactly is going on here. Mostly because your function names are not very descriptive. More descriptive function names would be nice, or at the very least, more documentation. Especially documentation about where some of these other functions are coming from. Because JS is so loose with its scope control these could be coming from anywhere and it would be nice to know where they SHOULD be coming from and what they SHOULD be doing/returning.

Nesting Functions

There are a couple of problems with nesting functions. The first is that those "inner" functions are only available within the scope of the "outer" function and are recreated every time that outter function is called. Second is that it is generally considered bad practice. Not all nested functions, just most. But that is because most are not created properly. I've already said I'm not an expert on this, that's why I gave you the link so you can make your own opinions. I will mention that I don't think what you have here is a good example of nested functions. Mostly because I can't figure out how cIO() is supposed to work if it never calls in().

Switch Statements

You are defining your switch statements wrong. The colon ":" should come after the case argument, not before.

case 'user_try':

This is one of those rare instances where I would say you should look at case dropping. Not sure if that's the right term, but it sounds cool. What I mean by that is instead of retyping the same statements for similar cases, you can write it once, and prepend all the cases that use it above that statement, excluding any breaks so that they "drop" down to the next.

case 'user_new':
case 'user_exist':
//etc...
case 'tweet_add':
    out( cPreHold( 'model=' + type, cPost( type, text ) ) );
    break;

Magic Numbers

You have some magic numbers going on here. Not really sure how you should fix them, but I think there has to be some way. If someone could recommend an example as an edit, I will accept it.

array_pair[0].appendChild( array_pair[1] ) 

Miscellaneous

I'm confused as to what cPreHold() is supposed to be doing. You have it set up a response variable, check if it has a "true" value, which if it does, you do nothing with it, but then if it doesn't it returns the response variable, which is false... Why not just return false? Why use response variable at all?

if( mPre( type ) ) {}

I do not think that switch statements are necessary in cPre() and cPost() unless you are planning on extending their functionality. It would be better written as an if/else statement.

UPDATE

I can't really say much about your structure. As I mentioned, I only use JS for very basic applications. More or less, your structure looks the same as how I'd write mine, except for all those lamda functions and nested functions. I can catch some syntax errors, and provide some logic suggestions, but I'm not the best one to turn to for advanced topics such as structure.

BTW: Here's a function I find I use a lot. Seems like you could use it too.

function eID( id ) { return document.getElementById( id ); }

Hope this helps!