Imagine I have an Item entity and a Basket entity. The Basket may contain any number of items. The typical Spring Roo interface for the basket might look something like this:
Lets say I want to add another button to the basket list, perhaps a checkout button. What would be the best way of going about that? Also assuming I haven't yet finished with my entities and Roo might re-generate alot of stuff.
I thought about modifying the tags, but I'm quite new to MVC, spring and jsp so battling through at the moment.
I tend to treat the Roo Scaffold application as just that: a scaffold that I can build my own user interface around. I'm more familiar with the GWT-generated interfaces, but I assume the Spring MVC world is about the same.
Roo does a great job of creating all the junk necessary for maintaining the data model of an application, but a good user interface is still going to take some custom code. In the GWT world, Roo does a good job of illustrating the best practices for implementing a UI. I would suggest studying how the Scaffold application works, and then duplicating the pieces you need while adding all the custom bits as well.
Might seem daunting at first, but if it were easy everyone would do it!
Create a custom Roo controller. It would also put an entry to the menu.jspx file as well.
You can use the following Roo command for this.
controller class --class ~.web.MyCustomController
Related
I've read about how to use Spring in standalone applications but I'm not sure what should be the approach for refactoring a large code base of 120,000 lines for making the change as gradual as possible.
As far as I understand Spring won't inject anything in an object unless that object is managed by the application context. If this is true, I think I have two choices:
1- Start refactoring from the main class down, but this means complicated scenarios will appear soon.
2- Share the application context statically so that I can start refactoring the simplest things, scalating in difficulty when I'm ready.
I'm not a fan of static access so I would try to avoid that choice, but I don't know if it's a good idea to start with the huge classes that are loaded at startup. Any ideas of the best approach?
By the way, is it OK to inject Swing components until I can fix the dependencies?
I think that before approaching such a big technology change, it may be a good idea to start asking yourself if you are following the architecture that Spring guides you to have when you start using it from the beginning.
Therefore, is your application based on the MVC pattern?
If not, maybe your product is not yet ready for being refactored to
use Spring. In this case, I would suggest refactoring the product
design first, so that it complies with the MVC architectural pattern.
If yes, then I would proceed with a use-case-based approach, starting
from the use cases that required a complicated design and
implementation.
E.g. I would look for very important entity classes or business classes containing a lot of logic. This way, you can reduce the risk of doing a lot of refactoring before realizing that, for example, Spring is not a good fit for the core of your product.
After identifying the most critical use case, you can start to experiment how refactoring works on your current product by introducing Spring from end to end on a single critical scenario (user input - business logic - entity manipulation - persistence). If you are successful, then you keep refactoring, otherwise you can go back and try to understand where you need to change your current product before introducing Spring.
Of course, this works when you have some experience with Spring and you do not have to cope with newcomer's issues. If you are new to Spring, then I would recommend getting some experience with Spring before starting the adventure of refactoring such a big project.
Start simply and wire new code/class with spring. You'll amend your existing main method to initialise the ApplicationContext and load your new feature. Over time then as change requests arrive you'll refactor and migrate the existing codebase to use spring dependency injection.
After realizing that I have completely ignored the MVC pattern I have tried to utilize the concept in an application with a Swing view. I have now read most of the posts on the subject of MVC with Swing but am still a bit confused, because it is too complicated for me to grasp, and I think I need some basic clarifications so I don't set off on the wrong path.
I also wonder how common it is to use MVC in real projects. Many online tutorials seem to leave out the controller and mix it with the model, while I was confused by XSTL:s business logic capabilities. Why would you want to address a datasource from a JSP view?
These thoughts aside, my proper question is this:
If you have a Swing component, should event listener in that Swing class update the component state through calling (static perhaps?) methods in a POJO controller class, which in turn gets the appropriate business logic from the model, which is made up by POJO class hierarchy and associated persistence?
I've worked as a freelance for a long time and almost 90% of the projects were about Java Swing (Desktop applications). Also a lot of projects involved migration from languages like Visual Fox Pro to Java, it was a pain, because the hard part is not think in the logic which is already done, the hard part is take the code that is a mess and turn it into a good-looking code following the good practices and using design patterns, that's why it is a good idea to make a schema or a map in your mind how you can separate your code following the concepts of Model, View, Controller.
MVC as mentioned helps you to have a good-looking, maintainable and easy to read code, as well as you follow the programming paradigms and good practices.
View: Obviously, the part that interacts with the user (user interface), in case of Swing, your windows, frames, panels and all the code that involves the graphic components you need for your app.
Controller: Involves the core or business logic you stablish for your application, in this "layer" you should include the functionality and the "how my application will achieve the goals?".
Model: Related with the data you manage, for example, your entities and classes that represents the data you want to manage or give maintenance.
Applying MVC is not so hard, but as I mentioned, it could be sometimes a pain when you have to migrate your code from a not-applying-MVC structure to a MVC structured application. It is easier to start coding using MVC.
A way I get used to it is by using maven and separate my application into little "modules", of course, you don't need maven, I just found it useful in that moment, but in any case you can try practicing or get used to MVC by separating your application into little projects, for instance:
Java Project 1: application-data-model (contains all the code related with data management: entities, dtos, beans, daos)
Java Project 2: application-core-controller (contains all the business logic and functionality, you can use a facade pattern here if you want to make your code more "transparent" when you relate with your view)
Java Project 3: application-view-ui (contains all the panels, frames and graphic components)
Working this way helped me (and forced me) to get used to separate my code and keep an eye on what really matters to the project I'm working on. For instance, if I'm on application-data-model I'm focused in data model, I'm not thinking in business logic nor graphic interface.
Long explanation, maybe somebody could do it better, but hope I could have helped you or at least gave you a hand with this.
Best regards.
Firs the URL for basic understanding of MVC
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Now the approach to implement it in Swing applications. Don't get confused with controller functionality with the listeners functionality.
UI controls and listeners attached to them should be defined in your view classes.
On any event, whenever you need to invoke a business logic, then you need to call the controller class. Like fetching some value from the database.
Controller class should talk to your model to fetch the data and manipulate it if required.
Model classes should work on the data.
The idea of using MVC is to reduce redundant code and more manageable code. So if you are doing some calculations/manipulations then those can be moved to Controllers. Controllers can be called from different views requiring the same stuff. Similarly model can be used by multiple controllers to fetch the data.
After many problems, I have finally set up Roo with a simple example.
Now I just want to know how far should one go with Roo.
I mean likes fields, classes, everything can be done through the Roo shell.
Now, for example, I have 15 classes in my project. I'm confused - to what point should I make classes with the Roo shell and when should I leave Roo and start working like normal?
Also, Roo has its own GUI and layout design. Can we change that also?
You can also try Telosys Tools, it has been design to generate a full web application from an existing database.
It’s more flexible than Spring Roo, you can customize the model and the generator templates
The tutorial for code generation with Spring MVC and Spring Data is here : https://sites.google.com/site/telosystutorial/
I personally use ROO to generate the models, controllers and the scaffold, then I strip out a large chunk of the Scaffold so that I can put my own components in there and some of the controllers I still need to write by hand.
When you reach the point where you have an interface generated by ROO, start hacking away and only use ROO to add new domain models.
I agree with Jan. The Roo Scaffold application is just that: a structure that you can use to build your own application around, but that isn't something you'd like to expose as a client in its own right. So far I have used Roo when creating or changing the data model, and have allowed it to manage and modify a lot of the code that is necessary for interacting with the data model. But any work I'm doing outside of the model I do myself.
My advice: use Roo where its strength is, and then do the rest by hand.
Our assignment for our java project is to make a tool for kids to make math excercices. One part should be in a swing application, where the teacher can adjust settings to what the kids should make, view their results, etc...
The other part is where kids should be able to make excercices on the internet.
Now, so we thought, as we are seeing Spring in Java courses now (just starting to.).Let's make it a Maven project, and reuse the service layer + DAO, and use the same model. That way the desktop app doesn't have to use the Spring framework neccessarely. (So we thought...)
We came to the conclusion that we don't know enough about MVC to pull this off.The service layer always returns the modified object that was saved in the database after executing business logic. Now this doesn't really work with using MVC in swing (or please tell us how to use MVC the right way..), As, as we see it, the controller modifies the data while the view receives an update of the model (via observer). But that object is replaced by a total new one!
Could please someone help us out of this, or give some tips how to fix this? Double linking controller and view doesn't seem a good idea to us at all, so is there a way to fix this, or would you recommend us to go Spring all the way, even if we have yet to learn this and only have roughly 3 months to make this?
Create a layer of Model class pojos.
Set them from swing or your web app and directly pass it to Service layer[Spring module in your case] and operate on it.
On WebApp we have scope like request,session, for swing you need to maintain it manually.
Hi everybody: let me do a bit of "concept mining" here: I am involved in mantaining/extending an application whose functionality is distributed across several servers. For example, we have a machine running the ApplicationServer, another running the DataServer and so on.
This application has a Web Interface. The current UI is totally implemented in Java, and in a way that makes adding new functionality hard. One of my goals is extending this interface, and we're considering shifting the whole thing to another platform, like Rails, for example.
Problem being, the database that is manipulated by the UI (possibly Rails in the future) is also manipulated by ApplicationServer (Java).
So, my main question is: both Rails and Java can access databases through their own ORM (ActiveRecord for Rails and Hibernate or similar for Java). Is there any way to guarantee that the mappings are consistent?*
Even if the answer is a hard "no", I'd also like to hear your thoughts on how you'd approach this scenario.
I hope the question is clear enough, but warn me if it isn't and I'll edit accordingly. =D
*Edit: per request, I'm extending this explanation: what I mean is, how to make sure things don't break when someone needs to add a new field to the database and edits the Hibernate mapping because of it? I know that Rails "guesses" the entity attributes pretty much by itself (making things easier), but I was wondering if there was some "magical way" to "connect" the ActiveRecord directly to the Hibernate mapping.
Depends on your case and how important it is to actually ensure that things won't break. I would probably code the Rails app to do its best, and then write a good set of db integration test cases for Rails to test against breakage.
Because Hibernate needs a mapping conf whereas Rails uses the database layout directly, it's best to do the db changes on Hibernate/mapped Java class side and then run the test suite on Rails side after changes.
this might be coming too late to the party, but ActiveJDBC is an ActiveRecord- like implementation in Java which reads metadata and configures self pretty much the same as ActiveRecord: http://code.google.com/p/activejdbc/
You should look at using DataMapper instead of ActiveRecord. DataMapper and Hibernate following roughly the same pattern so the mappings would be similar. Also, DataMapper defines the mapping in the class itself rather than figuring it out from the model. This is much closer to Hibernate and you could probably write a simple hbm to dm converter and just eval the output at the top of your model classes. If you didn't design your original data model with Rails in mind, none of the convention over configuration standards are likely to be there; with DataMapper, the default seems to be to map properties and relationships like Hibernate.
Another idea: if you use the Hibernate annotations instead of xml mapping, maybe you could JRuby as the bridge to build the Ruby model from the Java one.
But either way, if you have good tests, it should be obvious when a data model change break something.