As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been tasked with creating a Java web application that consists of two pages, a "Draw" page and an "Evaluate" page. I'll be developing in Eclipse.
The "Draw" page will facilitate the following process:
Take user input from a form
Using a Servlet, build a model in the background
Send the model to an Applet (probably via JSON) on the client-side to be rendered visually
The "Evaluate" page will:
Take user input from a similar form to build a similar object (same class) using a Servlet
Run a the model through an algorithm on the Servlet, and display the results on screen.
The pages can be relatively independent.
My question is, exactly how should I go about implementing this combination?
I'm familiar with Servlet development and the Spring MVC/Webflow framework, but in no way an expert. However, I'm guessing Spring would be overkill for this simple application, and I've never implemented a Servlet that has more than one major function.
Should I make an HttpServlet that just has conditional logic in the doGet/doPost methods, and performs an operation based on the request's URL?
Should I make two separate Servlets?
If so, would I make two separate projects in Eclipse, or just one project with two Servlets registered in web.xml? Should I do something totally different?
I'm not looking for code, but just would like to have a stronger understanding of how to approach this type of application.
I'm going to provide an opposing view to that of Dmitri's. I think its great for people to know how to write plain servlets but when it comes to writing code for a business I think you'd be better off using Spring MCV. The main reasons are:
you already have experience with Spring MVC, so no learning curve
although the requirements seem straight forward, my experience is that web projects like this quickly grow way beyond their initial specs, at which point you'll be wishing you'd used Spring MVC
You will have to code and maintain the features in a servlet which are normally handled by Spring MVC - I love the saying: they have solved problems that you haven't even thought about yet.
every line of code you write has the potential to be buggy, by reducing the amount of code you write you reduce the risk of bugs
Spring MVC is designed in a such a way that you can use as little or as much of the features that you like/need. With annotations, you can get a simple app up and running with a surprising small number of lines of code/xml
testing is much easier with Spring MVC
Spring MVC follows a convention that other programmers already know. If you leave your job, then someone can pick it up very quickly. OTOH if you code a simple servlet, you could do it a number of different ways that could make it harder to maintain for someone else
with modern hardware/OS, the extra memory/overheads that adding Spring MVC adds to you project is negligible - we no longer run our servers with 128KB of memory but some people still have a mindset that we do. If in doubt benchmark it, don't early optimise!
Spring (or any other MVC) framework is definitely overkill for this, servlets will do just fine.
Make sure all of your actual logic is in a separate class, all your servlets should do is apply whatever processing needs to be done to read the user input, and call the appropriate methods on your service class. Basically keep the web-specific parts minimal.
Whether it's two separate servlets or one that switches on the request path doesn't really matter. I'd use two separate ones, since mapping requests to methods is pretty much what servlets are designed to do.
You do not need separate projects in Eclipse, just define the servlets in web.xml (or with annotations if on Servlet 3.0).
It sounds like you're on the right track.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a Python developer, but I work with Python developers.
The scenario is the following: I have been asked to implement part of a system that integrates with a Python framework. I then agreed with the other team to develop my part in Java and provide full support to them implementing REST bindings. So I implemented a webapp in Java using Spring MVC and Hibernate. I can't go in detail but the design contract resembles the following:
The Python framework invokes a REST API with special authentication and authorization headers. The Spring MVC controller uses interceptor to perform authentication and authorization based on such HTTP headers, then gets invoked. The controller itself uses a path variable and two optional GET parameters to determine the type of object being accessed and the timestamp range
/api/{datatype}?[starttime=AAA]&[endtime=BBB]
Using a proper switch statement I choose the right Hibernate repository to query with these parameters and return an object (mapped to a table) that is translated to JSON by Jackson mapper for Spring MVC.
As a system integrator, I'd tell the guys to simply form legal HTTP requests to my component running on Tomcat and decode JSON (which is designed according to THEIR database model).
Instead the guys asked me to translate all the thing to Python. Apart being totally inexperienced in Python (I could barely write a console application that computes binomial coefficient, just not to implement yet another hello world or simple calculator), I guess that in Python no such thing as Hibernate, Spring and Jackson exist.
So, let's go to the question. Are there in Python any frameworks that allow me to...?
Easily create REST APIs with little code (Django????)
Easily intercept existing REST APIs and modularize the HTTP pipeline properly, i.e. doing authentication out-of-api-code, post-processing output stream, etc. through a mechanism similar to interceptors (I have seen something like that in their code base for authentication... we may mark this as solved)
Perform Dependency Injection. When switching between dev, staging, production, I currently change the class implementing an interface invoked by business code
Map objects to relations, such as Hibernate. That's currently my darkest point. I don't think there is any ORM in Python
Map objects to JSON (I know it's feasible, they already do in their codebase)
I won't post sample code believing it useless. I have tried to post a question as a general problem, not digging into specifics.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Due to security reasons our legacy application is split into 2 web applications, one application is for front end and another one for business logic and database interaction, i.e. middle tier.
I am redesigning this application now using the Spring MVC with JSTL. The tutorial examples are for 1 application.
What should I do to configure this spring application that uses JSP’s in a separate war?
Two main options:
Provide business logic as a jar and use it from the controllers.
Provide business logic as a SOA app.
It's not clear to me why the business logic and DB interaction needs to be a separate web application, as opposed to library. If they're being deployed on the same server, even less-clear.
If they're being deployed on separate servers, then you're basically making service calls from the "front-end" app into the "API" app. There are any number of ways to do that, could even be EJB-ish, although if you're using Spring, I suspect you're trying to avoid that (although with JEE6, much fewer reasons to).
I'll go this way:
First WAR contains JSP and all Web Components including images, CSS and JavaScript.
Second WAR contains Spring MVC Controllers and Service/DAO layers. The Controllers are in charge of invoking Service Object and parsing the response to JSON or XML.
With that architecture, your first WAR accesses second WAR services through AJAX calls. That implies intense use of JavaScript: maybe you can use JQuery to help you with that.
Also, that approach let you deploy WARs in different containers. And even the first WAR can't be a WAR at all and it could be even a PHP application deployed in Apache or a plain HTML/JS web page.
The first option Dave suggested is also the way we usually do it: Create a Maven multi-module project where the business services are built as a simple jar file on which the web tier depends. This way you can have a clean separation between the two layers and possibly reuse the business logic with a different "topping", e. g. a swing client instead of a web app.
Of course, this is also possible when not using Maven - you could keep your source files in separate folders and have Ant (or whatever tool you like) build the deliverables.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
I've been learning Spring and I'm really liking what I'm learning, but feel ill-equipped to do anything at the moment. I know Java really well, I'm ok at ant, but I don't know anything about: J2EE, JSP, Servlets, Tomcat, Maven, Hibernate, JPA, and I've never made any kind of website using Java (I've made lots of applications in Java, but all websites I've made were using PHP).
Should I cement some of my knowledge of the "basics" or should I keep slogging away at Spring?
Spring is a monster. It all depends on what part of Spring you are interested in. A good starting point would be the Dependency Injection container, which requires none of the technologies that you are unfamiliar with (the ones from your question).
If you are interested in learning Spring MVC (which it sounds like you might be based on the technologies you mention), I would recommend learning the basics in these (again from your question):
Servlets
JSP
Tomcat (or another web application container)
For Spring MVC I would also look at the idea of RESTful web services.
You can find a (likely) comprehensive list of Spring projects at this link.
I would recommend three things:
Lots of Reading => Spring Documentation in a Single Page
Lots of Coding => You can start off by getting an example Spring / Hibernate project. And then use Spring Tool Suite, which includes many interactive tutorials, and template projects that just work without any coding at all.
Find a Spring User Group next to the place you live. If there is no such group => create one!
It is totally ok that you don't know JSP / Servlets / Tomcat / J(2)EE / etc. Extremely smart people who, for example, write Linux kernel (which is a lot more complex) may not know it as well. The beauty of Spring is that going through it, and reading about best patterns and approaches you'll get all the above. No need to learn J(2)EE separately. Spring is J(2)EE of today.
For a good enterprise developer, I would recommend
a) very very good core java ( including collections, jdbc , threads)
b) servlets
Then I think you can start diving into spring.
If you want to accomplish something quickly to start with, definitely look at JSPs. A JSP is basically an HTML document with some special <% %> tags where you can just shovel in java. It's really entertaining, although nothing you'd want to use for a large-scale application.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Does JSP provide more flexibility then FreeMarker or is it other way around?
My back-end involves Servlets.
Which one is used under what circumstances?
JSP is going to let you do more things in the view layer, so you might say that makes it more flexible. Things you probably shouldn't be doing though, which one could argue as a benefit for FreeMarker. It would afford you more control over what the view layer can do and force a better separation of concerns.
There's not really any right answer here. You can technically accomplish just about anything with either for your UI. Without more details about your project it's hard to make a recommendation. About the only thing I can say is that you should probably use the MVC pattern. It can be accomplished with either.
My answer would be definitely to go with Freemarker.
Reason is flexibility in a term of usage.
It does not require servlet container, so you can also render e-mails or anything text based.
In a web application it makes possible to create web-modules as jar. Freemarker templates can easily be loaded from classpath (also, spring makes possible to load css/js - static content - from classpath with mvc:resources tag and scan for controllers). So a web module can contain its own templates, static data and controllers.
Freemarker is more powerful in terms of creating custom tags, jsp makes it just a pain. Also, custom tags allow calling back to body parameterized which you will not really be able to do in JSP very easily.
From Freemarker you can still use every JSP tag library available without problem :)
There are several libraries that have been around JSP like JSTL, DisplayTag, etc. that you can use if you choose to go with JSP. With Freemarker, there are not as many of them.
JSP is tailor made for Web pages, FTL is a more generic templating language - it can be used to generate html, plain text, emails, etc.
To pick one, you must consider what kind of tools you have. All good Java IDEs have excellent JSP support. FTL support may/may not be as good.
I believe that you already went for one or the other option by now. Anyway, comment might still be useful for others.
As WhiteFang wrote, using MVC is the only highly recommended suggestion.
If your application is a web based one, JSP would most likely be a better option as it is better known and one can write quite clean presentation code using JSTL (just make sure you don't mix in scriptlets ... all data should be prepared in servlets and passed on to JSPs as attributes). Choosing JSP you bring value to the project by enabling managers to plug-in easily other developers when needed to deliver faster etc.
Anyway, since you already have it on FreeMarker, if the template looks ok already, I wouldn't change it. Rather wait for when you have a business reason to switch. Whatever well designed an application might be, it will eventually need to be partially or even fully rearchitected. As long as you do modular programming, and keep your transformation in an isolated module, you will be able at any time to easily switch to whatever technology you'll see fit (potentially a new one, better than FreeMarker or JSP :) ).
I am usually using FreeMarker for non web applications. Or even in web applications, when I need to generate notification emails for example, which don't need to be web enabled. Otherwise JSP works great so far.
Stef.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on development of a social web application using Java. I need to develop the frontend/GUI of my application for web browsers.
I'm wondering what is the better strategy to do frontend development, whether using frameworks like JSF 2.0 & like OR simply following MVC approach with servlets and JSPs ?
As I have heard JSF really makes the development simpler but also the learning curve is not too low, so is it worth learning JSF or I should prefer to directly proceed with servlets/JSPs ?
I'm new to web applications development using Java & I've almost completed writing the business logic for the application.
Please justify your answer on the basis of following parameters:
Performance & costs
Ease of Development & Time (considering the learning time as well)
Future Maintenance of code
Any other parameters you consider important
Update (07-09-2012):
I finally went with JSF-2.0 & have no regrets till date. Learning curve is not steep. It's easier & development is fast with component libraries like Primefaces. There are some costs as to state saving but those things can be handled intelligently. Community is big & things are well documented now. Hopefully, in near future Stateless JSF is also coming which will boost JSF with extra high performance.
For a hobby webapp, homebrewing some MVC framework is not bad. It's a nice learning exercise tour. However, it will bite you on the long term, for sure if you publish on the web and it becomes popular. Most of existing MVC frameworks are very well thought out. Most of the unforeseen caveats are taken into account. The sole framework API is well maintained and documented by a third party.
Also, whenever your webapp becomes popular and you need more developers to work on it to fulfill the enduser requirements/wishes, it's easier to find someone who's already familiar with an existing framework. With a homebrewed and possibly buggy MVC framework, you'll likely find less developers who are eager enough to dive into another learning curve before taking over the maintenance which they'll probably never reapply on their future jobs/projects.
This does not specifically apply on JSF, but on every other existing and popular MVC framework as well, such as Spring MVC. As to JSF in general, well, I've written a lot about it before here. Here are some good starting points to read the one and other about it:
JSF versus plain HTML/CSS/JS
JSF adoption and popularity
What are the disadvantages of JSF 2.0?
For modern web apps like yours, and if your responsibility is the UI, you really don't want any "abstraction layer" stand between you and your html/css/javascript. Don't use any "component" framework.
I have heard JSF really makes the development simpler
Did you hear that from real webapp developers who actually used JSF in real products? Or just JSF committee patting their own backs? Or some old timers' wishful thinking that they don't need to learn the darn javascript?
If you choose JSF, please report your experience back to us after you shoot yourself out of frustration.
It's better use some MVC framework.
You can use either component based framework:
JSF = mostly standard, but its hard to learn and a lot of people don't like itTapestry = quite big and probably good framework
Wicket, GWT - smaller component based frameworks, handy, powerful, smart, but I haven't used them yet
Or you can use request oriented framework.
Spring MVC, Struts 2 = They are very similar. Spring MVC have probably better documentation
Struts - I do NOT recommend this, when you can use Struts 2, or Spring MVC - you can trust me in this point
Each framework have its pro-and-con it depend on situation and your knowledge. I cannot give you single-valued answer.
Spring MVC is very easy to learn and if you have a simple web app and you want to save your time, its better than JSF.
However if your web app is not so simple, JSF beats Spring MVC by far. Its model is more complicated, but it is much better structured and it is widely supported, so that you don't have to reinvent the wheel again in most of the cases. Complex gui can done with JSF with less effort.
You might want to consider Tapestry 5 if you're exploring options. We've been happily using it for many years on a large project in the social media space. It's an easy to use MVC framework that's component based. We're able to develop rapidly with it, especially now that we've built up a lot of our building blocks.
Learning time is probably on par with ramping up on any new framework. I'd perhaps say it's less than JSF and more than Spring MVC, though it really depends on what you're already familiar with and how deeply you use things. I put together a very small project on github a while back to get started with Tapestry 5 quickly, if you're interested it's tapstack.
As for long term use of a Tapestry based application, it has served us well. Maintenance of the code has been much better than when were using JSP. It's very stable as well. We've served billions of page views through Tapestry without any major problems.
On the downside it is less common than some other web frameworks. It is definitely a little different too. We feel it's worth it though, and refreshing to work with. Ultimately it's going to depend on what you need and what you feel works best for you. Best of luck with your decision.