Im new to Wicket and Hibernate. I have watched the youtube videos and read som chapters about Hibernate. I still have a question that I need to know before Im able to use Hibernate:
In wicket we have Application.java (for all the common things) and a java file for eache "page" in the application, for instance login.java, register.java etc. What should go in Application.java and what is good programming practise when using Hibernate in Wicket?
All the examples I have seen is ither with other frameworks like Wicket togheter with Spring or examples using just one file, the Application.java fil. Gess Im comfused and really miss an example using at least Application.java, one class file and one .java file for som function like saving forms, retriving db etc..
I dont know if its important, but Im using Netbeans in this project.
Any tips welcome
In my opinion the best way is to keep the persistence layer away from the presentation layer (in order to achieve a clean MVC architecture).
In this case this means you should put your Wicket related initialization logic in your Application class (more specifically WebApplication, since you are discouraged from subclassing Application directly) and put the persistence related logic in your DAO-s (preferably well encapsulated in a service layer).
You can find more information about the DAO pattern in the DAO Pattern and about transaction based persistence with Wicket, Spring and Hibernate here
You should create DAO - class with main functions (geting, saving, updating objects) and create instance in WebApplication class. For example you have:
public class WebApp extends WebApplication {
private final MyDAO myDAO = new MyDAO();
public MyDAO getMyDAO() {
return myDAO;
}
init(){
...
}
...
}
and in page classes you can get this instance using
((WebApp)Application.get()).getMyDAO()
P.S.
And please, don't use additional component.. only hibernate + wicket. I Agree with Paarth, if you don't know wicket and hibernate you should start from tiny test project for wicket and for hibernate
In this case, when you are new to both Hibernaet & Wicket, try learning one after another.
Make some demo/POC project for Hibernate with Simple Java program.
Then go on Wicket, make some demo on that also.
Then make some small web application, integrating Hibernate and Wicket together as you have learned.
You should be going easy, thoroughly.
Hibernate should be pretty easy if your OOP concepts are clear. I don't have idea about Wicket, so can't say on it.
For implementing Wicket with Hibernate, take a look at Databinder (http://github.com/n8han/Databinder-for-Wicket/). It is an excellent, thin layer between Wicket and Hibernate (among other data handlers).
However, Databinder's core was written for something like Wicket 1.2 and hasn't been updated in quite some time. Several people say they're going to update it (including myself) and they haven't.
So, Databinder is a great model of how to use Wicket and Hibernate. However, in practice, it has several flaws that need to be addressed.
For a quick fix, check out Databinder version 1.3.2.CAST at http://comp.cast.org/maven2/ which at least brings Databinder in line with the latest Hibernate.
For a complex and incomplete, but powerful, implementation of this code, see http://code.google.com/p/cast-wicket-modules/
For a completed project that uses those modules, see https://code.google.com/p/udl-curriculum-toolkit/
All of those links are works in progress, but a place to start.
Related
We are currently planing our project and decided to use Vaadin. Right now we are a bit stuck figuring out how we could organize our code quite well without spending to much time. It seems MVP is a good practice for vaadin, but we are all new to the framework and it seems that quite a few people are really struggling with it. During our research we noticed that there are only very abstract tutorials and outdated frameworks. In the vaadin book also a layered architecture is recommended which we wanted to use. Our application isn't too complex (comparable to a usual businessbackend).
Is there maybe an elegant and simple solution to decouple the view,while also using the Designer?
We are also planning to use Spring Security and UI.
Thanks in advance
In my latest project I'm using Spring alongside with Vaadin and, although lots of boilerplate is added, your classes will be smaller, better organised, with single responsibility. In my case, I follow the architecture below:
Layout: class that contains the UI elements and it's design/layout.
Controller: handles all the events and user actions that a layout has. A controller only responsible of a single layout.
View: View class is the main "controller" for a specific URI fragment. If it gets too complex or with subviews, a controller class is created and injected.
Service: contains the business logic of the data. While the "Controller" handles the user interaction, the service is responsible of the business logic and data.
Repository: SpringData JPA repositories. Implement the CRUD operation and custom queries.
Model: Database entities.
Extra packages:
Event: I recommend using EventBus alongside the application.
Helpers: For that stuff that you don't know where it really fits in.
Configuration: Configuration and properties fetched from application.properties (if using SpringBoot).
Using this pattern you'll avoid ending up with spaghetti code and mixing up responsibilities on the same class. Regarding the Vaadin Designer, with this pattern it's completely independent as your layout can either be pure java or the pseudo-html.
I am trying to build a basic CRUD application with NetBeans 7.4, JSF, PrimeFaces and JPA using MySQL.
I have successfully done this by using the NetBeans wizards. I want to do this from scratch, no wizards.
There seems to be a lack of support for the combo of JSF, PrimeFaces and JPA. When I say "lack", I mean a full example (I might be asking too much), without using the CRUD auto-gen templates/classes AND shows actual queries coded and passed to the datatables(primefaces). YouTube is full of non-English speaking examples using Hibernate (not JPA) and other examples that show flashy GUI's with no code.
So far I understand you need an #Entity class (provides the physical build of the tables), a Controller (serializable) and the .xhtml web page to show the datatable.. what else? Also, I'm not seeing any posts or examples where queries are using with JPA/JSF and how they are tied together (in one place). I need to connect the dots here so that I can leverage JSF/JPA to create simple queries to populate my PF DataTables. I've read the blogs and I've googled the intranets until I'm blue in the face. Sending me a list of URL's to read to learn about each product is something I've already done. I get what they do independently, but am looking for the "How do they all connect" answer with maybe some basic code examples!! :)
Since version 11, PrimeFaces comes with a JpaLazyDataModel which you can use with your p:dataTable. In its simplest form to be used like:
new JpaLazyDataModel<>(MyEntity.class, () -> entityManager);
See also:
DataTable documentation on JpaLazyDataModel
Source code
I think this should help you:
http://www.tutorialspoint.com/jsf/jsf_tutorial.pdf
Tung
look.If you need an example about CRUD operation using JPA/EJB as Model layer and JSF as view layer,you can see the follwing example:
http://uaihebert.com/?p=834
also my own blog is based on many examples explaining this.These examples are using JPA2/EJB3 as model and JSF2 and primfaces as view you can see
http://jsfspotlight.blogspot.com/2013/05/jsf2ejb3-preparing-your-environment.html (this post for explaining how to prepare your environment before developing EJB/JSF Applications
http://jsfspotlight.blogspot.com/2013/05/ejbjsf-master-detail-web-application-in_25.html
(in this post i explain in details how to create EJB/JSF master_detail Application including what you need about connecting model and view layers)
explore the blog for more examples
Try this archetype which will create you an example and then check how it is implemented: https://github.com/ignl/happyfacescrud. You will learn about Spring, Spring security, Spring WS, JPA and Hibernate, Spring data and QueryDsl for easier querying, and custom JSF components which will make you very productive jsf developer.
I am looking for some framework in java which can directly create html forms from database tables for crud operations on DB?
Spring Roo builds entities, pages and controllers based on Spring MVC,JPA. It can detect changes in the database. It is interesting that leaves no dependencies at runtime so, elements can be modified as regular Spring MVC elements, or you can add your own controllers, views, etc.
It has its limitations, of course, but it can be useful.
Would this work for you? http://incubator.apache.org/isis/index.html
Telosys Tools (an Eclipse plugin) can generate a full Spring MVC web application
from an existing database.
See the tutorials : https://sites.google.com/site/telosystutorial/
( if necessary the templates are customizable )
Maybe Spring Roo can help you:
http://www.springsource.org/spring-roo
http://static.springsource.org/spring-roo/reference/html/base-dbre.html
I think this is a big missing type framework in java. Roo works quite well, but it generates many files for each entity and seems to hava problems when you want to edit/remove some of them (at least it happened when I was trying).
I would like something like django admin, it should generate the page dynamically for each entity, probably with a view class describing the view.
For customizing a view even further it should follow a convention like:
views/domain/Entity.jsp -> replaces the whole view for the entity
views/domain/Entity_fieldname.jsp -> used as template for the field
Same thing for controllers, in roo there are many class that do almost the same thing. Why not use a default controller, and if the user defines a controller related to a entity, he could override the methods.
Of course this is not detailed enough, but I think pure java can improve a lot in making simple CRUD screens easy.
At least, this is the open source side. Inside business there are frameworks for CRUD, sometimes similara to this I describe. The hard part is making this framework decoupled from the other tools.
NetBeans can generate JSF pages based on your entities to do basic CRUD operations.
How-To: Generating a JavaServer Faces 2.x CRUD Application from a Database
try this:
barahisolutions.com/code-generator.htm
Its a Swing based code generator to reverse engineer databases and generate HTML forms ,entities,daos.
I have created a java based tool called Enfacade, that will generate CRUD screens from your DB tables.
The screens are data grid based and they will allow multiple grids to give one-to-many functionality.
You can then deploy to any java web application server using the runtime engine.
I have been handed a large Spring - Hibernate project and have been told to go through the code and figure out how it works.
I have been able to run the project in JBoss and access pages locally, but I have no idea how to figure out how the program is layed out, as I have no web programming experience.
I have been told that it is "pretty simple" and is a "normal Spring-Hibernate project."
Any idea where to begin?
Well, for starters, you'll really need to learn at least the basics of how these frameworks operate. Here's a tutorial on Spring MVC, and here's a Hibernate tutorial.
You'll need to identify the classes that create the various layers; there are certainly going to be Controller classes (which take a web request and figure out how to construct the response) and DAO classes (Data Access Objects, which manage saving and retrieving data).
There will probably be JSP files which describe the views; that is, what the user sees. The HTML code that builds the actual web pages should be here.
My suggestion: pick one simple page and follow it through. Where's the JSP that sets up the HTML for that page? Where's the controller it gets POSTed to? Does that controller call a service class or a DAO? A validator? Etc. -- type in one bit of data and follow it all the way through. It will help to have an IDE that shows you the structure of the application, and allows you to go into debug mode and step through the code.
Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently trying to get into the Java EE development with the Spring framework. As I'm new to Spring, it is hard to imaging how a good running project should start off.
Do you have any best practices, tipps or major DO NOTs for a starter? How did you start with Spring - big project or small tutorial-like applications? Which technology did you use right away: AOP, complex Hibernate...
Small tip - I've found it helpful to modularize and clearly label my Spring xml context files based on application concern. Here's an example for a web app I worked on:
MyProject / src / main / resources / spring /
datasource.xml - My single data source bean.
persistence.xml - My DAOs/Repositories. Depends on datasource.xml beans.
services.xml - Service layer implementations. These are usually the beans to which I apply transactionality using AOP. Depends on persistence.xml beans.
controllers.xml - My Spring MVC controllers. Depends on services.xml beans.
views.xml - My view implementations.
This list is neither perfect nor exhaustive, but I hope it illustrates the point. Choose whatever naming strategy and granularity works best for you.
In my (limited) experience, I've seen this approach yeild the following benefits:
Clearer architecture
Clearly named context files gives those unfamiliar with your project structure a reasonable
place to start looking for bean definitions. Can make detecting circular/unwanted dependencies a little easier.
Helps domain design
If you want to add a bean definition, but it doesn't fit well in any of your context files, perhaps there's a new concept or concern emerging? Examples:
Suppose you want to make your Service layer transactional with AOP. Do you add those bean definitions to services.xml, or put them in their own transactionPolicy.xml? Talk it over with your team. Should your transaction policy be pluggable?
Add Acegi/Spring Security beans to your controllers.xml file, or create a security.xml context file? Do you have different security requirements for different deployments/environments?
Integration testing
You can wire up a subset of your application for integration testing (ex: given the above files, to test the database you need to create only datasource.xml and persistence.xml beans).
Specifically, you can annotate an integration test class as such:
#ContextConfiguration(locations = { "/spring/datasource.xml" , "/spring/persistence.xml" })
Works well with Spring IDE's Beans Graph
Having lots of focused and well-named context files makes it easy to create custom BeansConfigSets to visualize the layers of your app using Spring IDE's Beans Graph. I've used this before to give new team members a high-level overview of our application's organization.
Focus first on the heart of Spring: Dependency Injection. Once you see all the ways that DI can be used, then start thinking about the more interesting pieces like AOP, Remoting, JDBC Templates etc. So my best bit of advice is let your use of Spring grow out from the core.
Best practice? If you're using the standard XML config, manage the size of individual files and comment them judiciously. You may think that you and others will perfectly understand your bean definitions, but in practice they're somewhat harder to come back to than plain old java code.
Good luck!
First of all Spring is about modularity and works best if one focuses on writing small components that do one thing and do it well.
If you follow best practices in general like:
Defining an interface rather than abstract classes
Making types immutable
Keep dependencies as few as possible for a single class.
Each class should do one thing and do it well. Big monolithic classes suck, they are hard to test and hard to use.
If your components are small and follow the dogmas above they should be easy to wire up and play with other stuff. The above points are naturally also true of the Spring framework itself.
PS
Dont listen to the points above, they are talking about how to do whatever. Its more important to learn how to think rather than how to do something. Humans can think, repeating something is not clever, thinking is.
I actually quite liked Spring.. It was a fresh breeze of air in your average J2EE Java Beans..
I recommend implementing the example Spring provides:
http://static.springframework.org/docs/Spring-MVC-step-by-step/
Also, I decided to go full monty and added Hibernate to my Spring application ;), because Spring provides excellent support for Hibernate... :)
I do have a DON'T however, which I learned the hard way (product in production)... If you only implement the Controller interface, and return a ModelAndView object with some data as provided with the interface, Spring does garbadge collect those resources, for tries to cache those data. So be careful to put large data in those ModelAndView objects, because they will hog up your server memory for as long as the server is in the air as soon as that page has been viewed...
Start here - I actually think it's among the best Software Dev books that I've read.
Expert Spring MVC And Web Flow
Learn the new Annotation-based configuration for MVC classes. This is part of Spring 2.5. Using Annotation-based classes is going to make writing Unit tests a heck of a lot easier. Also being able to cut down on the amount of XML is a good thing.
Oh yeah Unit Tests - if you're using Spring, you BETTER be Unit Testing. :) Write Unit tests for all of your Web and Service Layer classes.
Read up on Domain Driven Design. The fact that you can use Domain Object classes at all levels of a Spring Application means you're going to have a VERY powerful Domain Model. Leverage it.
However, when using your Domain Object classes for form population, you will want to take heed of the recent security concerns around the Spring Framework. A discussion on the Server Side reveals the way to close the hole in the comments.
A good way to get started is to concentrate on the "Springframework". The Spring portfolio has grown to a big pile of projects around various aspects of Enterprise Software. Stick to the core at the beginning and try to grasp the concepts. Download the latest binaries and check out Spring's petclinic example once you are familiar with the core. It gives quite a good overview of the various projects SpringSource has to offer.
Although the documentation is very good, I'd recommend a book after you grasp the concepts of the core. What I've found problematic with the documentation, is that it's not in depth and can't give you all the details you need.
"...Which technology did you use right away: AOP, complex Hibernate..." - I'd say a better question would be to ask what people did not use right away. I'd add the examples you cite to that list.
Spring MVC and JDBC template would be my starting recommendations. You can go a very long way just with those.
My recommendation would be to follow the Spring architectural recommendations faithfully. Use their layering ideas. Make sure that your web layer is completely detachable from the rest. You do this by letting the web tier interact with the back end only through the service layer.
If you want to reuse that service layer, a good recommendation is to expose it using Spring "contract first" web services. If you start with the XML messages that you pass back and forth, your client and server can be completely decoupled.
The IDE with the best Spring support is IntelliJ. It's worth spending a few bucks.
Whilst its been years since I have used spring, and I can't say I am a fan of it, I know that the App Fuse tool (https://java.net/projects/appfuse/) has been helpful to help people bootstrap in terms of generating all the artifacts you need to get going.
Spring is also very much about unit testing and therefore testability of your classes. That basically means thinking about modularization, separation of concerns, referencing a class through interfaces etc.
If you're just looking to dabble in it a bit and see if you like it, I recommend starting with the DAO layer, using Spring's JDBC and/or Hibernate support. This will expose you to a lot of the core concepts, but do so in a way that is easy to isolate from the rest of your app. This is the route I followed, and it was good warm-up before getting into building a full application with Spring.
With the release of Spring 2.5 and 3.0, I think one of the most important best practices to take advantage of now are the Spring annotations. Annotations for Controllers, Services, and Repositories can save you a ton of time, allow you to focus on the business logic of your app, and can potentially all you to make all of your object plain old Java objects (POJOs).