I really like the new feature, Web API that's released with MVC4.
I'm currently working on a web application, that I will want to extend it to a mobile application.
What would be the best way of utilizing this feature?
Program it like there's no Web API, and when i'm ready to develop for a mobile application, then use this feature (Copy and paste controller functions then edit the return and error handling value ?
Or should I use Web API from the beginning of the web development. Using javascript to call functions and to handle errros? The problem with this apporach is I'm not too familiar with JS, and the code would not look very clean (the Views)
Any opinion?
Thanks
IMHO the Web API shouldn't be seen as a feature specific to mobile application development. It's a tool allowing you to easily expose RESTful APIs over HTTP. Those APIs could be consumed from desktop applications, web applications, mobile applications, etc ... The interface for each type of application will of course be developed using the specific frameworks and tools for this task (WPF, ASP.NET/MVC, WP7/iOS/Android, ...).
The Web API just allows you to expose your business data and services in an interoperable way so that different clients could consume them.
I would prefer using the second approach.
In the beginning, I also thought the .ajax calls might mess up the Views. (No one likes to add a long <script> section in a View.) But after asking my questions on Stackoverflow, I am glad to find some experts here using some "code-behind" for those javascript.
The practice is:
Create a separate JS folder to store all the "code-behind" js files. (The default Scripts folder only contains the third-party packages like knockout.js, jquery.js and etc)
For each view, generate a .js file, like home.index.js, form.add.js, etc. Just follow a consistent rule. There will be a lot of js files created. The great thing is in MVC4, we can combine all .js files under this folder and generate a minified, combined, single file, and load it only once in the _Layout view.
The way to do it is:
In _Layout view, <head> section:
<script src="#System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/JavaScripts/js")" type="text/javascript"></script>
In Global.asax, Application_Start, register the bundle:
var bundle = new Bundle("~/JavaScripts/js", new JsMinify());
bundle.AddDirectory("~/JavaScripts", "*.js", true);
BundleTable.Bundles.Add(bundle);
BundleTable.Bundles.EnableDefaultBundles();
//BundleTable.Bundles.RegisterTemplateBundles();
Then you are good to go. The Views are still clean. All the .js files are organized. And no need to import different .js file on each individual view.
Leaning JS is not a problem. As it is probably the only client-side programming language, it is now becoming necessary for us to learn new things. And I feel it is easier since we have jQuery now. It is time to upgrade our knowledge. I am happy and excited about what we can accomplish with these new tools.
Related
OK so hear this: I have a project in mind, which would require a front-end solution (most likely pure html,css,js) and a back-end solution (not sure of the language yet)... if the site will be made in two parts (the app itself, and the static, I don't know how to call that site? it's the introduction site with about me etc.), how do I properly have the project organized if it will grow?
I'm starting a project where I will be making a suite of applications. Each application will be its own SPA, hosted on its own domains.
However, each application should use the same layout - nav bar up-top and pull out drawer on the left side. All the text and menu options should be handled dynamically (depending on the spa using it). What is the best way to go about this? How can I make a single layout component that can be used across multiple applications?
Please keep in mind that each SPA should have the ability to be developed independently - one might be ReactJS another might be VueJs or Angular.
Also, my employer does not want to use a micro frontend framework. I was hoping someone that is more experienced can help me out here and throw some ideas my way. Would I make this an npm package?
I would like to use strapi.io as my content manager, and I want to build the layout in quasar.js (but maybe I should build my own with no framework so each spa does not have too many dependencies IDK).
I'm working on two webapps built with Nuxtjs which are like e-learning apps. One app (App1) acts as a CMS from which a teacher prepares courses, and in and the other app (App2) is like an end result where a student can go through the content created.
Now I want to implement an instant preview of the App2 in the App1 when content is being built.
So I was wondering what the best approach, that's quick and seamless, is to go about it?
I was thinking of sharing the components in an NPM package between the two apps but the thing is that almost all the pages of the App2 should be used in the App1.
Or loading the App2 in an Iframe in the App 1 but no sure how to instantly show the changes being made in App1?
All ideas given is appreciated in advance.
As I guess you want to create two apps that have common components, and different logic, sharing components via npm package is a really good idea, I think you can also use Layout feature, you can have more than 2 scenes, But that can make the app little bit complex, it depends on how to organize your business logic.
Just created a new MVC4 Web API project - however I don't want any client-side for this, just the back-end to be referenced from other clients.
Is there any, sensible, reason that the default project template includes all of the javascript, views, etc?
Can they be removed without issue?
Default the web api project also contains the regular mvc stuff. If you do not intent to use the web api help pages (https://www.nuget.org/packages/Microsoft.AspNet.WebApi.HelpPage) or intend to develop a website part next to your api you can easily remove all views, scripts & statics.
I am about to start building a mobile site which is dynamic, working from a lot of dynamic content which must come from the database.
I have already written a REST API for the site which the IOS and Android applications are using to interact with the information.
My question is what would be the absolute best practise for building this site, would it be:
1- Make the mobile classes an extension of the existing site functions
(The downside I see here is that the mobile site would be dependant on the main site library meaning that any bad heat on the main site would also affect the mobile site)
2- Make the mobile site a completely stand alone site running from itself
(The downside I see here is that any change to the main site library will need to be reflected here so in essence we would almost be writing code twice)
3- Make the mobile site run from the REST API and standalone
(The downside i see here is just increased number of HTTP requests for the information rather than communicating with the server directly)
Each one would function normally and there wouldn't really be any problem there, coding is really not too difficult, though if I make it standalone I would need to recreate a lot of the functions from the main site and adapt them for the mobile site which isn't ideal.
Look forward to your comments! Thanks
I would go with 3rd point, but that needs to be architect well.
We will prioritize standalone application after that API, also we can have 2 way communication, any content changed on server it will coordinate with clients to get that updated.
Also I would also suggest go with Bootstrap framework, its an awesome framework and have responsive and adaptive design