Determining app structure

[luckysmack]

my histrory on mvc frameworks is primarily in php (cakephp, yii) and some in .net. So since in meteor the controllers are typically exposed to the end user, I had some questions on how to structure apps in meteor.

Typically in php my router would point my url to a controller/action. /foo/bar/baz would load the foo controller calling the bar function passing baz as an argument. I do see routers I can do this with. But from my thinking and experience, I would have a lot of code I may not necessarily want the end user to see in the controllers. Should I try to move more of that logic to the models? or Something different. I suppose from my experience, having to use server/client/public directories is just a lot different to my normal way of thinking. So I just need to find a way of doing this that matches with meteor.

Typically, using php i would have root directories like so:

framework/

--/all the files for the framework i would use. meteor is setup from npm so I wouldn't really have this

app/

--/config/          # config files like database connections, and so on.

--/controllers/    # normally private, but in meteor is public. is there any benefit to having controllers available to the client? or could I put these in /server/ as well?

--/models/        # this would essentially be in the /server/ directory for meteor.

--/views/          # here would likely be all of my templates, separated by directories related to controllers/models. public

--/public/          # just like meteor, all of my public directories. in php, this is the only directory the end users can see.

best I can tell, the best way i can organize this in meteor is like so:

/controllers/  # since not in server/client, is available to both. do I need to do it like this? it seems like this is how meteor behaves like it is real time

/server/        # only available to server

--/models/

--/config/    
/public/         # like normal

/templates/   # replaces views, available to both clients and server

Does this seem right? I just want to be able to secure my code logic so users have the least possible chances of messing things up or doing things they shouldn't. I'm sure its just very different so I just need to look at it from a different perspective. Also, in php anything in the <?php ?> tags are hidden as well. In meteor, using mustache, anything in the {{  }} brackets can still be seen in the html source. Which i suppose in a way I would want to hide as well.

Also as a note, the need/want to hide code is primarily for apps that i want to make closed source or for things I would make at work, which is all generally proprietary code. If I am making something open source, Obviously I am not nearly as worried about this issue. 

I'm just looking for more insight oh how I should do this and if anyone has any input on another or better/node/meteor way of doing things. 

Thanks.

[Iain Shigeoka]

Hi,

Take a look at Tom's Unofficial FAQ:

https://github.com/tmeasday/unofficial-meteor-faq#where-should-i-put-my-files

There are some suggested directory layouts presented there.

-iain

> --
> You received this message because you are subscribed to the Google Groups "meteor-talk" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/lUF_g7gUWvMJ.
> To post to this group, send email to meteo...@googlegroups.com.
> To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

[Shawn McElroy]

ok that helps. but I am still curious as to the need to have controllers visible on both ends. It seems that this is how the client can do things that make it appear to react instantly, since it has that controller and routing data to know what to do.

Also, is there a way to hide code inside the {{  }} tags? Would I use a different templating engine? I do believe that there should be no logic in the templates so most of this would just be echoing variables and loops. But I'm still curious if anything can be done to hide it.

--

 -- Shawn McElroy

"Anything worth doing, is worth doing right"  — Hunter S. Thompson

"A mind troubled by doubt cannot focus on the course to victory" — Arthur Golden

[Iain Shigeoka]

On Aug 17, 2012, at 7:34 AM, Shawn McElroy <lucky...@gmail.com> wrote:

> ok that helps. but I am still curious as to the need to have controllers visible on both ends. It seems that this is how the client can do things that make it appear to react instantly, since it has that controller and routing data to know what to do.

I'm not sure about the need for controllers at both ends. You'll be sharing your data models, method signatures, business logic, and data validation between client and server. In general, the controllers in more traditional MVC designs will mainly live on the client and interact with the client exposed database(mongodb)/models and call the methods that the server implements. Controllers on the server are probably going to be rare (except for functionality that covers data validation and business logic which you'll want to re-run on the server to protect against rogue clients). Note there is ongoing work in the auth branch to make data validation easy: https://github.com/meteor/meteor/wiki/Getting-Started-with-Auth (see section on "Restricting writes").

> Also, is there a way to hide code inside the {{ }} tags? Would I use a different templating engine? I do believe that there should be no logic in the templates so most of this would just be echoing variables and loops. But I'm still curious if anything can be done to hide it.

No - at least not for handlebars. You'll want to place code inside template data providers (aka the Template.foo.bar = function(){} that executes the function and places the return value into the template 'foo' context name 'bar') or template helpers via Handlebars.registerHelper().

Note that the template engine is going to see a major update soon - you can see the preview of docs https://github.com/meteor/meteor/wiki/New-Template-API and play with the code on the 'spark' branch.

In case you aren't aware, if you are playing with code that depends on different meteor branches, you may find the Meteorite tool an invaluable help:

http://possibilities.github.com/meteorite/

-iain