I hope this isn't too vague.
I am wanting to create an mvc project in which I can use in other projects. I am wondering whether I can do this with Areas. Although when trying it looks at the wrong folder for the views. Does any one know a way of doing this? or Is there a different method?
Check out portable areas, I think its exactly what you are looking for.
http://lostechies.com/erichexter/2009/11/01/asp-net-mvc-portable-areas-via-mvccontrib/
You can use EmbeddedResourceVirtualPathProvider which works for MVC views and also other content files (e.g. js/css/aspx).
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 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 have looked for similar questions, but could find none other than the difference between solutions and projects. Mine is on the same level, I suppose, but is slightly different.
I'm a previous Java developer thrust into C# recently and I am the sole individual charged with setting up source control, project standards, etc. etc. and this is my first go with Visual Studio (using 2010 Pro).
I understand a solution is a "container" for related projects, but I am unsure the best practices of adding projects to a solution which are related, but are of a different type.
For example, would I place a web project in the same solution with a desktop application or mobile app if they are related (rather near identical) in function? They are basically the same app, but in different formats. They may use the same classes (for a contrived example, a Person class).
To me, they seem obviously related, but are different applications, so it would seem they should be in different solutions.
I appreciate any feedback offered.
Thanks in advance.
Those apps should be in one solution, expecialy if they share functionality, common projects etc. Quite good approach is to group projects within a solution using solution folders, for example "Common", "Web", "Mobile", "Setup" etc. This way you can have logical groups inside solution.
I would place them in the same solution, since this makes it easier to have a common class library as one project in that solution.
There are no rules for this so there is no right or wrong answer. It all comes down to how you want to organize your code. We commonly have web apps and console apps in the same solution because they are functionally tied together and share code so the type of project really does not matter.
I would place them in the same solution. You can create different configurations to build each application or build both of them at the same time. This allows you to change the class and verify changes made to the class will work for both applications.
Also if you start to see functionality start to duplicate across applications it is easier to create new classes and project that can apply to both applications.
You can throw everything in one solution. This is convenient if you often have to debug the library and application code together, but if the solution has many projects it can become unwieldy.
One approach is to treat the solution as 'that which will be installed as a unit.' Then your common library will go in one solution, and your mobile and desktop apps in their own solutions. This keeps solutions smaller, but it can be inconvenient when you are developing everything together-- so it works best when the library is very stable.
I am trying to find out if I am thinking about this correctly. My goal is to be drop in a dll and have access to helpers, and partial views (Maybe Views too), using an MVC pattern. I have been treating Areas as modules lately using #RenderAction to serve me up some partials when I need them anywhere on a site. I can copy that whole area out and reuse it on another site, but that means changing namespaces on each file and it's duplication of the area so I am not getting to update it in one place for all sites. I am open to ideas and thoughts if I am approaching this incorrectly. For clarity's sake, here is my question: Is there a way to isolate only an area and compile it in it's own assembly? If so why is there not a new project type for that? Like add->new->module?
Thanks
You may checkout the following article which illustrates a nice technique allowing you to embed razor views into a separate assembly as embedded resources.
i am pretty new to CI. been looking at few template libraries but found either they have much more than I need or not enough.
so i started to build my own. is there anything i should keep in mind? in terms of security? caching? etc etc
thank you
A template library is pretty simple to create and unless you have a need for all the stuff that one of the many available have I would just roll your own. With that said I tend to use the one by Phil the most as it matches the closest with the way I do things.