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.
Related
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.
I'm working on legacy code in a DotNetNuke module, trying to get classes and behaviors under a testing framework: I'm taking this opportunity to follow advice from the "Working effectively with legacy code" book, so what happens is that i'm trying to define areas which can be tested thoroughly and then converted to services. Then i'd like to use an IoC framework for it to work. For now, i've set eyes on Ninject.
However i'm hitting a design problem: as i'm in a DotNetNuke module, i can't really change application-wide structure: for example i can't derive the Application from NinjectHttpApplication. I can't use these suggestions from SO either.
I was thinking about having the Kernel in a static class that my module would set up and then use but from what i've read around it's a very bad idea.
So i'm starting to ask myself if it's possible to use an IoC in an application that hasn't been set up to support it from scratch. If i'm supposed to have a whole dependency tree loaded for each request, how can i rewrite legacy code locally and benefit from IoC? Is there a pattern where IoC use can grow out from very local rewrites?
Even though i'm working with DotNetNuke, any standalone component that can be installed into an independent framework begs the same question. Also i'm not targeting Ninject specifically, if another IoC framework can help in this case i'm willing to consider it.
From my experience, your best bet to get this type of abstraction within the context of DotNetNuke is by using the WebFormsMVP framework. This is really the only sane way I've found to do unit testing in a DNN module, and if memory serves I spent awhile trying to wire up Ninject a year or so ago.
But be warned, it is still WebForms and will never be drop dead simple. And without knowing your existing code base, I'd have a hard time knowing how easy it will be to make the migration.
I have a couple of resources on GitHub that you can check out for reference:
The first is a module template that should act as a solid starting point:
https://github.com/irobinson/WebFormsMvp-DNN-Module-Template
The second is a small example project:
https://github.com/irobinson/BeerCollectionMVP
Depending on the version of DNN you're using, it may or may not already ship with WebFormsMVP, but you should be able to either bundle the dependencies w/ your module or upgrade to the newer version of DNN if that's reasonable.
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'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.
I am at a company that does not understand the concept of using frameworks and the benefits of them. I have tried to explain that it provides structure and organization but the people I am trying to explain to are still a little fuzzy about it. In your opinion, what is the best way to describe a framework in the most simplest terms and how it could overall benefit a company to transition their code from procedural and spaghetti code to a nice organized framework?
Thank you for your time.
I guess the best explanation I can think of for using a framework are to standardize your design process and save yourself a lot of effort as your code-base grows. Not to mention that a lot of work can be taken care of for you by the framework (which could save hours of coding). A framework can give you all the parts you need to build your application, you just have to assemble them.
The best reasons I can think of for using a framework are:
Code reuse -- If you try and follow the design of the framework you can save yourself a lot of coding time. However, some frameworks do require a time investment to master.
Encapsulation -- You can change the underlying implementation of different parts of the framework in a way that doesn't require a lot of code rewriting.
Extendability -- You can extend the code of the framework to add features you need and if you are careful about your design, you can reuse these features too.
I'm sure there are many other good reasons, but I'm sleepy.
EDIT: A good example of the benefits of a framework can be replacing the database adapter with another ie. switching from mysql to postgresql. This could be awful with functional programming but a framework could make this transition very easy.
Your coworkers most likely already use libraries, which one could define as code that exists outside of your project, and is meant to used in many projects.
A framework is like a library, but usually has other featues, such as
It might enforce changes to your code. For example, you wouldn't replace one method of your WebForms project with a call to the ASP.NET MVC framework - the entire project would be written differently to conform to the framework.
It might restrict the universe of applications that you can write. For example, you might be using a CRUD generating framework that lets you make data entry applications, but wouldn't let you make a video editing application.
However, a framework will usually give you a lot of value in return.
Let them do as they like ,first.
then pick up their shortcomings and
finally generalise your framework to avoid procedural code.
I'm going to concentrate on only a part of the question:
In your opinion, what is the best way to describe a framework in the most simplest terms
Framework == Library + Inversion of Control