I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
Related
I'm total newbie with Laravel, so the question might not be the most intelligent, be gentle, please.
I'd like to use an Open Source application made with Laravel. However, the application does not fully suit my needs, hence some customization is needed.
Naturally, I don't what to change the application files and also want to keep all my files separated.
In other PHP-based applications there are typically methods to customise the app without touching any other code. Also, it is possible to have own code nicely in one place. For instance, Wordpress has a theme concept, child theme concept, plugins and hooks in code (filters and actions). In Magento we have a simple method of overriding a core file by copying it to local code pool, as well as a more sophisticated dependency injection, which allows to override any class anywhere.
I've been trying to understand what is the correct way to customise a Laravel application in such a way, that my own modifications are separated from the base application and e.g. updating the base is possible.
Please guide me, or give pointers on how to do this.
Sounds like Packages might be your best option.
https://laravel.com/docs/master/packages
They let you customize very much in your application without touching other parts of the code, as well as keeping it separated from the other parts of the application.
Here's a getting started guide on packages:
https://medium.com/#lasselehtinen/getting-started-on-laravel-package-development-a62110c58ba1
I have been deliberating and deliberating. Orchard is clearly powerful and flexible, contains some very sophisticated code. I need to create some specific Wizard/Workflow functionality. I am also using Entity framework instead of NHibernate. It seems to me that it will be better to write this application seperately using simpler code, which I can refactor, and integrate into Orchard via a Wrapper Module, rather than getting caught up in writing a module afresh for the complete Wizard/Workflow. As I say I am learning MVC3 and do not want to overcomplicate my life, just deliver a solution. I will certainly use Orchard for typical CMS website features.
I also still have an unresolved issue of representing Organisations above users, which I have already resolved outside Orchard. This is only needed for the application rather than content management. So in the short term it may be that I keep the authentication seperate.
Does this sound the most pragmatic approach. If there was a good existing module then the decision would be easier. I think they are considering workflow for 1.7, but we are not there yet.
Many thanks,
Ed
It does sound like a safe path, yes.
I mainly worked with Rails-like frameworks in the past. Recently, I've been looking into Express.js. I've noticed that most of the examples do the routing inside the main app.js, or do the rendering inside route.js and I'm a bit uncomfortable with that.
A slightly more familiar example is the mvc folder in Express.js' github page, but even then, I find the way the routing is done a bit weird (also, view folder inside controllers? What's happening?).
My question is, what change of mentality should I perform, or is there a standard way of using Express.js that clearly separates the concern of routing and controllers and make them work neatly?
Thanks.
After a bit more of experimentation, I answered my own question.
Express is not made for these kind of tasks. Frameworks like Geddy or Tower are, although none of them are production-ready like Express is.
There is a module called Express-resource that does just what I want. Nevertheless, in the worst case, it's relatively easy to build one's own routing / controlling mechanism in Express.
I'm writing a web application in Go. So far I've written all base libraries I'm going to need for now and that worked out just perfect. The package structure is really handy in that aspect.
Now I'm at the point where I need to start writing the application itself, the business logic. I'm a little lost of how or where this code should go.
I've watched and read pretty much every application development tutorial/walkthrough on the official documentation page and they always write the entire domain logic in the main package/namespace.
Is this the way to Go (sorry, had to) or was it just for the sake of simplicity?
Putting the business layer into packages feels uncomfortably wrong in my opinion.
No, it does not have to be all in the same package. You can easily make a new directory, put your code for that package there, and import it from your main package. It's simple as that.
You may want to look at go-tour as a simple web app that consists of a few small packages (pic, wc, ...). If you want to see organization of a big Go app see Camlistore. Both of these are written by Go Authors, so they can be considered nice examples.
I just have to say that writing small, reusable, and separate packages is very common in Go, and that reduces the size of the main codebase of apps.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.