We Keep Coding

Where to find examples for easy task manager

I am a junior java developer.
I have to make a project that requires me to have 2 kind of users, managers and normal ones.
The manager may add new duties to the normal users, register new users in the system, view everything etc.
The normal users can only view information related with them.
I am able to do this by my own but I am required to use MVC architecture and I am a little confused.
Please if anyone know where can I find any similar project it will help me a lot

I think the best you can do is use Struts framework to implement your application (http://struts.apache.org/). Simple, universally used, realizes MVC pattern in a very easy and understandable way, supports user handling and so on.
If, on the other hand, you are not allowed to use frameworks...
Well you should struct your application with jsp, servlets and POJOs in order to implement MVC custom. JSPs just handle page layout, Servlets manage navigation and general application control and POJOs (Plain Old Java Objects) realize your business logic, in order to keep in separated layers the "look", the navigation issues and the business.

You don't provide a lot of context but judging by your tags (which include JSP and Servlet) then consider taking a look at the Web application technology stack project AppFuse. It will generate a Web Application project for you using Maven, the project builds on top of the state-of-the-art in Web Development. The generated project has exactly the functionality you are [vaguely] describing.

How to implement a complex page flow in a Java Web application

I am trying to implement a reasonably complex page flow (100+ pages) as a traditional web application. I found a few options, but none of them are 100% convincing
Harcode the flow into the controllers, do redirects, etc. This is obviously not the best thing for maintenance
JSF not only handles the flow, but also requires to use JSF as the view technology. I don't like this lock-in
Spring web flow. The current version 2.3.1 defines flows in XML that is not easy to maintain. The upcoming 3.0 release promises to define flows with annotations in pure java, but it does not even have a timeline. Additionally the project development slowed down significantly in the past years.
GWT and Vaadin's concept is closer to a traditional desktop application then to a web application, that is really convenient to use, but it wont fit to my project.
Additionally I found dozens of abandoned projects like this: http://javasteps.sourceforge.net/
I am wondering why all these projects are abandoned, what is the way to implement a complex page flow in 2012?

Personally, I'd recommend Single Page Architecture:
Architecture of a single-page JavaScript web application?
I'm not sure if that is feasible or not with your application. I've used all the flows you mentioned above and am currently working on a single-page application and I love it. We're using Dojo on the client-side, which calls a REST API on the server. It's been pretty nice.
Vaadin is pretty solid too and is much easier to set up than just bare-bones GWT. If you have a lot of UI guys on your project that like to code in CSS and Javascript, they'll hate that approach though.
Spring Webflow is pretty solid actually. I haven't looked at it in a while, but when I was using it, it got the job done for what I worked on at the time.

This is really late but I don't see a satisfactory answer to this question and would like to share an approach I had tried in a recent project which I feel is better than the spring web flow approach which is strictly tied down to spring views. I created a SPA using angular js with Spring MVC. In angular js I did not use routers or state, rather I created a div within the controller like below
<div width="100%" id="fullertonDataPanel" ng-include="page"></div>
On the server side to capture all possible transitions from one frame(I am referring to a particular screen in the SPA) to another I created a tree of rules using MVEL . So in the database I had a structure which stored a tree of rules for every frame . The data in the MVEL expressions were being set by the various services each action invoked. Thus on any action the following steps were followed.
1) Validate the action.
2) Invoke various services.
3) Capture the data from these services and merge it with the existing data of the user.
4) Feed this captured data into collection of rules for each frame along with the details of the current frame.
5) Run the rules of the tree w.r.t to current frame and fetch its output.
6) If there is only one transition then that is the final transition. If there are 2 transitions and one is default then ignore the default transition and use the other transition.
7) Return the template name of the transition to the angular controller and set the value of the page variable in the scope of the controller.
Using this approach all my services had to do was store data in different data fields w.r.t a particular action. All the complex if-else conditions for Web Flows or any complex process definitions(like the one defined in Spring-Web Flow) were not required. The MVEL rule engine managed all that and since it was all in the database it could be changed without needing a server re-start.
I believe this generic approach with MVEL is a flexible approach which comprehensively handles the problem of a convoluted flow without making the application code a mess or adding additional unnecessary xml files.

There is a new MVC framework and web flow implementation for Vaadin component model called Lexaden Web Flow
You can try it out for your application as possible alternative.

