http://sydjs-architecting.heroku.com/
Write Javascript apps, not just random methods. Some exceptions apply.
I'm more of a module pattern kind of guy so that's my take. At the end
of the day, it's all a matter of how you like the source written.
As for number 2, not necessarily. Write your JS as a client to the
server's API. E.g.: a table you can use to read/write data is an app
in itself. While it may appear in, say, FruitsController#index, I
wouldn't have it mixed up with something else.
And as for 3, all the way. If you're using Rails, go for Jammit.
> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>
>
We're using a tool which a (former) colleague of ours created. It's a
very impressive hack IMO, although I'm on the fence as to whether or
not it's a good idea overall. I probably wouldn't recommend it for
smaller projects:
http://github.com/adamh/html_namespacing
The idea is you can write CSS and javascript that's scoped to a
particular *partial*. So:
* The CSS for app/views/path/to/template is in
app/stylesheets/views/path/to/template
* The JS for app/view/path/to/template is in
app/javascripts/views/path/to/template
It does this by inserting a class name (based on the template path) to
the toplevel elements of each partial, and then:
* for CSS: prefixing each rule with this class, so they only apply to
that part of the DOM
* for JS: providing a jquery object $NS(), which returns a jquery
object containing those elements, so you can look up elements just in
that part of the DOM using $.find().
The HTML modification is done by wrapping calls to render and scanning
the HTML using a C extension (so it's pretty fast, and only MRI/REE
compatible so far). You can then insert the CSS/JS for just the
rendered partials using a single helper call.
We've been using it for over a year, and I think it's done wonders for
managing development complexity. It has gotten in our way a little
when trying to do aggressive caching, or bundling asset (css, js)
files into libraries. It would also have a slight hit (not sure how
much) on JS performance, as all jquery selector lookups are prefixed
with an extra namespace class.
To deal with the bundling, we include all our "namespaced" JS and CSS
inline to avoid requiring a second set of user-and-page-specific
css/js files (throwing all the namespaced JS and CSS into the
site-wide css/js files was making it way too big). The rest of our JS
and CSS is minified and bundled using another gem he open-sourced:
http://github.com/adamh/asset_library
Hope that helps! Would of course love to hear impressions if anyone
gives either of these a go.
George
Excellent, thanks Julio. It's really nice to see the alternatives
distilled into such a clear presentation. I've seen so many
variations of "objects in JS" that I wasn't sure how best to do
it.
Clifford Heath.
It doesn't matter if you have a bunch of those. As long as these
applications can all be retrieved with a single request (read: you're
bundling/grouping your Javascripts) when in production, you're set.
Might as well pimp it while we're on the subject :), so here goes a
different solution than Jammit ->
http://github.com/juliocesar/rack-bundle
Though I recommend Jammit if you're using Rails.
--
+1
Mikel
SHUUUUUUUUUUNNNNNNNNN!
I seem to recall Dave Thomas saying in his recent talk that MVC was a workaround because the machine it was developed on didn't have proper interrupt handling, so they couldn't use event-based processing.
I think the important thing about what's proposed here isn't about
putting
the M/V/C parts into separate files, but about separating those roles
at all.
That is, the "M" part describes a passive box of state and capability,
the
C part activates those capabilities, and the V part displays the state.
There are many ways to implement this separation, and it doesn't have to
be as heavy-weight as some of the approaches proposed. The important
thing is the mental discipline imposed by separating them conceptually.
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.
I really like this approach. The trickiest part of having the DOM involved in JS is that the DOM can simultaneously be the Model *and* the View. This structure forces to you to separate that duality.
> There are many ways to implement this separation, and it doesn't have to
> be as heavy-weight as some of the approaches proposed. The important
> thing is the mental discipline imposed by separating them conceptually.
With Jammit, Sprockets and other JS managers, the folder separation is not an issue for production but makes the approach taken extremely clear.
The fact that it mirrors Rails' own structure makes me have to think about it less. Time for an opinionated JS structure in Rails perhaps? ;)
Josh
--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
I don't think that "Jails" is ever going to catch on ;-)
--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
MVC originally served the purpose of each model serving an unknown
number of views of potentially disparate types. In most situations
that doesn't happen and isn't needed however, and the value of
separating the model from the view is less. If the Model is a JS object,
and the view is a DOM object, and they're closely coupled one-to-one,
that serves most purposes. So on that I'd agree with Korny.
If you have a bar chart with values above each bar, there's no need to
separate (for example) the bar height from the displayed value, as two
separate views - it's simply overkill. Do it as one view instead.
It's really important that the model is passive and the controller
separate.
That's what makes it possible to configure the model through settings,
and tweak the behaviour by changing the controller. Finer-grained
customisation is usually not needed, since we have CSS to set most
view details.
> The fact that it mirrors Rails' own structure makes me have to think about it lessThis is exactly the reason I use MVC for my Javascript files, it means
one less concept to wrap my head around.
--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.