Reply to thread

Message: [QUOTE="Kirk Haines, post: 4438437"] It's really no different with a web project than with any other project. The web portion is nothing more than the interface between your software and the user. So if you would use some sort of an object model for a GUI app, you will do so for a web based app. If you would build some custom classes for handling your data or performing specific business tasks for a GUI app, you'll do the same for a web app. About the only difference is going to show up when dealing with the actual user interface, and that difference is going to boil down to how well whatever code library or templating system you are using to handle your interface bits. Do they let you use OO design paradigms? Can you define reusable components? Rails definitely takes a person down this direction. I'm trying to think of frameworks for Ruby that actually take the approach of saying that your components are themselves objects. The only two for sure that I can think of right now (and appologies if I am forgetting any) are my Iowa framework ([URL]http://enigo.com/projects/iowa[/URL]) and Borges ([URL]http://borges.rubyforge.org[/URL]). Maybe SWS? I forget the URL for it, though. David can certainly give you examples of how he uses OO design ideas with web apps using Rails, so I'll just lay out, generally, how I approach it with Iowa. I use an object-relational modeling package for all of my database interactions. In my case, I use Kansas. There are so many advantages to an ORM tool in terms of reducing lines of code and making applications faster and simpler to write and to read later that using a tool like this for your model data is usually a huge win. If I have common sorts of back end data manipulation or business logic tasks that are going to be performed at multiple different points in the application, I abstract those capabilities out to their own classes. Then for the user interface I break it down to find the areas where there are going to be commonly repeated elements and I put each of those into its own class (component). So, for example, a standard page header and footer each get their own component. A standard navigation bar would get its own component. If there is some reporting tool or table that will be used in multiple places, I can write it as a seperate component. Whatever. Once I have all of the multiuse pieces abstracted into their own classes, I then code the components that describe how the app ties together and that use the header and footer and report tool and whatever other multiuse components I have created. Back to front, it is all objects and everywhere that I can I refactor and reuse. Kirk Haines [/QUOTE]

Verification