struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vu, Thai" <Thai...@parsons.com>
Subject RE: With a new project, what technologies should I use?
Date Fri, 10 Feb 2006 23:04:45 GMT
Wow, an answer from a prof. :)

Sorry that I didn't give any information about the project I want to do.
Your question showed that I missed a lot of things. 

- I am a sole developer building a 3MB source code application in a
reasonable amount of time period (don't laugh at me please :) ).

- The look and feel is not very important (i.e. some simple CSS and
displaytag are fine).

- As I am the only developer, I have to do everything from database,
business logics to GUI.

- I don't expect to use any prepared sql statement. I prefer using
Hibernate or iBATIS. I think I will use iBATIS because iBATIS can call
stored procedures (Hibernate cannot do that, can it?) because I can
write stored procedures, triggers quite well (not well enough to build
an application just using PL/SQL).

- The site will contain a lot of dynamic elements and will not be
updated often (updating is needed if a new functionality is required).

- The business people are still figuring out what they want and I hope I
do not have to build everything from scratch when they need a new
feature.

So, what is your advice with those information?

Thanks for your answers.

Sincerely.

PS: By the way, what does PHB stand for in ` To a PHB, every application
is a nail.'?

-----Original Message-----
From: Ted Husted [mailto:ted.husted@gmail.com] 
Sent: Friday, February 10, 2006 3:17 PM
To: Struts Users Mailing List
Subject: Re: With a new project, what technologies should I use?

On 2/10/06, Vu, Thai <Thai.Vu@parsons.com> wrote:
>. Now what should I use if I
> have to write a new web application? And correct me if I'm wrong
> anywhere please.

It's a little bit like asking a building contractor: "What materials
should I use to build a new structure?"

Just to pose a few rhetoric questions: Are you a sole developer
building a five page application next week, or leading a team of ten
developers building a five hundred application over the next year or
two? Is the primary purpose of the application database access or
something else? How important is look and feel? Are the java
developers doing the markup, or is there a second team of HTML
designers? Are you expected to use prepared statements, code your own
SQL, or have it generated? Will the site be static or have a number of
dynamic elements? How soon before the site needs to be updated (if
ever)? Are the requirement stable, or are the business people still
figuring out what they want? Will the site need to maintained and
extended as business needs change, or would you start from scratch
with a new site?

Now some vendors want you to believe that no matter how you answer any
of these questions, and a hundred more, there is only one true answer:
Whatever product they want to sell you!

One size fits all is a myth. We don't have a unified theory of
relativity, and we don't have a unified framework for web development
at all scales. Some things work better for small applications
(Quantum). Somethings work better for larger application (Relativity).
There is a tipping point when you need to shift gears from
quick-and-easy to extensible-and-robust.

It's one thing to build a bike-shed; it's another to build a skyscraper.

A professional chooses the right tool for the job. To a PHB, every
application is a nail.

My best advice is to pick the smallest possible part of your
application and try that part with a couple of likely technologies.
Then, choose the one that best suits the application, your team, and
you.

If  it is not worth the trouble of doing even a small part more than
once, then the job is  probably a small enough job that you can snag
Java Studio Enterprise and do it with JSF out of the box.

*
http://developers.sun.com/prodtech/javatools/jsenterprise/reference/tech
art/whatis.html

HTH, Ted.

http://husted.com/blog/ted/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message