Maintaining Clean Architecture in Spring MVC with a data-centric approach

Maintaining Clean Architecture in Spring MVC with a data-centric approach
I'm trying to map out the architecture for the front-end of a new Java-based web app (portal type application) we are making at work. I want to get this right from day one, and I would like to kick off a discussion here to help me implement Uncle Bob's Clean Architecture in my architectural design.
Here's a quick run-down of our tech stack, top to bottom (the technology isn't importance, the structure is):
Oracle Database
Oracle Service Bus exposing services using WSDLs
JAX-WS generated Java-classes from the WSDLs (let's call this the "generated service layer")
A Domain module consisting of POJOs mapped to the generated data objects
A Consumer-module exposing the "generated service layer" to the front-end application
A Spring MVC based front-end module using FreeMarker to render the views
A key point:
In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.
Attempting to adhere to Bob's Clean Architecture, I've gone back and forth a bit with myself regarding where to place the application logic, namely the "Use Case"-layer in his architecture.
Here is the approach I've come up with:
Layer 1 - Entities
Entities encapsulate Enterprise wide business rules.
This is where our Domain module containing the domain-objects lives, these are self-containing objects with minimal dependencies on each other. Only logic pertaining to the objects themselves may live on these domain objects, and no use-case specific logic.
Access to our database is exposed via WSDLs using a service bus that transforms the data, as opposed to an ORM like JPA or Hibernate. Because of this, we do not have "entities" in the traditional sense (with Ids), but a data-centric approach making this layer a data access layer, presented to the rest of the application by the Consumer-module.
Layer 2 - Use Cases
The software in this layer contains application specific business rules.
This is where logic specific to our application's use cases lives. Changes to this layer should not affect the data access layer (layer 1). Changes to the GUI or framework implementation (Spring MVC) should not affect this layer.
This is where it gets a little tricky:
Since our data access layer (in layer 1) must be kept clean of application logic, we need a layer that facilitates use of that layer in a fashion that suits the use cases. One solution I've found to this problem is the use a variant of the "MVVM-pattern" that I choose to call MVC-VM. See below for an explanation. The "VM"-part of this lives in this Use Case-layer, represented by *ViewModel-classes that encapsulate this Use Case-specific logic.
Layer 3 - Interface Adapters
The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.
This is where the MVC-architecture of our GUI lives (the "MVC" in our "MVC-VM"). Essentially this is when the Controller-classes get data from the *ViewModel-classes and puts it in Spring MVC's ModelMap ojects that are used directly by the FreeMarker-templates in the View.
The way I see it, the servicebus would in our case also fall in under this layer.
Layer 4 - Frameworks and Drivers
Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.
This layer is really just a configuration-layer in our application, namely the Spring configuration. This would for example be where we specify that FreeMarker is used to render the view.
Model View ViewModel Pattern
MVVM facilitates a clear separation of the development of the graphical user interface (either as markup language or GUI code) from the development of the business logic or back end logic known as the model (also known as the data model to distinguish it from the view model). The view model of MVVM is a value converter meaning that the view model is responsible for exposing the data objects from the model in such a way that those objects are easily managed and consumed.
More on the MVVM-pattern at Wikipedia.
The MVC-VM roles would be fulfilled in our application like so:
Model - represented simply by the ModelMap datastructure in Spring MVC that is used by the view templates.
View - FreeMarker templates
Controller Spring's Controller-classes that directs HTTP URL requests to specific handlers (and as such functions as a FrontController). The handlers in these classes are responsible for fetching data from the use case-layer and pushing it out to the view templates when showing data(HTTP GET), as well as sending data down for storing (HTTP POST). This way it essentially functions as a binder between the ViewModel and View, using the Model.
ViewModel - These classes are responsible for 1) structuring data from the data access layer in a fashion that is usable by the View and 2) treat data-input from the View. "Treat" means to validate and to break down the data so that it can be sent down the stack for storing. This layer would take form as <UseCase>VM-classes in a viewmodel package in our Spring MVC front-end module.
A key component here is the implicit binding that happens in Spring MVC between ModelMap and the FreeMarker-templates. The templates only use the model (ModelMaps), where the controller has put the data in a format it can use. That way we can make templates like so:
<body>
<h1>Welcome ${user}!</h1>
<p>Our latest product:
${latestProduct.name}!
</body>
I apologize for the verbose explanation, but I could not explain this (relatively simple) architecture in fewer words.
I would greatly appreciate some input on my approach here - am I on the right track? Does the MVC-VM thing make sense? Am I violating any Clean Architecture Principles?
There are of course many solutions to this, but I am trying to find a solution that is 1) not over-engineered and 2) adheres to the principles of Bob's Clean Architecture.
Update:
I think the key issue that puts me off here is what form the "Use case" layer takes in this application. Remember we have an MVC front-end that gets data from a data access layer. If the MVC part fits in Bob's "Interfaces adapters", and the domain models of the data layer fit in Bob's "Entities" layer, then what do I call the use case classes that implement application logic? I am tempted to just call them <UseCase>Models and put them in the MVC project, but according to Bob
The models are likely just data structures that are passed from the controllers to the use cases, and then back from the use cases to the presenters and views.
so that means my model objects should be "dumb" (like a simple Map. ModelMap in Spring) and it is then the responsibility of the controller to put data from the Use Case class into this Map-structure.
So again, what form does my Use Case-classes take? How about <UseCase>Interactor?
But in conclusion I realize that the MVC-MV-thing is over-engineering (or simply incorrect) - as "mikalai" indicates below this essentially just a two-layer applcation in its current form; a data access layer and a front-end MVC layer. Simple as that.

