I have a basic question--apologies if this not the right forum. But I thought this question might be useful to others as well as myself.
I want to design Web Apps on Spring more quickly and cleanly than I currently do. I have programmed in Java, C++ and other OO languages for 10 years. I have used several frameworks, and mapped objects to databases, and have designed databases themselves.
But when I turn to design webapps, I sometimes find myself confused. It seems that online use-cases are most naturally described in terms not of objects, but of WEB PAGES AND THEIR FLOW. "The user gets a greeting page." "The user hits return and is served a Login Page." "On the Login Page, the user enters her name, address(es), and ID.", and and so on. The flow of web-pages, not business objects, or persisted objects, would seem to me the first thing of design.
Where can I find a clear methodology that proceeds from web page flow, rather than object-level design? Or least page-flow in conjunction with OOA/OOD? Spring WebFlow looks interesting as a tool--but are their design methodologies described elsewhere?
At stake are several things. For example, the definition of Controller responsibilities. How many would be used in the above example? Perhaps a GreetingController and a LoginController? How are command objects defined? Command objects or form objects are by no means business objects, it seems ot me.**
1. Tell me if I am entirely wrong about this.
2. Any references to books, webpages, blogs, etc. on web-page driven would be greatly appreciated.
Opinions of any kind are most welcome!
**not to distract with trivia, but this issues seems to me to give rise to inconsistencies in the Spring online documentation. A command object, if I remember correctly, is, in one example, called "Person." Corresponding form actions in html or jsp pages are, in this example, labeled "Person". References are recurrently made by disjunction--for example, "a command or form object," or "command/form object." That dichotomy seems problematic. "Person" is not a command. Nor, in my above example, is the user's Login data (for example, 1 name and 2 addresses), a business object. This is not just a matter of semantics. As Robert Martin has pointed out, there are difficulties with the Command-Pattern falling short of purely object-oriented design. Which is fine by me, but then I would prefer that all html actions, and associated Commands, be just that--actions--command: "displayLoginData", "DisplayLoginCommand," etc.
You bring up great points. There is a weird thing that happens when you get to web apps. I personally have disliked the view of request-response. I always think in terms of actions/events. I want to save a Person, or list all my Friends, or add an item to my order. Not request a page to display my order in a form, which I can submit as a POST to a new request to save the changes or additions.
Still, in many ways you can build a Spring Web App with your domain objects, but it does rely on you retrieving exactly the amount of data you need for that request and then have the jsp render the data with jstl. For forms I have never done any special bindings or command object. It has always been the Spring form tags where the inputs are assigned to properties of my object I put into the Model. and when the form submits that domain object is passed into my Controller.
With a REST approach you do take a request for a resource driven design and one of the first steps is to represent your domains via REST URI calls.
Mark, thanks a lot, this is very interesting. (I have been crazy-busy at work).
I now understand what you are saying about your use of form tags and domain objects. That is a good way of thinking about it.
And your idea of using AJAX with a REST-ful interface sounds very interesting. I have done one REST-ful interface (in Java Jersey with annotations) which I used for a webservice, and I was impressed with the whole concept, and the way it exploited the capabilities of HTTP. It made a lot of good sense. I will definitely have a look at those frameworks you mention and a think some more about what you are saying. I had not thought of using Ajax to pull up data from REST interfaces.
Here is a basic question I can now ask about Spring development. When you design a Spring webapp, do you do the webflow logic of controllers and views first?
I had the idea of returning, in a first iteration, blank pages with little more than, "This is the Login Page"; "This is is the Login Completed Page with the Login Data On it"; "This is the You are finished page." That way, one could first check the flow of the application, then, when that was done, design the objects underlying it which supply the data to those pages.
Chicken or the Egg. Yeah, where to start. I do a lot of thinking before I go to any pages or code. A lot of time I think about the features that I want, which draws out the domain. Do I am mostly a domain driven approach. On this app I spent the first part thinking about the domain model I was going to use. I am not using a RDBMS, I am using Neo4J Graph Database, so I had to think of my nodes and relationships. And properties of my nodes and if I needed any properties on my relationship. Then I had to figure out if I had to have vertices because of complex relationships that required three nodes to define it. For instance, and event has items a user signed up to bring, and I have an Event, User, and Item node that all three had to be combined as the relationship of this is an item that a user signed up to bring to an event.
After that I started on my Repositories(DAO) using Spring Data Neo4J. I created Integration testing to see if my model was correct and I could save stuff. I was brand new to Neo4J and Spring Data so I had a lot to learn first.
Then I thought about the actions needed and defined REST URIs for those actions. Then started building the Web Controllers and some basic html. I actually used a product from JetBrains called WebStorm, so just html no serverside code. Just to learn Html5 and CSS3 and how to get my layout how I wanted it, (It was also this time that I was whiteboarding what my views should look like. I then worked on some JQuery and Spring Security stuff, just so I could get the page to display, then be able to login. Then I added the Support overlay form and got that working, then an About Us overlay page.
So, it really is an it depends answer, this is what worked for me, but going with another approach isn't wrong either.