I'm stuck with a mess of a web application. The previous developer started porting the Spring MVC/Apache Tiles application to Backbone, there wasn't a RESTful API to support the port however and it's stuck in this funky state where JSPs are rendering the HTML and some JS which then loads a Backbone View. About half the API has been ported to REST but the application is still far being a true SPA and even further from being done properly.
I've got a strong background in Angular and little with Backbone but next to nothing with Spring & Apache Tiles. The application either needs to go back to server side templating or be rewritten to truly become a SPA with proper organization/testing.
If I start (properly) porting to Angular or Backbone, is it possible for the two frameworks to work together (Spring / Angular or Backbone)? I've done a port like this in the past from Django to Angular on Google App Engine and it wasn't too bad but the application has significantly smaller. Has anyone done something similar to this, if so I've been unable to find anything on how to go about doing so or if I should even try.
Well, if you don't have a background in Spring & Tiles, it'll be difficult to learn & then port.
But if you're up for it :
1. Read about Spring (Dependency Injection & Configuration)
2. Read about Spring-MVC
3. Read about Tiles
Since, you already know about Django, you should be able to spot the similarities very soon. Once you become comfortable with Spring & Tiles, follow this approach :
1. Take a controller
2. Convert the JSP (which is returned by this controller) to a html template (used by Angular/Backbone)
3. Convert the model (data sent to the JSP) to JSON & start returning this JSON instead of the JSP
4. Create a route & test
5. Pick another controller
JSP is just a template & then model(data) is passed to create the actual html response, same as we do in case of Backbone (underscore template & then pass data to create the actual html).
This should be enough to start.
Related
I am not asking if it is possible, I know it is but I would like to know what's the best way to offer a rest service while having a front end in my application.
I'm developing a Spring Boot application, I currently have a controller that calls jsp pages, and a separate RestController. I want to be able to consume it with an Android application.
So is it correct to have both a Controller and a separate Restcontroller in my application? For example the Rest controller methods will be called from /api/*.
Edit :
I know the difference between the two, but since I want to be able to return a view ( and I shouldn't do that with a RestController) and I want to have a rest service I am wondering if I can have both of them (separately of course).
Thank you so much in advance.
I'd say that it's possible, but considered a bad practice (except for corner cases like a controller for Swagger in a REST application) in a typical, layered, spring app (will get back to that)
you may want to create a multi-module project, that may look like that:
parent project
-- core
-- web api (jsp based)
-- rest api (for android)
both web api and rest api depend on the core.
web api and rest api are separate deployment units. you can deploy them on the same server or run as separate applications (for example using spring boot). Depends on your usecase.
with that you can have your business logic in one place (core).
you may also want to read about ports and adapters architecture, which may give you an idea how to solve this in a more organized way than just having Controllers and RestControllers sitting side by side
I plan to port a MVC app from Spring 3 to Spring 4 using Spring Boot.
This webapp use Apache Tiles.
I'm a bit confused considering Thymeleaf seems to be the new standard with Spring, with nice integration.
Tiles was a pain to configure in this app.
We've got like 20 JSP pages in this app.
Questions :
Does Thymeleaf and Tiles are similar concepts ? (template engine ?)
I've seen that Thymeleaf could be used with Tiles... I can't see how and why
Would it be better to keep Tiles and make it working with a Spring 4 / Boot application ?
Would it be better to port Tiles/JSP to Thymeleaf templates ?
I would suggest eventually porting Tiles to Thymeleaf, but you don't have to do it all at once.
Your intermediate strategy could be to start using layouts and integrating existing Tiles where it makes sense. New development can be straight Thymeleaf and you can fully port existing Tiles when it makes sense to you.
Please see the following article (you can jump to the "Thymeleaf Tiles Integration" section) and the associated example code on github.
We have a Spring application which exposes all the business logic as RESTful web services, which is consumed by the jQuery front end. Our jQuery front end code is becoming unmanageable with javascript manipulating the html files. So we are planning to use grails with jquery/bootstrap to overcome these issues. Right now, we are doing a Poc to understand the implications of moving to new stack.
Our current understanding is that we will run two applications - one for grails and one for Spring backend. We can implement CAS to maintain the session between these two apps. Grails will use spring for all data as well as business logic. Our front end communicates only with grails, which in turn connects to Spring as need basis.
I am not sure what are the potential things to look for in the new approach. Can someone provide
feedback on our approach?
Thanks
--Venky
I would suggest to create only one app, in grails. Plug all your existing code into src/java and use groovy domains/services to get data from you existing business logic.
In this way you will not have the overhead to run 2 webapps that will communicate over http to serve one client request.
I am working on a porlet app and it looks like the "main" portlet will be pretty complex, with some wizard-type functionality in it. I started with plain Spring MVC but it's clear that the backing controller will become very big and unwieldy over time (to my eye). I like to keep my classes small and static through the lifetime of an app.
I was considering the use of Spring Web flow, but a lot of the documentation on it seems to be from 08-timeframe - my question is, is this still a good technology choice for a modular portlet architecture? Is there a way to redirect to standard MVC in certain use-cases within the same portlet/mode..? I.e. to use SWF where it makes sense, but use MVC for other use-cases..?
Spring MVC supports portlets and so does webflow . We had an AbstractWizardFormController earlier in Spring for process ing data in a Step-By-Step approach which was replaces by Web flow . These store a Flow Id in every screen which decides the movement of the flow . Consider webflow if you have the following scenarios
There is a clear start and an end point.
The user must go through a set of screens in a specific order.
The changes are not finalized until the last step.
Once complete it shouldn't be possible to repeat a transaction accidentally.
As per the documentation here . It does support portlets. The portlet intergration reference is here . Check here for spring mvc integration .
I am in the middle of creating my own custom MVC web framework for a project. This project has very old code base where one JSP page directly submits a form to another JSP whereas the paths are also hardcoded. Now it is a big project and putting Struts or JSF will take considerable amount of time.
So my suggestion is to build a small custom MVC framework and convert many existing page flows into it and also encourage them to develop newer applications using this new MVC frameworks.
I would like to review this with all of you whether it makes sense or we should directly go to the standard MVC frameworks.
My idea
1. Create one front controller servlet which will have URL pattern like /*.sm
2. This servlet reads one config file and creates a map whose key is requestedURI and value is the class name of the command bean.
3. upon intercepting any action request it reads the parameter map (request.getParameterMap()). This servlet refers the already built map, understand whose command bean is to be invoked? Creates an instance of this command bean.
4. pass the parameter map to this command bean and calls execute method.
5. if any exception is found, front controller servlet forwards the request to one global error page
6. if everything is fine, it then forwards the request to the expected URI (by removong .sm and replace it with .jsp)
Do you think I am missing anything here? I know I can make it more fancy by providing error page per request page in the config file or so but those can be done later as well.
I think that you will end up reinventing the wheel rolling your own MVC framework. I know that it is tempting to make your own, since you won't have to get used to a new API but instead create your own and you can more easily adapt it to your specific usecases. But since it seems to be a very long lived application you will have to consider the fact, that your own framework (which may now be state of the art) will be legacy in a couple of years, too.
And that's where adapting one of the popular frameworks comes in handy. The creators of a new framework usually want others to move, too, so they will (or should) offer easy integration or migration options away from the frameworks they think they are doing better (Spring is a good example since it e.g. seamlessly integrates with existing Struts applications and you can gradually move your application without putting the old one into trash). Additionally most current frameworks are very versatile (which can sometimes be a problem since they need more time to get into it) and can be adapted to almost all usecases.
So I would recommend to review the existing solutions carefully (you can learn a lot from their design decisions and errors, too) and only start making your own if none of them matches your requirements.