Whoa that was a lot. And I think you have mostly translated Uncle Bob's jargon over to your Spring Java app.
Since architecture is mostly opinion and since your question is sort of asking for one...
There are many different styles of architecture and ... most are overrated. Because most are the same thing: higher cohesion and looser coupling through indirection and abstraction.
What matters MOST (IMHO) are the dependencies. Making lots of small projects as opposed to one giant monolithic project is the best way to get "clean" architecture.
Your most important technology for clean architecture will not be "Spring MVC" technology or "Freemarker" templating language, or another Dr. Dobb's article with diagrams of boxes, hexagons and various other abstract polygons.
Focus on your build and dependency management technology. It is because this technology will enforce your architecture rules.
Also if your code is hard to test.. you probably have bad architecture.
Focus on making your code easy to test and write lots of tests.
If you do that it will be easy to change your code with out worry ... so much you could even change your architecture :)
Beware of focusing too much an bull#%$## architecture rules. Seriously: if your code is easy to test, easy to change, easy to understand and performs wells then you have a good architecture. There is no 6 weeks to 6 pack abs article to do this (sorry Uncle Bob). It takes experience and time... there is no magic bullet plan.
So here my own "clean" architecture... I mean guidelines:
Make many small projects
Use dependency management (ie Maven, Gradle)
Refactor constantly
Understand and use some sort of dependency injection (Spring)
Write unit tests
Understand cross cutting concerns (ie when you need AspectJ, metaprogramming, etc..)

My solution
So it turns out that implementing Bob's "Clean Architecture" in Java/Spring MVC is borderline non-trivial and requires more architectural facets than I originally had included.
And I could actually not find any example of implementations online.
Evidently my architecture was missing a separate module for the "Use Case"-layer as this logic should not live in the Spring MVC Web module (and not be called "*ViewModel"). The Web/MVC module is simply a detail of the application, and the application logic should be completely separated from it, and separately testable.
This new "Use Case"-module now contains *Interactor-classes which get data from the domain module (entities). Moreover, "Request/Response Objects" are needed to facilitate the communication between the MVC/Web-module and the Use Case module.
My dependency chain now looks like this:
Spring MVC module -> Use Case module -> Domain module
where every arrow (dependency) takes form as a Boundary, meaning an interface is defined in the module to the right of the arrow that is implemented where required and injected where needed (Inversion of Control).
Here are the interfaces I ended up with (per Use Case):
I<UseCase>Request - implemented in the MVC module, instantiated in the Controller
I<UseCase>Response - implemented in the Use Case module, instantiated in the Interactor
I<UseCase>Interactor - implemented in the UseCase module, injected in the Controller
I<UseCase>Consumer - implemented in the Domain module, injected in the Interactor
How it works?
The Controller takes parameters from the HTTP request and packs it in a RequestModel which it passes down to the Interactor. The Interactor fetches the data it needs from the domain module *Consumer and imposes it's application specific logic on it, then puts it in a ResponseModel and sends it back up to the Controller. The Controller then finally simply puts this (now GUI-friendly) simple data in a Map object and forwards it to the FreeMarker template which then uses this data directly and renders the HTML.
A Presenter could get involved in that last part there, making this an implementation of the Model-View-Presenter pattern, but I'm leaving that for now.
My conclusion
I ended up with more files than what is necessary this early in development, strictly speaking. However as the complexity and size of the application grows, I am confident that this structure keeps it easy for us to maintain low coupling and high cohesion. Also, the Web-module is now easily replaceable - it just delivers requests to the use-case module and receives response-objects. Moreover, each layer of the application (domain logic, application logic, and GUI logic) is separately testable, with only the View-part requiring a webserver in order to be tested.
Thanks for all advice and pointers I received here. And please comment on my solution - I don't claim that it is perfect.

