I want to make a Android Application of grocery stores. I have an existing Wicket Application deployed on server which I want to use in my Android Application for request handling. Is it compatible to use wicket application for android part.
There are 2 ways:
Use existing Wicket Application for request handling from Android Application. Can some one suggest me is this possible or is this the right way? If yes how can I achieve this and some tutorials are most welcome.
Second thing I thought about is integrate Spring with Wicket and migrate all my service classes to Spring and then use those spring service classes for Android Application. This approach is little costly and time consuming. But if first aprroach is not so good, I might think of opting this. So any tutorial on this part is also welcome.
Any help or advice appreciated. Thanks in advance !
I would definitely suggest to choose some sort of option 2. It doesn't really matter if you migrate your services to Spring, EJB or whatever, but the separation of services (or business logic or whatever you want to call it) and the view (or presentation or layout or...) would come in very handy in this case.
I firmly believe in the saying "premature optimization is the root of all evil", meaning that you should really skip any additional layer or indirection you simply don't need. However, if there actually is a use case which justifies a separation into different layers (or abstraction levels or...) you should tackle it as soon as you can. You will benefit a lot from it later on.
Just think of the Wicket application and the Android application as two different presentations of your grocery store. If you clearly separate the business logic from the presentation and make it accessible via HTTP (be it RESTful, SOAP or whatever way you prefer), you can easily imagine building an iOS, Windows Phone, you-name-it presentation of your grocery store without touching the core itself.
Related
We are green fielding a mobile web app against an existing Java web app --the database of that app, at least.
We are only using the database of the original app because the original app is built on a custom ORM solution and Struts 1.1 that is showing its age. So this is going to be a bit of a proof of concept for what can be done with modern tools.
We have decided to utilize JQuery mobile on the front end to leverage device cross compatibility. On the back end we are going to go with JPA for now...maybe moving to Hibernate down the road. But we'd like to expose our model with a RESTful service to kill two birds with one stone (the original app interfaces with a number of third party's that we'd like to give access over a simple REST interface that happens to have a lot of overlap, data wise, with the mobile module.)
So, the question is which controller layer will best tie the JQuery mobile front end with the RESTful back end?
We'd like a controller framework that:
Is not too intrusive. i.e. we don't have to lock ourselves into that particular implementation because of hard set dependencies spread all over the code.
Is annotation based or heavy on convention over config. or both so we are not writing reams of XML glue
Doesn't bring along cruft that we won't be using... i.e. it sticks to the controller layer as much as possible
Can handle REST from one end and AJAX from the other without too much trouble
The larger the community the better
The simpler to get up an running without compromising any of the other points, the better.
We've begun exploring Struts2, SpringMVC, Stripes, Play! etc. but I am hoping for some sage advice from the erudite SO community to help narrow the field.
If you need anything clarified, I will be happy to do that.
It seems to me that you're searching in the wrong direction.
Your Java App is producing JSON/XML through REST web services.
Your jQuery client is consuming those web services to publish them to an interface
You seem to search a controller server side. Why? Producing REST web services is not the only goal of a REST server?
Take a look at BackboneJS — it's not the only one in the category, but the one I know better — it's a client-side controller. It fits perfectly with jQuery and allows to access REST resources with HTTP verb — GET, PUT, DELETE, POST — in a compact and generic way.
If you choose so, I'll help you further.
We are developing a widget based web application in Java (UI looks like http://pageflakes.com). We ping about 20 APIs, analyze and present some statistics (one API result per widget, so 20 widgets in total). We want to use jQuery for AJAX communication for the widgets. Since our previous projects use JSF, we started off with it, but observed that AJAX communication for widget based approach doesn't go well with JSF. We are thinking of going with REST based design, so that we can re-use the services created for each widget for mobile based scenarios in future. Can you suggest a good architecture stack for this?
I think wicket is a good choice. You can find an example of how to create restful urls here. I can't say anything about JSF as I always kept myself away from it (for some reason I've never liked it).
Stay away from Tapestry 5, unless you have suicidal tendencies.
I would also suggest you to use JRuby or Clojure, but I think it might be a long shot.
I'm about to start developing a large-scale system and I'm struggling with which direction to proceed. I've done plenty of Java web apps before and I have plenty of experience with servlet containers and GWT and some experience with Spring. The problem is most of my webapps have been thrown together just to be a proof of concept and what I'm struggling with is what set of frameworks to use. I need to have both a browser based application as well as a web service designed to support access from mobile devices (Android and iPhone for now). Ideally, I'd like to design this system in such a way that I don't end up rewriting all of my servlets for each client (browser and phone) although I don't mind having some small checks in there to properly format the data.
In addition, although I'm the only developer now, that won't necessarily be the case down the road and I'd like to design something that scales well both with regards to traffic and number of developers (isn't just a nightmare to maintain).
So where I am now is planning on using GWT to design the browser-based interface but I'm struggling with how to reuse that code with to present the interface (most likely xml) for the mobile devices. Using GWT RPC would, I think, make it relatively easy to do all of the AJAX in the browser, but might make generating xml for the mobile phones difficult. In addition, I like the idea of using something like Hibernate for persistence and Spring Security to secure the whole thing. Again, I'm not sure how well those will cooperate with GWT (I think Hibernate should be fine...)
There's obviously a lot more to this than I've presented here, but I've tried to give you the 5-minute overview. I'm a bit stumped and was wondering if anybody in the community had any experience starting from this place. Does what I'm trying to do make sense? Is it realistic? I have no doubt I can make all of these frameworks speak the same language, I'm just wondering if it's worth my time to fight with them. Also, am I missing a framework that would be really beneficial?
Thanks in advance and sorry for the relatively broad question...
Chris
I'll be pretty specific here since I have some related experience. Not all of what I'll write will apply, but I'm hoping something does.
My 1. advice would be to keep any code that's directly dependent on any framework as "stupid" as possible. If you can, consider such code more or less disposable (implementation wise, API contracts exposed to clients needs to be stable of course).
Focus on what makes your application unique, and try to make that independent of GWT etc. The facade pattern is something I can recommend - keeping the app-specific logic behind one and exposing it by wiring the presentation layer with it has served us well. If your back-end depends on third party infrastructure (via web services etc), decouple those dependencies from your code with the adapter pattern.
I have spent most of my working time during the past 5 years on building something that matches what you described in many ways. Today it's more an app framework then an app - it has a few different browser interfaces (WAP/standard web+ajax/Facebook app), an interface for 2-way SMS usage, and a REST/XML interface for thick mobile clients - BREW, iPhone, Android and Blackberry.
When it comes to frameworks, for persistence, we have used Hibernate. All the different pieces of code are tied together with Spring. The browser interfaces have been ported from Struts (1.x) to Wicket. The SMS and mobile client interfaces are built on top of Restlet.
Using multiple different presentation layer frameworks (such as Wicket and Restlet in our case) has not been a problem, as long as that code is kept lean and business rules are kept out of it (to the extent possible). There is nothing that says that your browser interface has to be packaged into the same WAR as your mobile client interface - with Spring you can easily wire several web applications with the same facade. This has been helpful to us especially in allowing multiple developers to work on well isolated pieces of the application.
In my opinion, trying to achieve maximal reuse of code in the presentation layer has caused more harm than good. That has always been the most volatile part of our application, beyond what we have been able to expect.
I've got an application here that I wrote many years ago that consists of a heavy-weight front end that directly queries a database server. This application runs on about 7 dedicated workstations. There is also a web-based front-end that I whipped up that shares the same feature set, and a web-based administration too for managing and reporting on the data -- they all just hit the database directly.
The application is quite simple and I understand the problem it solves very well. It could use an update, and I don't even have access to the tools necessary to work on the GUI anymore. I've been getting into Java lately, and it seems like a rewrite of this app would be a good project to get started with.
So my question then is this:
The application will require a non-web GUI, I suppose in Swing. This is necessary for very particular reasons. The application will also require a web-based GUI with the same exact features as the Swing front that will probably be deployed as a JSR-168 portlet, and a web-based administration tool (portlet also). With my previous design I ended up with a lot of duplicate code because each component had its own code base, and I foolishly used stored procedures to help to ensure that critical calculations were at least consistent.
Where should I start? I'm having such a hard time wrapping my mind around how this should all work in the Java world. I guess what I'm having the hardest time with is how do I create an application that can have both a Swing (or whatever) front-end and a web-based front end with as little duplication as possible?
Edit: I know conceptually how this can work. What I'm asking is for advice specifically related to Java technologies. Which frameworks to consider, etc.
Build a Core that contains the business logic. Use JDepend or a similar tool to ensure that it nowhere references anything swing or anything web/jsp/servlet.
Build the two UIs: For the web version pick a webframework of your choice and call your business logic from there.
For the Swing framework you have two options: access the businesslogic through webservices (you could use RMI or whatever, but I wouldn't), i.e. the logic is on the same webserver that serves the webapp (I'd probably prefer that). The alternative is to ship the weblogic with a swing GUI. Makes the coding and debugging easier, but now you have multiple points that access the db which causes headaches when you want to use caching
In any case you should only duplicate the gui stuff, once in html/css/javascript and once in swing.
Congrats on that project it will teach you tons about design and software architecture
You should have a project with all business logic.
Then, 2 separated projects, 1 for the web access, and 1 for the Swing application. those projects both calling the business logic API.
in these 2 projects, have only presentation code
Use a middle tier server.
Swing Client -> middle-server with spring-remoting -> database
Web Client -> middle-server with spring-remoting -> database
Web Client write once any MVC framework will work stripes, struts, even grails if you are brave rememder to keep it thin....
Swing Client write once using miglayout, and glazelist.
http://www.miglayout.com/
http://publicobject.com/glazedlists/glazedlists-1.8.0/
take a look at this posting.....
Java Swing: Libraries, Tools, Layout Managers
Middle-server write once using jdbc cause you have the db already..
http://www.springsource.org/
database write once using whatever you like. It seems already have this....
Obviously start with a unified code base. You might also want to consider whether you really do need multiple interfaces.
You want to make sure that your code does not have unnecessary dependencies. For instance, make you UI as shallow as possible, rather than the usual ball of mud. Avoid singletons, as they cause dependency hell.
It may seem very enterprisey to have a middle tier, but it also adds a lot of work. For a small group it is entirely pointless.
I'm teaching Java EE at the university, and this was a question a student asked. I said "no", but I wasn't really sure, so I thought I might ask you mighty developers. :)
Basically, what I'd like to do is to use entities if they were in my context: cat getters, setters, etc, so like normal POJOs. if I use an EJB using its remote inferface, the entities gets decoupled from the core infrastructure, so that's a no-go.
I thought about writing a layer such as this in my MSc thesis. If it's a dead idea, feel free to tell me. If it's not, tell me if you'd like one.
Or if there is such a tool out there, let me know!
In a basic modern world Java EE application, it is broken into various layers, where you have 4 basic layers
+--------------------+
| Presentation |
+--------------------+
| Controller/Actions |
+--------------------+
| Business Delegate |
| (Service) |
+--------------------+
| Data Access Layer |
+--------------------+
| Database |
+--------------------+
Your applications should be split into these layer right from the beginning, such that you can at any given point of time replace any layer without effecting any of it's sibling layer.
Example if you used JDBC for the Data Access layer, you should be able to replace it with Hibernate without affecting the business delegate or Database layer. The benefit of using such an architecture is to allow collaboration with multiple technologies. You business delegate (service layer) should be able to talk to a web service and handle the application processing without even going to a browser!
Regarding using JSP as the presentation layer, there are other technologies available like, velocity, freemarker, as iberck mentioned above, tapestry also has it's own rendering engine. You can use XML + XSLT also to render the UI. There are UI managing apps also available like Tiles and sitemesh, that help you integrate various techs as different components of the page and show them as one.
You can also use light weight swing components clubbed with JNLP and develop a desktop style enterprise application. All we need is a little imagination and client requirement and we can use literally anything as the presentation layer.
I've never tried it, but JSF is supposed to work better with Facelets than with JSP.
IBM has an article about it.
Ah. It seems you didnt get my question right :)
Beans are there to provide services inside an application. Lets say I'd like to develop a standalone java application with a swing gui, and from that application I'd like to use the entities present at the java ee app's scope.
That is what I'd like to to seamlessly: create entities, modify them, delete them in an intuitive way, without caring about EntityManager-detachment problems (if you call an EJB remotely and it passes back an entity object, it will be detached before return).
I dont want to develop a web application. JSF/JSP and such is strongly integrated, but in many environments a standalone client application would be better. :)
Seeing your comment in the middle, i see that you want a desktop framework over Java EE.
The answer here is that JSF works over the servlet api. And is definitely for the web, but wait, you can still embed tomcat or jetty in your application!
The possibilities are pretty much endless, if your business layer is well defined, just build a swing layer that calls your business functions.
Also, Java EE is an API, some parts can be replaced, or you can just use part of it. The container is mostly for dealing with EJB, Servlets JNDI and other small stuff. All this can be used by desktop apps also.
So the answer depends on your specific goal and the actual design/implementation of the application.
One alternative is the Spring Framework. Spring provides its own support for binding entity objects to the view and handles the getting/setting for you once it is wired up. There are many Spring modules to pick and choose from. Spring MVC and Spring Webflow are both worth checking out. Spring MVC (IMO) is simpler to get started with, but Sring Webflow allows for more complex navigation and more scope options (ex: flow scope). If you're looking for a book Spring In Action is descent. There are some concepts you will need to tackle (such as dependency injection) in order to use Spring but it is well worth the time.
Another alternative is Tapestry5 framework.
Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server.
Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects -- and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.
The ideology behind beans is nowadays in any proper Java framework I know of. As rich mentioned, Spring is a good/great all-around business logic framework (check out its jdbc template classes, those are simply awesome - another great gem is applicationContext.xml which is ) and for view layer I personally prefer Apache Wicket.
I don't believe you should make your own but instead find a framework that suits your needs and start contributing to its code base, that way you get to start with an already formed user base and your code will get authored more thoroughly which in turn will make you a better programmer.
grails (http://www.grails.org/) or griffon (http://griffon.codehaus.org/) may be of interest
StringTemplate is written by Terrence Parr, the guy behind ANTLR. If you're interested in generating some kind of textual presentation from a model, this is very good.
I have had excellent results using it to generate XML, web pages and dot files from the same model. You write a template to render an object. That template can call other templates (including recursively), based on the data derived from the model. (q.v. Picture Functions)
Getters and map.get() are callable directly from within the templates. The model can be any POJO. ST prides itself on its strict separation from the controller, so very little logic is allowed in the templates themselves.
As with all these little languages, it's something new to learn, and may not be what you're looking for. It was a really good fit for me.