You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Christine Eckstein <kw...@yahoo.com> on 2001/07/12 18:07:36 UTC
Looking for Statistics
The stats I'm looking for are comparing lines of code
necessary for front-end development using Model2 Struts
versus using a Model 1 solution (actually a JSP/Servlet --
not controller -- architecture).
If those type of stats do not exist, does anyone have
something already built using a Jsp/Servlet architecture as
one solution and a Struts architecture for the other that
could provide me with some of the stats I'm looking for?
We're in a crunch to get estimations done and I don't have
the necessary time to build something quick to do the
comparison. It can be something as simple as a page with 6
form fields that'll submit and return a result.
Thanks a bunch to anyone that can help me out with this on
such short notice! :)
-cme-
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: Looking for Statistics
Posted by Christine Eckstein <kw...@yahoo.com>.
Wow, this mailing list is soooo active, I almost overlooked
your reply and sent it off into the digital wasteland. I'm
sorry!
Thank you for your help. I'll check it out and once I have
some numbers, I'll be glad to share. :)
-cme-
--- Ted Husted <hu...@apache.org> wrote:
> I don't have a model 1 version, but I've put up a WAR
> with brief
> skeleton application at:
>
> < http://husted.com/about/struts/resources.htm#new >
>
> along the lines of your requirements.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: Looking for Statistics
Posted by Ted Husted <hu...@apache.org>.
I don't have a model 1 version, but I've put up a WAR with brief
skeleton application at:
< http://husted.com/about/struts/resources.htm#new >
along the lines of your requirements.
Struts-simple collects input for 6 fields, each validated as an integer,
date, phone, ZIP, and email. The validations are made both as Javascript
on the client side, and in Java code on the server side. The same error
messages are validation code are used on each side.
The Action just returns the input values in a read-only page, but
comments indicate where the data access code would go in a production
application. The sample only has "input" and "insert" tasks, but others
can be easily added.
If a database error occurs, the error would be be added to the message
queue, and flow automatically returns to the input page (with the input
intact).
The source files you would need to write are provided. Again, I can't
say how much work this would be to do from scratch in Model 1, but
here's what it would take in Struts.
If you do develop any metrics form this, please pass them along ;-)
Christine Eckstein wrote:
>
> The stats I'm looking for are comparing lines of code
> necessary for front-end development using Model2 Struts
> versus using a Model 1 solution (actually a JSP/Servlet --
> not controller -- architecture).
>
> If those type of stats do not exist, does anyone have
> something already built using a Jsp/Servlet architecture as
> one solution and a Struts architecture for the other that
> could provide me with some of the stats I'm looking for?
> We're in a crunch to get estimations done and I don't have
> the necessary time to build something quick to do the
> comparison. It can be something as simple as a page with 6
> form fields that'll submit and return a result.
>
> Thanks a bunch to anyone that can help me out with this on
> such short notice! :)
>
> -cme-
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: Looking for Statistics
Posted by Ted Husted <hu...@apache.org>.
Incidentally, if someone did have a simple Model 1 application handy,
and wanted to see it running under Struts, a good way to get a quick
start is to use Ravi R's Stuts Codemaker. (Available at <
http://husted.com/about/struts/resources.htm >).
To do this, you would start by removing any scriplets from the Model 1
JSP's and converting the HTML form tags to Struts HTML form tags. Ravi's
CodeMaker * takes less than five minutes to setup *, and will read in
the JSP's and output the sourcecode for the Struts ActionForm classes.
As a convenience, it also outputs starter Action classes.
I'm thinking of rewriting Strut by Strut to depend on using Ravi's tool
as a quick start (would that be OK, Ravi?). As mentioned there, the best
way to start an application is to draft the views first, and Ravi's tool
is a good fit with that approach.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Christine Eckstein wrote:
>
> The stats I'm looking for are comparing lines of code
> necessary for front-end development using Model2 Struts
> versus using a Model 1 solution (actually a JSP/Servlet --
> not controller -- architecture).
>
> If those type of stats do not exist, does anyone have
> something already built using a Jsp/Servlet architecture as
> one solution and a Struts architecture for the other that
> could provide me with some of the stats I'm looking for?
> We're in a crunch to get estimations done and I don't have
> the necessary time to build something quick to do the
> comparison. It can be something as simple as a page with 6
> form fields that'll submit and return a result.
>
> Thanks a bunch to anyone that can help me out with this on
> such short notice! :)
>
> -cme-
Re: Looking for Statistics
Posted by Ted Husted <hu...@apache.org>.
Yes, it's important to point out all the advantages of using a MVC
Framework like Struts to do a fair comparision. Even though the
framework is not actually designed to minimize coding or promote rapid
development, I think if you put all the real-life requirements on the
table, we can stack up quite well.
For example, the simple application I through together last night,
besides capturing and returning input, fills these requirements:
1. Validates input as to type (Integer, Date, Phone, ZIP, and Email).
2. Provides Javascript and server-side validations from the same
configuration file (logic and messages).
3. Can be Internationalized by simply adding language resources.
4. Returns the original input in the event of error.
5. Will return muliple errors in the same request/response.
6. Detects and handles cancel event.
7. Can redirect flow in the case of data access errors, or return to the
same page with input intact.
8. Can share data-access logic with applications in other environments.
Counting semi-colons:
Access.java - 28
Form.java - 57
Counting < .. /> nodes:
Struts-config.xml: 7
validator.xml: 20
So about a 100 lines for a full-featured data-entry skeleton, about 20%
of which would be re-used on the next module.
Of course, a practical metric would not only include what's needed for
start-up code, but also what would be required to make substantial
changes later -- as happens in actual practice. That's the real thrust
of MVC frameworks: what happens ~after~ you ship? Getting the product
out the door is only the tip of the iceberg. The smart money knows that
the real cost of ownership is in maintaining and extending applications
over the long term.
Say, Malcom, we've started work on a brochure that might make good use
of your text. May we appropriate it?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
malcolm davis wrote:
>
> Hello Christine,
>
> I don't have any stats. Sorry. :(
>
> The following was from a presentation I had to do on justifying
> converting an application to Struts. Hope it helps.
>
> 1. UI - Presently, minor changes in code ripples through
> the large sections of the application. Moving a single field
> from one HTML page to another might require touching multiple
> java classes instead of just a simple change of two JSP files.
> [Struts limits ripple affect]
>
> 2. Layering of the application - The present design has a
> high degree of coupling between layers. This makes it difficult
> to make changes with affecting the major parts, or the entire
> application.
> [Every module should communicate with as few others as possible. - Myers ]
>
> 3. Interface development and role development - Changes in the
> presentation layer requires change in the business code. The
> present design requires that the JSP contain Java code. In addition
> to code, the UI developer requires intimate knowledge of the internal
> workings of the application; a human interface person cannot do UI
> development.
> [Struts, with the help of JSP Tags abstracts away the daily
> involvement of Java developers in the UI]
>
> 4. Regression Testing - There is no way to build unit test around
> the business logic because it is tightly integrated with the UI code.
> [Struts reaffirms the need to build business logic by
> forcing a layer with Action]
>
> 5. Flow - Understanding the flow of the application requires walking
> the code. There is not a central location for the logic flow of the
> application.
> [Struts, with the help of the Controller, allows a developer to see the
> flow of the application. This is extremely import in large applications]
>
> 6. Common Error - There is not a common way of handling or displaying
> multiple errors to the user.
> [Struts provides a common mechanism for handling errors]
>
> It's hard to say if Struts is the solution for you with out knowing
> the entire problem space.
>
> I'm interested in any options.
> Malcolm
RE: Looking for Statistics
Posted by malcolm davis <ma...@nuearth.com>.
Hello Christine,
I don't have any stats. Sorry. :(
The following was from a presentation I had to do on justifying
converting an application to Struts. Hope it helps.
1. UI - Presently, minor changes in code ripples through
the large sections of the application. Moving a single field
from one HTML page to another might require touching multiple
java classes instead of just a simple change of two JSP files.
[Struts limits ripple affect]
2. Layering of the application - The present design has a
high degree of coupling between layers. This makes it difficult
to make changes with affecting the major parts, or the entire
application.
[Every module should communicate with as few others as possible. - Myers ]
3. Interface development and role development - Changes in the
presentation layer requires change in the business code. The
present design requires that the JSP contain Java code. In addition
to code, the UI developer requires intimate knowledge of the internal
workings of the application; a human interface person cannot do UI
development.
[Struts, with the help of JSP Tags abstracts away the daily
involvement of Java developers in the UI]
4. Regression Testing - There is no way to build unit test around
the business logic because it is tightly integrated with the UI code.
[Struts reaffirms the need to build business logic by
forcing a layer with Action]
5. Flow - Understanding the flow of the application requires walking
the code. There is not a central location for the logic flow of the
application.
[Struts, with the help of the Controller, allows a developer to see the
flow of the application. This is extremely import in large applications]
6. Common Error - There is not a common way of handling or displaying
multiple errors to the user.
[Struts provides a common mechanism for handling errors]
It's hard to say if Struts is the solution for you with out knowing
the entire problem space.
I'm interested in any options.
Malcolm
RE: Looking for Statistics
Posted by Renzo Toma <re...@xs4all.nl>.
You're asking for an unfair comparison; model2 seperates logic ("model" &
"control") from presentation ("view") so you're bound to have overhead, and
thus more lines.
It sounds like you need to convince suits to go with Struts. If so, take
another approach, point out the benefits of MVC.
Cheers,
Renzo
-----Original Message-----
From: Christine Eckstein [mailto:kwisti1e@yahoo.com]
Sent: donderdag 12 juli 2001 18:08
To: 'struts-user@jakarta.apache.org'
Subject: Looking for Statistics
The stats I'm looking for are comparing lines of code
necessary for front-end development using Model2 Struts
versus using a Model 1 solution (actually a JSP/Servlet --
not controller -- architecture).
If those type of stats do not exist, does anyone have
something already built using a Jsp/Servlet architecture as
one solution and a Struts architecture for the other that
could provide me with some of the stats I'm looking for?
We're in a crunch to get estimations done and I don't have
the necessary time to build something quick to do the
comparison. It can be something as simple as a page with 6
form fields that'll submit and return a result.
Thanks a bunch to anyone that can help me out with this on
such short notice! :)
-cme-
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/