Because of this, we do not have "entities" in the traditional sense
(with Ids), but a data-centric approach making this layer a data
access layer, presented to the rest of the application by the
Consumer-module.
Something seems odd to me in that part. Why couldn't your entities have ID's even if you get them from web services ?
In the Clean Architecture approach, the Entities layer is precisely not a data access layer. Data access should be a detail in your architecture, not a central concern. As you said yourself, Entities contain domain-specific business rules. Business rules, or behavior, is very different from the way you fetch your data.
Entities is where all the domain logic happens, not where you get your data from. According to Clean Architecture, you get your persisted or external data from Gateways.
One solution I've found to this problem is the use a variant of the
"MVVM-pattern" that I choose to call MVC-VM. See below for an
explanation. The "VM"-part of this lives in this Use Case-layer,
represented by *ViewModel-classes that encapsulate this Use
Case-specific logic.
ViewModel clearly refers to a View, which is a presentation artifact -another detail. Use cases/Interactors should be devoid of such details. Instead, Interactors should send and receive delivery mechanism-agnostic data structures (RequestModels and ResponseModels) through Boundaries.
I understand that this is a custom pattern of yours and doesn't involve a reference to a presentation framework, but the word "View" is just misleading.

Architectural Differences in Java MVC Web Frameworks

I'm trying to choose an AJAX-friendly Java framework for my first web application and am interested in first
understanding the architectural differences between the different flavors that are out there.
I like the concept of MVC frameworks, and so am primarily considering the following:
Any JSF variety (ICEFaces, RichFaces, PrimeFaces, etc.)
Spring Web Flow
ZK
Wicket
I've downloaded each of these projects and tried to follow their samples/tutorials, and there is
so much information to ingest I figured I'd take a breather and come here to cover some preliminaries
first.
I'm interested in how each of these frameworks implements the MVC pattern. Obviously, something rooted
in JSF (like ICEFaces) is going to have a different architecture than Spring. I'm sure that this is a
huge question, so I'm not looking for a full-blown tutorial on each of these frameworks; I'm just
curious as to what sort of artifacts (Java sources, XML config files, etc.) a developer has to write in
order to build a single AJAX-driven page using these. I'm interested in the differences to their approach,
nothing more.
For instance, I would imagine that each framework at some point uses a FrontController (or its likes) to
map HttpRequests to the right Controller implementation. That Controller (bean) would then need to do
some processing, possibly hit the database for some information (using ormapping and forming the Model), and
then construct a View/HttpResponse to send back to the client. This is an oversimplification I'm sure, but
there has to be an easy way to explain the high-level architecture for how each of these frameworks accomplishes
that.

Struts uses the ActionServlet (with Struts2 now its just Action) as the controller and model and jsp is the view.
For Spring MVC is achieved by DispatcherServlet which does the routing and Model is not bound to any framework related object you can use any.
JSF - UI jsp or jsf itself, Model - ManagedBean, Controller - FacesServlet.
I did some similar search for my own project a while ago, have a look at the links below:
Comparison based on multiple parameters : http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks.pdf
Difference between JSF and Struts
http://struts.apache.org/2.0.14/docs/what-are-the-fundamental-differences-between-struts-and-jsf.html
Somewhat related post
https://stackoverflow.com/questions/7633583/which-mvc-is-better-spring-or-struts
Spring and JSF
http://blog.springsource.org/2007/04/21/what-spring-web-flow-offers-jsf-developers/
Spring MVC : http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html
Best Fit For JSF Component Library: Primefaces based on my own experience
From IBM Clearing the FUD : http://www.ibm.com/developerworks/library/j-jsf1/
Hope this gives you some insight.

