Notalib/LYT — Issue #67: A couple of suggestions
Author: Flambino
Created: 2011-12-22 20:34:54+00:00
State: open
Labels: code improvement

Looking over the control/render/router stuff, I got a few ideas.

1. "control" should really be "controller" :-)
Just because it'd be in keeping with the singular-noun-convention we've used everything else.
2. A function to generate URLs would be great - no more hardcoding urls in the code. Plus it could automagically handle URL escaping of parameters and such. Something like `linkTo "page-name", { param: "value", ... }`
3. There's a few things which might be nice to extract/abstract, since there's some repetition

For the 2nd point about abstraction, here's what I'm thinking:
Most pages/actions go from router to control to render. It might be nice to make that relationship automatic. I.e. if a page is defined in the router, it's assumed to have a similarly named function in the controller, _and_ a similarly named render function.

Also of note is, that the first thing many controller functions do is call calling `getParams` and finding the content element. This is the kind of thing would be neat to abstract. It'd require a change to the router-library or a layer between the router and the controller functions, but it shouldn't be that hard.
The idea would be that the controller functions simply get the content element and the params-hash as arguments straight away.

Similarly, the render functions always take the `view` element as an argument. Perhaps it'd be simpler to have the controller functions return whatever's needed by the render function.
Or the controller and render functions could be called in certain object scope, so they'd share instance properties. That'd be pretty much be the same view/controller structure as in Ruby on Rails, and almost the same syntax even:

# This function would be called automagically, if the url is "#somePage"
controller.somePage = (...) ->
# Set a variable the render function can use
# `view`, `page` and other stuff is implicitly set
@someVar = foo

....

# And this could be called automagically, since it shares the same name
render.somePage = (...) ->
# Use the vars for something
@view.find("#label").text @foo