Well let me try to explain what I need: once upon a time I have been contracted by a company to work for six months. The company was using an internal MVC framework, which was really outdated and bloated. Anyway I miss one great thing about it. It had JSP tags that you would fill with a controller name (as configured in xml files) and the "Action" (yeah was struts based), so that the resulting URL would be correctly pointing there (and I didn't have to worry about writing it by hand).
I was wondering if there is something similar in Spring MVC? It would be great
With spring-mvc - no. But grails, which is built ontop of spring-mvc, has this exact functionality:
<g:createLink controller="yourController" action="yourAction" />
Related
I would like to modernize my Struts 1.x application. There are quite a number of articles which advocate migration of codes, instead of rewriting the entire system.
I would like to seek the advice of someone who has successfully modernize legacy applications.
My current system is using struts 1.x and JDBC prepared statements as the data access layer.
I am looking forward to improve the legacy application with the following objectives:
Web Pages should be coded with Responsive Web Design in mind.
Replace struts 1.x with Spring MVC
I am looking to breaking up the modernization into the following phases:
Phase 1 - Change all jsp pages to HTML 5 and CSS 3
Phase 2 - Change all DAO classes to Spring JDBC Template or Spring JPA
and transactions managed by Spring
Phase 3 - Ultimately, replace Struts 1.x Action Forms, Actions with Spring MVC
Before I start the changes, I would like to find out if it is possible for:
Struts 1.x with HTML 5 and CSS 3? I am looking at replacing all struts 1.x html taglibs with HTML 5 and JSTL/EL.
Running Struts 1.x with Spring 3/4? Is it possible to run non-spring managed pojo with Spring beans?
What should I take note of and how/what are the best practices to handle this modernization process? The code base is about 500k of HTML/JSP codes and 3 million Java codes.
It's been a while since I last worked with Struts 1.x, but I see no problem replacing at least most of the Struts tags with JSTL/EL. You should be able to paint HTML5 with Struts 1.x JSPs. I remember working using little or no Struts tags, only JSTL/EL, but this was before HTML5.
You can invoke Spring Context from any Struts ActionForm or, essentially any class within your webapp. You'll probably have to do it manually though and not with annotations, something like this:
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
With all this said, I can see you're intending to do a serious update of your app, therefore I must ask, are you positive about keeping Struts 1.x? If you want to ditch Struts tags, use Spring 3/4 and HTML 5, why not dispense with Struts entirely and migrate your app to Spring MVC? It's very easy to use, powerful and, needless to say, it integrates perfectly with the Spring components implementing your business logic, persistence, etc.
Cheers.
(Not an answer, informational.)
There's no reason you can't have an S1 app running alongside Spring MVC. It's a reasonable way to migrate piece-by-piece instead of a longer project that does a complete replacement.
Older Spring has direct support for Struts 1. Depending on your timeframe I might consider using the older Spring until you're further along.
Replacing S1 tags with pure HTML/CSS will be a pain because the S1 tags render other stuff besides just the input fields (e.g., labels, error messages, etc.) It's totally doable, especially if you write your own custom tags.
jQuery v. (AngularJS | React | similar) Switching to a full-on client-side app is a big lift, especially if your back-end isn't already designed that way. I wouldn't do that, but you could get a start on it by putting business logic in its own place and using that from the web layer. Then...
... you start to consume API calls on the client side using jQ or other client-side framework injected into the existing pages. Only then would I start considering going full SPA.
The bottom line is you have a fairly large app. Rather than converting the entire thing I would consider removing functionality from the mainline app and break it up into sub-applications, each of which could use whatever tech stack seems reasonable.
I've done a lot of project like this as a consultant: it's a lot of busywork that requires a wide range of knowledge and skills, and it's difficult to get right.
First time asp.net webAPI + angular project. From many examples I've seen online I've found there are basically two ways for handling the views.
The first (which I have seen in many tutorials and courses) - use APIcontrollers only, so that the view are generated by angular. That means my project structure would have a folder 'app' and it will contain the html files (probably inside a 'view' folder). The routing will be done using angular routes. I will only have APIControllers in the project (without the regular Controller object).
Example project: https://github.com/DanWahlin/CustomerManagerStandard
The second - using Controllers to generate the views, using Razor (cshtml files), and angular incorporated into those (i.e ng-click inside the cshtml). There's no special 'app' folder for angular etc.
example project : https://github.com/Wintellect/Angular-MVC-Cookbook/tree/master/CRUDOperations
So, I'm wondering what are the pros and cons for each method, and when shall I use which one. Examples projects would be great as well.
I can only assume that the first method is more modular and differentiate server and client. However, using it means I'm loosing razor (Do I even need it?)
Thanks!
I actually had to make this decision a few months back myself.
This comes down to what you feel is more comfortable. I chose to do angular and WebAPI controls only. It makes me think in terms of true separation of concerns just easier, angular is your presentation layer and webapi is your services. This also gives you the freedom to do the compression/formatting of the actual html pages(instead of the cshtml pages which you really have no control over).
One more pro for WebAPI only is scalability, you would really only need one webserver for the webpages but you can scale out your WebAPI, this will allow you WebAPI to be your api as well as your clients as well.
Razor is just a view engine and in my experience angular does a good job of templating and directives to bear the cost of losing razor. You'll probably end up writing pure HTML in your razor files anyways once you get a hang of directives which means you'll have more of an issue adding a new view. Who wants to create a new controller, new action and a new view, and then have to do that in angular. It just ends up being easier and less complex to let server serve the html files, and let angular do all your routing and logic for you.
I believe too that the html files get cached too so you will see less round trips as you navigate page to page in angular.
As a person who works at a Microsoft shop and loves AngularJS for nearly all my front-end, the sooner you get away from mixing Razor and AngularJS, the better, especially if you are going for a SPA.
The only time I would recommend using Razor at all would be to generate the landing page (and possibly login page/admin area). It does give a nice way to provide authentication to access the app and then use Web Api Authorization attributes to do the rest of the authentication.
I am working on an web application/site and I want to do it with AngularJS, ASP.NET and Typescript.
I read about the Single Page Application concept, but I still have some question about this whole concept:
Why should I prefer a SPA (Single Page Application) before multiple pages.
I also have some questions about integrating it with ASP.NET:
In ASP.NET it standard generate a nice bootstrap layout with about 3 pages at the top. So I think that it means that I need to combine all these pages to one page. But how can I get it to work together with the routing of ASP.NET. Because you will use the routing of AngularJS, and I want to keep the login from ASP.NET (Can you maybe give an example so I can see how it works).
If I got it correctly Typescript in this concept will replace the JSON webservice. Is this correct or do I got this all wrong?
If you could answer one of my questions I would be very thankful.
SPA's are a trend, they are mostly useful to move the load on your server to the clients. Only data requests will be made to the server, rendering is done on the client machine.
There are still other benefits, but I guess this is the most relevant.
As to your questions regarding integration into ASP.NET.
Building an SPA does not mean all has to fit in one page. Look at AngularJS, it will fetch views as separate requests (see templateUrl in routingprovider). That being said, you can use ASP.NET MVC and serve ASP.NET Views as Angular Templates. This allows for a neat separation of Model, View and Controller parts.
Typescript is Microsoft's JavaScript dialect. It will not replace JSON and you will probably want to use JSON to exchange data with your server. You could use XML, but that is a little bit oldfashioned (and way more bulky).
I have no experience with TypeScript so I would not consider doing that (coffee might be a better alternative), but there are also some quicks in JavaScript you need to be aware of. I would suggest to search Douglas Crockford and Javascript on Youtube. The guy has great talks that can make you a JavaScript pro.
I've been reading up on MVC2 which came in VS2010 and it sounds pretty interesting. I'm actually in the middle of a large multi-tenant application project, and have just started coding the UI. I'm considering changing to MVC as I'm not that far along at this point. I have some questions about the Routing capabilities, namely are they required to use MVC or can I more or less ignore Routing? Or do I have to setup a default routing record that will make things work like standard ASPX (as far as routing alone is concerned)?
The reason why I don't want to use Routing is because I've already defined a custom URL 'rewrite' mechanism of my own (which fires on session_start). In addition, I'm using jquery and opens-standards for the entire UI, and MVC's aspx overhead-free approach seems like a better fit based on how I've already started to build the application (I am not using viewstate at all, for example).
I guess my big concern is whether the routing can be ignored, of if I will have to re-implement my custom URL rewriting to work with MVC, and if that's the case, how would I do that? As a new Routing routine, or stick with the session_start (if that's even possible?).
Lastly, I don't want to use anything even remotely 'intelligent/readable' for the url - for a site like StackOverflow, the readability of the URL is a positive, but the opposite is true if it's not a public website like this one. In fact, it would seem to me that the more friendly MVC routing URL (which indirectly show method names) could pose a security risk on a private, non-public website app like I'm developing.
For all these reasons I would love to use the lightweight aspects of MVC but skip the Routing entirely - is this possible?
You could make it work without routing, but you would have to rebuild a lot of the framework and pretty much build your own routing engine. That wouldn't really make any sense as Microsoft already provide you with a great routing framework. All your url rewriting rules could easily be implemented using the routing framework anyway. You don't have to have the action name of the controller name in the url if you use the routing framework. As long as you can tell what action should be executed from the raw url it could be implemented.
My advice would be to read up on the routing framework and learn how it works. I'm pretty sure you will not regret it.
Don't bypass routing
Routing is imperative part of Asp.net MVC and ignoring it will cause more or less trouble. You could get by by using ISS7 URL Rewriting module, but it will only work if your requests have a certain format, otherwise you will end up writing rewrites for every single request that is used in your app.
The good thing is that routing is nothing you should be afraid and is quite simple to understand as long as you don't start havind some complex routing rules. Then you will delve even deeper into it and probably love it even more.
I want to build an ASP.NET MVC application with Boo instead of C#. If you know the steps to configure this type of project setup, I'd be interested to know what I need to do.
The MVC project setup is no problem. What I'm trying to figure out how to configure the pages and project to switch to use the Boo language and compiler.
So there are two levels of "work with Boo". One would be all the code (namely, the Controllers), and the other would be the views.
For the code, I assume Boo compiles to standard .NET assemblies, so simply properly following the naming conventions using by ASP.NET MVC should allow you to write Controllers. You will probably need to start with a C# or VB version of the MVC web application project template and port some of the boilerplate code over into Boo to get the solution entirely in Boo (I presume Boo supports Web Application projects?).
The other half is views. Someone will need to port the Brail view engine over to the ASP.NET MVC view engine system. This may already be done, but I don't know for sure. If it's not, then this is probably a significant amount of work to be done.
Probably the best place to get answers to these kinds of questions is the MvcContrib community on CodePlex.
The Brail view engine has been implemented to be used in ASP.NET MVC. The MvcContrib project implemented the code. The source code is located on Google Code.
As far as the controllers, I really am not sure. I am not that familiar with Boo. I know a lot of developers use it for configuration instead of using xml for instance. My tips would be, if Boo can inherit off the Controller base class and you stick to the naming conventions, you should be alright. If you vary off the naming conventions, well you would need to implement your own IControllerFactory to instantiate the boo controllers as the requests come in.
I have been following the ASP.NET MVC bits since the first CTP and through that whole time, I have not seen somebody use Boo to code with. I think you will be the first to try to accomplish this.