Have a look at Matt Raible's talk on Comparing JVM Web Frameworks here. You can also consider looking at Spring MVC and 'Tapestry`.
Also, this link gives you a matrix on capabilities of various java web frameworks.

You should also check out the Play framework. I have used it a little and really like it.
It is very easy to get started with minimal configuration (reminds me of Rails).
http://www.playframework.org/

What Are the Benefits of Struts

I recently added Struts 1.3 to my application on Tomcat. Here are my observations,
MVC. Servlet/JSP does this fine for me, where JSP is the view and servlet is the controller. I don't see any benefit to get the mapping from an XML file since our mapping is very static.
Action Form. I can see some benefits of action form but not huge.
Tags. I already uses JSTL and don't see any advantage using Struts tags.
So I am thinking about removing Struts. Anyone can think of any other benefits I might have missed?

Personally I myself prefer jsp/servlet but theoretically Struts has some advantages.
Here are some of the advantages i know of, you might have mentioned them already, but i thought it would be better if i list all of them here.
Centralized File-Based Configuration.
Struts values/mapping are represented in XML or property files. This loose coupling means that many changes can be made without modifying or recompiling Java code, and that wholesale changes can be made by editing a single file. This approach also lets Java and Web developers focus on their specific tasks (implementing business logic, presenting certain values to clients, etc.) without needing to know about the overall system layout.
Form Beans.
Bean Tags.
Struts provides a set of custom JSP tags that let you easily output the properties of JavaBeans components.
HTML Tags.
Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This bean/form association serves two useful purposes:
It lets you get initial form-field values from Java objects.
It lets you redisplay forms with some or all previously entered values intact.
Form Field Validation.
Struts has a robust, extensible validator that can be used to uniformly validate your form fields. This validation can be performed on the server (in Java), or both on the server and on the client (in JavaScript).
"Plumbing code" contained within the Struts framework.
Mapping HTTP request parameters to Java objects is handled by Struts, for example. You don't have to do it. This allows you to focus more on the domain problem instead of building infrastructure.
Good documentation & plenty of books.
If you have to leave the project and/or someone else has to maintain it then using a well known and well documented framework will make that job much easier. A homebrewed framework just can't match that.
Broad user testing.
Since Struts is used in plenty web-apps the framework will get looked at by many more eyes than anything you could write alone. Usually, but not always, that means any problems you have will have been seen by someone else (and hopefully resolved) first.

Large knowledge base.
I agree that this perhaps isn't as valid as it used to be but Struts has been used in a lot of projects over the years. From a maintainability point of view using a well known framework makes it easier for other people to work on your application and also help build your own resumé for the future. Right now most development is either in the component based space (like JSF, wicket, tapestry) or in the rails-like space (like rails, grails, lift) but the struts arcitechture is still in use and valid.
You didn't say if you develop in a corporate environment or not, for a personal project perhaps the maintainability issue isn't that much of a problem.
If you decide that struts suits you well you could also have a look at stripes, a struts-like framework that's based on the same concepts but is less verbose when it comes to configuration with more sensible defaults, less xml and support for annotations.

I totally agree with your points about Struts - personally I think its time has come and gone.
I went off Struts in v1 (which I believe is nothing like the latest versions) because the form beans where just added boilerplate code to write.
Since then most applications I've worked on are using Spring as the dependency injection framework, which has made Spring MVC the natural choice - it's simple, straight forward and minimal.

Not just for Struts. But some points to consider for using a framework:
Standarization.
Specialized IDE or plugins for your favourite IDE.
Portability. For example, someone can develope a portlet for integrate your existing struts application in a portal server.
Internationalization.
The most important for me:
You dont have to worry about the issues on the struts code, just upgrade.
You can focus your work in business logic.

Struts is Open Source--
Large Community----
Number of Books available-----
Proven FrameWork----
Popular framework-----
Available since 2001----
+----
the features mentioned above...........
but when u r using struts,the better choice is struts2.

I think your feeling about removing Struts is a sound and understandable reaction. Struts just doesn't seem to do very much for an application.