Is there any java cms for websites which uses spring hibernate annotation , which can make building sites easy.
Like user registration from with fields , login with spring security and some basic functioanlity.
Actually i am not sure what product i want but i will tell you the bsic requirement.
I am looking for something where i can select e.g registration form fields , login with spring security , user can edit those fields as weel .
forgot password thing , confirm email address and a model all java spring files are created automatically and from there i can add my new features.
Because these things are basic in every web application and there has to be easy method to generate those things
The Magnolia CRM (Magnolia Community wiki) has a module called Blossom that provides Spring integration for Magnolia. (That works for Spring 3 too)
Magnolia store its Content in Java Content Repository and not in a Data Base. That works very well for the cms content, because Mangolia provides a good Api for accessing it.
If you have your own business domain model and want to store it in a Data Base, you can add your JPA / Hibernate functionality like you do in "normal" Spring applications. (or like Sean Patrick Floyd suggested: invoke an other layer/server via for example Web Service).
I have running such a System (Magnolia, Blossom, Magnolis JCR, Spring 3, Hibernate) with a small domain model stored "outside" of Magnolia in a seperate Database, and it worked very well. (But at the moment I am thinking of integrate the Domain Database in the JCR, not because of technical problems, but to reduce the amount used technologies/systems.)
Anyway: Magnolia, Blossom, Magnolis JCR, Spring 3, Hibernate is worth to have a look at.
I don't think there should be one. Persistence Layer and Web Layer are two separate concerns, and it would be smelly to tie one to the other. The standard way to connect those two is through a service layer, and that is usually where the application's most important logic is. A CMS could simply not provide an abstraction that makes a service layer unnecessary without seriously restricting your application.
That said: Spring Roo goes in the right direction, it automatically creates Web Controllers from your entity classes. I'd say that's probably the best you can hope for.
Related
I have been working on a Spring-mvc webapp that takes some form data and emails this accross to the administrator.
I wish to expand this webapp into a CRUD application. I have lined up some hibernate lessons and just need to do some work on my SQL skills before I start working on this.
What I need help with is the things to consider when expanding. The amount of work that will go into this means I cannot afford many mistakes when working on the foundations of this project.
The main component will be an admin panel that can work with submitted forms.
+After this the system may be further developed by adding a user database where after each form completion a user would be created.
So really the main points of my question are:
Do I just go ahead and start designing the DB and learning Hibernate?
Do I need to consider anything NOW if I wish to have user
authentication down the line?
Am I considering the most appropriate technologies? (Hibernate, mysql + Spring Security I presume for auth?)
Firstly you should learn how to design a database. Making huge changes on database after creating the application can lead serious problems.
You can set up spring security later. Just take look at here.
You can have an idea of hibernate implementation from here: a web application CRUD example shows how to integrate Spring MVC and Hibernate frameworks. Technology choice is appropriate (Hibernate, mysql + Spring)
Nowadays typical JAVA application can expose some JPA entities via REST easily. In that case in short there is e.g. persistence.xml where driver, database, etc are defined to access the database and persistence unit easily can be used in the application.
I am looking for something opposite. I.e. if somebody saw the solution where persistence relays on REST API?
Background of my question is the following.
There is an app written in some ancient technology and there is quite complex logic behind. I would like to build new JEE JPA (Eclipselink if possible) based application which could (at least for some time) use that complex logic in order to find and read data. My idea was to implement REST interface on top of old application and let the new one use REST queries in order to deal with the data. Since logic is complex I would like to avoid duplicating it and maintaining 2 branches of code in different technologies until I am fully prepared to move all stuff into modern technology.
Do you think it is possible?
You can design your Data Access Layer and the rest of your new application so that it doesn't care how the data is stored (no "bad" dependencies).
You would then need to create separate versions of the DAL, where one would fetch the data from the legacy REST app and one would use JPA. This will make it possible to start out being dependent on the legacy app, and part by part build the JPA DAL to retrieve data from a database.
I am trying to create web application that allow its users to create new forms and tables (many ERP applications have such feature). It is clear about generating and saving HTML forms and it is clear about generating new tables in database as well. But what about entities, e.g. Spring #Entity and #Repository classes.
One can try to compile then on the fly and save into the web application deployment directory, that should be possible. But is there need to update some kind of internal Spring registry of existing beans, repositories and controllers. Does Java JPA have such registry as well?
Is it possible to do such kind of thing? It is clear that it is possible to do this in php, e.g. to dynamically update yii framework application, because there is no compiled code (except, maybe, cached code) and with each new request the available paths are scanned anew. But how this happens in Enterprise Java and Spring applications?
Maybe I should look for Groovy Grails or Scala Play - they may be more dynamic languages.
More "object java storages" compatible with JPA (ObjectDB and Co) promise smoother, more natural migration with extra fields and classes. I haven't personal opinion.
EDIT: good perspective has, I think, philosophy ActiveRecord and similar. Few solutions in Java are ready. I have tried such solutions with partial success, but my project was not too dynamic (classes were stable) and we switched to clear JPA.
some ERP applications (in different languages f.e.C,Java.C#) have an idea "kernel class and additional fields", ie. Customer with all typical fields plus "Preffered color" (usually implemented in extra hidden tables). This is OK if they don't need new relations
Eclipselink has similar concept 'extra fields' in JPA area (not strict standard JPA but extension) https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
At project level, seems to be OK enter non-critical data
3 Ist hard to imagine create high count of dynamic important/central classes (tables) without radically redesigned application (proverbially version 2.0 ;) )
Sometimes I try stop and restart EMFactory with different Persistence Units (in Tomcat environment) with Hibernate and Eslipselink, but not use in production. Reset & start seems be ok, this is like rupture and new life of JPA engine. Its more like application 2.0 than small patch.
Creating multiple gemmini table sets (for different companies in the same database) is good in Hibertate and Eslipselink (prefix before table name), few dedicated lines by start, normal clean JPA use. Tested, all OK.
Once again, adding single/few tables is poorly reworked in the community.
It is an interesting discussion to "glue" together common JPA modules (code+JPA), this is done often by OSGI programmers.
Theoretically so it has to module give your tables, strongly connected in the same PU.
At the ERP application level it can be anything from "add CRM module" to "kernel + sales".
I'm an interested spectator, but i have not seen any success.
If you look in the google integrate persistence unit from parts, composite persistence unit, many programers try to reach such target.
It is like a fishing rod rather than fish (as the old adage goes).
Persistence Unit conception isn't friendly for such ideas (and is blocked in standard JPA).
I have a web app running with Grails looking after the view and controller and calling into a spring-mvc backend via the service layer (Grails app using services from spring-mvc backend). Now I need to implement Spring Security (SS) for the app.
Its at this point I'm not sure how to marry both. The backend already has a fully functioning spring security implementation but to get the Grails app to work I needed to exclude all transient spring security dependencies coming from the spring-mvc app and go with a purely Grails solution (maybe this was the wrong decision?). The backend already has User and Role objects complete with a user_roles table modelled via a joinTable annotation in the User domain.
Questions:
Am I on the right track? Ignore everything from java backend in terms of SS bar using its data objects and go with Grails impl with SS plugin? I've seen posts saying I don't even need to use the Grails plugin but they're quite old now and I'm not sure how I'd annotate my controllers and services.
If Grails is the way, I'm not sure what I need from by backend and what I need to reimplement/extend in Grails.
I have an SS extended User and UserDetailsService in the backend app but cannot use them as I've completely excluded all the SS jars that they depend on so I presume I have to roll my own?
So I implement a UserDetails object, a custom UserDetailsService (should this implement the GrailsUserService?) and expose the latter as a bean and everything should work? Wishful thinking maybe.
Any guidance, even at a high level would be much appreciated as I'm struggling to determine my approach at this point, never mind implementation.
I have managed to implement what I need to get this working. I have gone with the purely Grails approach and so have my own implementation of userDetails, an instance of which is returned by my custom userDetailsService.
One thing to look out for, if getting a proof of concept working, is to make sure that you are reading back your password in the format you are storing it in. Spring Sec will hash your password to compare against what is in your database and so you will not successfully load a user if your storing your password as plain text. One way around this is to use the following config in resources.groovy.
passwordEncoder(PlaintextPasswordEncoder)
But of course I would not advocate this as being the long term solution from a security point of view.
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.