On 5/26/06, Medicherla Lakshmi <[EMAIL PROTECTED]> wrote:
Am Lakshmi. Am working on a web application in struts in a company. Am alone over here on java. Everyone is on .Net. Am new to huge development on java and never worked on any project in java till now since i was on vc++. This is my first project. So, please, please, anyone help me in building this project. Am not able to understand anything in this project. There is no proper design also. We have to design ourself and create the project. Please help me anyone to work on my project.
If the application needs work, and the application is poorly designed, and the other applications are .NET, then the best thing might be to start over with .NET. In practice, it is usually less expensive to get a fresh start on a good design than try and fix a bad design. It's said that 80% of the cost of an application is incurred after the initial version ships, so it's worth spending more up front, if it will make the application easier to maintain later. If the application is already deployed, and the primary task is maintenance and enhancement, then the best way to explore a Struts application (of any flavor) is to step through the configuration file. A big plus of an XML configuration file is that it can tell you how everything fits together. I'd start by clicking through the application and noting the Action URIs it call. Then, I'd write a brief narrative or story for each Action that explains what its doing. An extreme example of this approach is the MailReader tour: * http://www.planetstruts.org/struts-mailreader/Tour.do Though, this tour is more than most developers exploring an application would want to write just to explore a new application :) Instead, just write a single paragraph -- or story -- describing each Action, to help you get the big picture. You might want to do the same for the ActionForms. Even if the application has its own documentation, this exercise will help you "take ownership" of the application. Then, as maintenace and feature requests come in, you might want to add a formal use case to each narrative. A formal use case is an *excellent* way to figure out how something works, and it is also an asset that can be maintained with the project. Here's some use cases for the MailReader application: * http://www.StrutsUniversity.org//MailReader+Use+Cases In my own work, I often create "system use cases" to describe the internals of an application, often before I implement the code. The use case help me figure out beforehand what I will need to do -- like pseudo code, but in a format mere mortals can understand. For Action 1 newbies, my personal favorite book is "Struts for Dummies". * http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-0764559575 For experienced develpers working with Action 1.2, I'd suggest "Struts: The Complete Reference". * http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-0072231319 -- HTH, Ted. http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
