What is the difference between JPF (Apache netUI) and Struts? When should I use JPF in web applications? What are the pros and cons about JPF?
Apache Struts is an open-source framework that provides support to Model-View-Controller
implementations of web-pages. Its goal is to separate these three parts of the project: the model (application logic that interacts with a database) from the view (HTML pages presented to the client) and the controller (instance that passes information between view and model). It has a tag library
that eases the production of form-based applications with server pages.
NetUI is also a MVC framework that is part of Beehive Project, which aims for the reduction of the necessary code on J2EE projects
by using JSR-175 java annotations.
NetUI was built atop Struts, and it provides a Page Flow Controller class that separates navigational control from presentation
of the web-project, keeping a clean JSP code and enabling the reuse of navigational/flow logic (also, it provides a set of JSP tags for rendering HTML/XHTML).
Now, regarding your other question about when to use JPF: Page flows control all of the major features of a web application: how users navigate from page to page, user requests, and access to the web application's back-end resources. You should use them when you need this kind of control for your application.
For example, with normal HTML pages, each page is linked directly to other pages.
page > page > page > page
When using page flows, pages and actions are interwoven, transparently.
page > action > page > action > page > action > page
Here is an image to illustrate this situation. The .jsp squares are static pages, while the other ones are JPF controllers.
You can read more about all of this in the apache beehive documentation, where I got the most of these information.
Related
I am programming a large web site.
My main problem is the volume of the web at the end of the work
When the user enters the website address, are all the designed web pages loaded or only the first page is loaded and other pages are loaded according to the user's request?
Because in other programming languages, the entire website is not loaded, but this happens in web applications.
Currently we have a Hybrid solution where we show a web form in our Movilizer screen. This solution does not open a new browser window, but the form is shown in the movlizer screen.
This form need to be logged in with our credentials (using our login page).
Now we have a new requirement that on referring to the form, instead of our login screen, it will be redirected to a third party authentication login. Once the user is authenticated by this third party authentication, it will be redirected to the our web form.
How can we achieve this?
This must be solved first in the HTML world. Once the auth in HTML is completed (positive or negative), you can use the Movilizer specific Cordova JScript functions to provide the result to Movilizer, so the MEL logic in your Movelets can operate with it.
Movilizer runs HTML through lightweight html engines / browser components out of the frameworks of that specific platform. In other words, Movilizer clients use functionality that the native frameworks provide ... Movilizer does not have impact on how HTML itself is processed in there. Regarding the typical problems different browsers on different platforms normally bring, this means you have to carefully test the HTML part of this process on a multitude of platforms and devices.
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 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.
I am using MVC4's WEB API to expose a controller.
Initially I created created a MVC4 WEBAPI project, set the project not to open any web page, wait for an external app to call the URL (WEB API). The project in VS2010 is set to run from IIS7 Express, not VS2010's Dev Server. This works OK, the browser prompts me to down load a file. Which is OK for me, as the browser does not know what to do with the returned data (RAW TEXT).
Next, I created an AREA in the MVC4 project area, then added a controller (WEB API type).
Then I once again ran the project and in a browser entered the the URL (WEB API). And it fails.
Ed.
The DefaultHttpControllerFactory doesn't work with Areas by default. To get this functionality you have to write your custom HttpControllerFactory.
You can find how to do this at the post How to create HttpControllerFactory to support Areas
While it is possible to place WebApi Controllers in different Areas, ASP.NET MVC 4 RC will still treat these ApiControllers as if they all reside in the same namespace. This is a limitation of the DefaultHttpControllerSelector, which is responsible for selecting the appropriate ApiController.
Fortunately, you can inject your own implementation of this class. In fact, I've already encountered this very issue and written an "area aware" HttpControllerSelector. You can find a blog post of mine about this issue and its solution here:
http://blogs.infosupport.com/asp-net-mvc-4-rc-getting-webapi-and-areas-to-play-nicely/