I am dealing with a Java EE web application that needs some refactoring. I am currently in charge of doing this job and am currently at a loss on what would be necessary to be done or changed in order to improve the application.
My question is: how can the frontend part be refactored?
I already refactored the CSS files in order for them to have generic rules and classes and removing unused or wrong rules, I refactored all Javascript files using some patterns (not using prototype inheritance since it's not really useful here) and adding PrototypeJS and still need to finish aggregating JS functions (when possible) in Objects and included files.
Now I am finishing up adding Localization to pages that missed it or where it wasn't complete and I want to migrate the whole application to XHTML Transitional following W3C guidelines strictly.
I also have in mind to start using Struts Tiles to add templates and in the mean time remove the old "Tables Layout" the frontend is currently using, so actually redesigning the whole application.
But I am at a loss here: is what I am doing useful? Does all this work need to be done or am I just going too far? What would you add up? What would you do instead?
I think this Stack Exchange Thread (How to approach refactoring an existing web application?), would better answer your question.
Hope that helps.
Related
We are working on large scale project which is having hundreds of method.
We are using Spring MVC, hibernate and DWR architecture for our Project.
Currently we are adding all methods of all functionality in Few Service Class. This Service Class are divided according to Modules (Front, Admin, Billing etc).
NOW project size is huge and so the methods in Services class are increasing. This service class contains hundreds of methods of all functionality.
MANAGING as well as UNDERSTANDING this is getting problem.
want to know that is this a proper way every one in industry do or we are going wrong.
ELSE HOW WE CAN IMPROVE THIS.
I've noticed a few patterns in file structure between different languages and programmers. In Java, they like to make many classes, spread out. While in C/C++ they try to keep as many methods in a single file as possible (I've commonly seen 2-5k .cpp files). Either way you go with is fine, just make sure that you keep your code as clean and as documented as possible. It's nice to have a multi-line comment before each method explaining the parameters, algorithm and return.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have setup my models and now I would like to build the application so that I can easly switch between swing views and html views (2 differents builds).
Could you recommand me any library that let me do that ? or a Controller/View architecture that let me do that myself ?
edit: MVC architecture in java is the point of my question, if I use SWING my controller call the method of a View class to show the results, whereas (at least in python django) the controller returns a "View" class (and something takes care of rooting the resulting view to the user, possibly getting the view from cache directly if it's already there.) which is 2 different ways to implement MVC. I don't know how html views are sent to the user with Java (I suspect that there is different methods) that's why I'm asking the question to get the general idea behind MVC architecture in Java as it may have it's own ideomatic/reference interface to achieve this job.
Oracle's Application Development Framework (ADF) does just this.
You develop your application modules, database entities, and view objects. Then you can drag and drop them onto the page or frame. This allows you to develop the business logic once and keep the logic for handling each view separate.
JDeveloper 11g (the IDE for developing software using ADF) handles AJAX well. It also allows you to declaritively create custom components that can be reused via drag and drop.
The application's visual layout is somewhat abstracted through custom tags, but you cannot, for example, create a web page and then click a button to create a corresponding JPanel. (To my knowledge.)
I don't know of any library, but I can suggest a kind of architecture.
I suggest using (at least) three projects: one for the core functionality, one for the HTML view and one for the Swing. The views depend on the core functionality project, but the two views do not know each other.
You will need some kind of Factory in both view projects, that can instantiate the classes of the selected views using the data from the core projects - if you want to handle this instantiation from the core project, then you will need either a common interface and some kind of dynamic instantiation, or use the same class in the same package in both project.
If you choose a solution like this you cannot use both views in the same time (at least easily :) ).
OSGi with its updated classloader provides support for such scenarios, where your Java projects are OSGi bundles, their dependencies are explicitely set, and the framework can handle these ones. And you can use services to describe the view factories, and then you could decouple these parts in a formal, well-defined way.
I hope the base idea was clear enough.
I'm not sure any library will achieve what you wish. After all, each technology (swing and html) will require different 'view' layer code. What's important here is to keep all business logic out of the view layer and keep it in a control layer which is then used by each view (otherwise known as the MVC architechture, see this link for more info or Sun's more detailed example.
Basically it will come down to your dedication in maintaining separation of responsibilities which will enable you to gain the most reuse out of your code.
I googled for 'swing' and 'ajax' - because I knew of eclipse RAP project, the rich ajax platform which would help if you weren't focussed on swing - and this blog entry looked promising: http://www.javalobby.org/java/forums/t101605.html
The 'RAP' idea is to have one GUI code base and build it either for a standalone client application or a web application (ajax). The blog discusses a different approach: you build a swing application and transform it to a web application.
Hope it helped! (hope I got your question right ;) )
MVC, if followed to the dot can accomplish this! Keep all your business and model layer separate, then have struts/spring controller decide the view.
Maintain separate swing and html code.
The key again is to remove all possible business logic from presentation layer and making sure your business layer is independent of the presentation layer.
Another option is to just use Swing to display html. If you use JEditorPane or JTextPane and just show html. The downside is that you can't do very sophisticated html using this method. You might also consider using a browser in your app. Here are a couple of possibilities though I have not tried them:
http://jrex.mozdev.org
http://lobobrowser.org/java-browser.jsp
http://www.webrenderer.com/
I recently added Struts 1.3 to my application on Tomcat. Here are my observations,
MVC. Servlet/JSP does this fine for me, where JSP is the view and servlet is the controller. I don't see any benefit to get the mapping from an XML file since our mapping is very static.
Action Form. I can see some benefits of action form but not huge.
Tags. I already uses JSTL and don't see any advantage using Struts tags.
So I am thinking about removing Struts. Anyone can think of any other benefits I might have missed?
Personally I myself prefer jsp/servlet but theoretically Struts has some advantages.
Here are some of the advantages i know of, you might have mentioned them already, but i thought it would be better if i list all of them here.
Centralized File-Based Configuration.
Struts values/mapping are represented in XML or property files. This loose coupling means that many changes can be made without modifying or recompiling Java code, and that wholesale changes can be made by editing a single file. This approach also lets Java and Web developers focus on their specific tasks (implementing business logic, presenting certain values to clients, etc.) without needing to know about the overall system layout.
Form Beans.
Bean Tags.
Struts provides a set of custom JSP tags that let you easily output the properties of JavaBeans components.
HTML Tags.
Struts provides a set of custom JSP tags to create HTML forms that are associated with JavaBeans components. This bean/form association serves two useful purposes:
It lets you get initial form-field values from Java objects.
It lets you redisplay forms with some or all previously entered values intact.
Form Field Validation.
Struts has a robust, extensible validator that can be used to uniformly validate your form fields. This validation can be performed on the server (in Java), or both on the server and on the client (in JavaScript).
"Plumbing code" contained within the Struts framework.
Mapping HTTP request parameters to Java objects is handled by Struts, for example. You don't have to do it. This allows you to focus more on the domain problem instead of building infrastructure.
Good documentation & plenty of books.
If you have to leave the project and/or someone else has to maintain it then using a well known and well documented framework will make that job much easier. A homebrewed framework just can't match that.
Broad user testing.
Since Struts is used in plenty web-apps the framework will get looked at by many more eyes than anything you could write alone. Usually, but not always, that means any problems you have will have been seen by someone else (and hopefully resolved) first.
Large knowledge base.
I agree that this perhaps isn't as valid as it used to be but Struts has been used in a lot of projects over the years. From a maintainability point of view using a well known framework makes it easier for other people to work on your application and also help build your own resumé for the future. Right now most development is either in the component based space (like JSF, wicket, tapestry) or in the rails-like space (like rails, grails, lift) but the struts arcitechture is still in use and valid.
You didn't say if you develop in a corporate environment or not, for a personal project perhaps the maintainability issue isn't that much of a problem.
If you decide that struts suits you well you could also have a look at stripes, a struts-like framework that's based on the same concepts but is less verbose when it comes to configuration with more sensible defaults, less xml and support for annotations.
I totally agree with your points about Struts - personally I think its time has come and gone.
I went off Struts in v1 (which I believe is nothing like the latest versions) because the form beans where just added boilerplate code to write.
Since then most applications I've worked on are using Spring as the dependency injection framework, which has made Spring MVC the natural choice - it's simple, straight forward and minimal.
Not just for Struts. But some points to consider for using a framework:
Standarization.
Specialized IDE or plugins for your favourite IDE.
Portability. For example, someone can develope a portlet for integrate your existing struts application in a portal server.
Internationalization.
The most important for me:
You dont have to worry about the issues on the struts code, just upgrade.
You can focus your work in business logic.
Struts is Open Source--
Large Community----
Number of Books available-----
Proven FrameWork----
Popular framework-----
Available since 2001----
+----
the features mentioned above...........
but when u r using struts,the better choice is struts2.
I think your feeling about removing Struts is a sound and understandable reaction. Struts just doesn't seem to do very much for an application.
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've observed the strange fact (based on the questions in the hibernate tag) that people are still actively using xml files instead of annotations to specify their ORM (Hibernate/JPA) mappings.
There are a few cases, where this is necessary:
you are using classes that are provided, and you want to map them.
you are writing an API, whose domain classes can be used without a JPA provider, so you don't want to force a JPA/Hibernate dependency.
But these are not common cases, I think.
My assumptions are:
people are used to xml files and don't feel comfortable / don't want to bother learning to use the annotation approach.
Java pre-1.5 is forced upon the project and there is nothing to do about it
people don't know that annotations are a full-featured replacement of xml mapping.
legacy systems are supported and hence changing the approach is considered risky
people fear that mixing annotations (meta-information) with their classes is wrong.
Any other possible explanations?
The domain layer and the persistence layer are considered by some to be separate concerns. Using the pure XML approach keeps the two layers as loosely coupled as possible; using annotations couples the two layers more tightly as you have persistence-related code embedded in the domain code.
Lack of overview of what's been mapped. You need to dig in the source code.
people don't know that annotations are
a full-featured replacement of xml
mapping.
Ah, but they're not. Three cases off the top of my head (there are probably more) you can't do (well) with annotations:
Use formula as part of association key (admittedly, rather esoteric).
Join-via-subselect - #Loader is not an adequate replacement. Not too common but quite useful. Envers provides a viable alternate approach.
Losing column order for schema generation. This one's an absolute killer. I understand why it's done this way, but it still annoys me to no end.
Don't get me wrong, though - annotations are great; doubly so when they're coupled with Validator (though, again, #3 above kills the buzz on this one). They also provide certain aspects of functionality that XML mappings do not.
Using XML to complement the annotations, where environment or system specific configuration is needed.
Some information is carried nicely in annotations, such as the cardinality of relationships between entities. These annotations provide more detail about the model itself, rather than how the model relates to something else.
However, bindings, whether to a persistence store or XML or anything else, are extrinsic to the model. They change depending on the context in which the model is used. Including them in the model is as bad as using inline style definitions in HTML. I use external binding (usually—though not necessarily—XML) documents for the same reasons I reference an external CSS.
I initially found the annotation syntax very weird. It looks like line noise and mixes in with where I usually put comments. It's vastly better than dealing with the XML files though, because all of the changes are in one place, the model file. Perhaps one limitation of annotation is possible collision with other annotations, but I haven't seen that yet.
I think the real reason that it isn't used more is that it isn't really considered the default. You have to use an additional jar file. It should be part of core and the XML approach should be the optional one.
I've switched to annotations, but sometimes I miss the XML mappings, mainly because the documentation was so much more comprehensive, with examples of many scenarios. With annotations, I stick to pretty basic mappings (which is great if you control the data and object model), but I've done some very complex things in the XML that I don't know if I could replicate in the annotations.
So if you want to deploy your class to multiple datastores. And you want to annotate column definitions into it do you ? Different datastores have different conventions etc and using XML is the only sane place in that situation, being able to have one for MySQL, and one for Derby, and one for Oracle or whatever. You can still put the basic persistence/relation annotations in if you wish, but the schema-specific stuff would go into XML in that case.
--Andy (DataNucleus)
I have a new one : http://www.summerofnhibernate.com/
Very nice screencast series not yet covering annotations. I have written some apps with it to learn the basics, not for my job but out of curiosity, but never migrated to annotations yet. The series where suggested as still relevant on SO. I still will migrate to annotations if I have some more spare time but for the time being I could be one of the persons asking questions about it.
I worked on a project where the database would change very frequently and we have to regenerate the java files and configuration files each time it happens. Actually we do not use all the relationships and configurations generated by hibernate tool. So basically we use the tool and then modify/tweak them.
So when you want to modify/tweak the default configurations, it is easier to do in the XML file in comparison to doing it through annotations.
I feel that it makes the code much more readable if we donot use Annotations.Use of Annotations can really help if the configuration info changes frequently, but take the case of web.xml, how many times does the info in that change, so why use annotations for Servlets.
We continue to use XML because typically for deployed sites, getting a patch (binary code) approved for installation takes time that you may not have. Updates to ASCII files (e.g. xml files) are considered configuration changes and not patches...
t
I'm currently building a Spring MVC application. I was looking to use JSP pages with tag libraries for handling the view layer and formatting of the HTML, but I've come across another group in my company that uses Velocity templates for the same purpose.
From what I can see, it seems to me as if there are a lot of similarities between the two approaches:
Both have easy-to-understand syntax. Makes it easy for non-developers to understand and use, allowing the designers to focus on the HTML/CSS and only having to use directives/tag libraries in the few cases where they need conditionals/dynamic content without having to have a full understanding of Java.
Simple to see which part of the content is HTML vs which are directives/logic.
Both are heavily used and well supported.
Simple to integrate with Spring MVC.
But in comparing the two technologies, I can't see any specific reasons to use one versus the other. I'm having trouble thinking of any cons specific to either Velocity or JSTL.
So my question is, what are the pros and cons of each in your opinion? If you have built a (Spring) MVC app using one or the other, what made you decide on the view layer technology you are using and what (if anything) made you decide against the other?
Update: I've found a similar discussion of this same topic archived on the Spring Framework forum's here, which might be of some interest to anyone making the same decision between JSTL and Velocity as I am.
I would prefer to use Velocity just because using JSP+JSTL can allow lazy/sloppy developers to get into trouble by adding scriptlets. There should be no reason to have java code in your view tier. It doesn't take much to understand Velocity and as a matter of fact I just picked it up in about two weeks. While I don't like the formatting of the output, for the most part it works pretty well. We're actually not using it in the app's view tier but rather for generating HTML for use by other browsers. We save the output from Velocity as files which is then deployed to a different server for consumption by other web clients.
I actually slightly prefer Freemarker to Velocity, just in case you're open to exploring other options. Comparison here:
http://freemarker.org/fmVsVel.html
I agree with Ben's statements about enforcing a simple view by avoiding JSP and the possibility of scriptlets. I also like the ability to render a Freemarker or Velocity template in any kind of execution environment (JUnit, main() method) without requiring a Servlet/JSP container as JSP would.
JSP is also more difficult to visually differentiate from the embedded HTML. With Velocity, it is very obvious.
Also, the VelocityTools package provides a great deal of additional functionality.