-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules encapsulating UI and data? #35
Comments
Hi @mulderp, I've been thinking about those for a while, and I'm still unsure how I'd like to manage creating backbone objects in the generator. Unlike more structured framework like Ember/Angular, there's very few information the generator can write to the file. Anyway, the last thing I had in mind was And then it would generate the correct object type and maybe some extra. For views, I think i'd put them this way:
But for model/collection, I'm still unsure. Any suggestion or return on a similar API is warmly welcomed! |
Oh also, there's of course the separation of concerns in a module. So I wasn't sure if module should only generate a file, so it is used this way:
Or if calling Although, I think this structure is still a WIP and haven't been exactly defined yet in the BBB project. - And then also, of course, BBB is moving more away of app creation best practice and more on the tooling side of the things. So this concern may be out of scope for where Tim wanted to bring the future of BBB. |
Interesting thoughts. Well, the Rails approach is often taken as an example, but in my opinion, Backbone's model and collection belong together. My favorite way of structuring this is by looking at the original documentcloud application like here: https://github.com/documentcloud/documentcloud/blob/master/public/javascripts/model/accounts.js Since many views need a template, and some don't, I also like the idea of having a directory 'UI' in an application, so, for my taste the critical separation is 'UI' and 'Data' . This might also be interesting to managing source code, since UI will need to change more often (= more merges), than Data does (= API is more stable). Well, I know this breaks the concept of MVC a bit, but on the client-side things are different anyhow. PS Sorry about the confusion of BBB and Generator-BBB, I thought they were more closely related. |
Oh no, they are closely related. I agree with you on the data part, like you I usually combine model and collection in the same file when that make sense. And their position is relative to their scope (global application or only a sub-module). I'd like to see a demo the tree of your typical BBB application. |
So far, I am only working with medium sized projects. It is mainly:
I am recently working with Thorax, where it looks something like: main.js (= basic setup) The Thorax generator also does a Collection and Model structure, see: https://github.com/walmartlabs/generator-thorax Hmm.. most likely, it is a question of project evolution... |
It's very much the future for this project. Components are a big deal and we're already seeing them used in active development. I think right now is a bit premature to formally bake anything in. The text plugin and css plugins are not sufficient as defaults in my opinion. I want to see an excellent Lo-Dash/Underscore templating optimizer that does proper precompilation and inlining. The CSS plugin would need to build out to a separate file instead of inlining inside of the output JS build. |
I wrote https://github.com/tbranyen/lodash-template-loader in response to the first missing piece. Looking into CSS plugins now. |
Hi @tbranyen !
If I understood correctly from the video of your Backbone talk at Backboneconf, you were advising to use separate files for the UI/View layer and the data layer.
Would this mean we would get a different way to call:
e.g.
or
The text was updated successfully, but these errors were encountered: