Dakota Jack wrote the following on 4/1/2005 8:03 PM:
<SNIP>
On Apr 1, 2005 12:01 PM, Dakota Jack <[EMAIL PROTECTED]> wrote:

Because you get yelled at when you say that and some people cannot
take being yelled at.  Expect Craig, Ted, or someone to say the
standard thing soon on this tread.  I know I am doing my part.  LOL
///;-)

Jack

</SNIP>


You saw the prediction here, but I did not think the person doing the honos would be Rick. So, I guess I only get part credit? ///;-)

Relax! No stones have been thrown.

For the record, so others don't think I'm a die-hard Struts or JSF person, the prediction Jack made was in reference to a question by Dave:


"Anyway, how come no one is saying that the future is Struts 1.3 or 1.4? Why all the hoopla about the future IS JSF?"

My response was prompted by what I saw as a stone being thrown at a person - not at a technology. I probably read more into the thread than I should have, and for that I apologize. At the time, it certainly appeared to me there was an attack on an individual's motives behind JSF. I was only upset with what I perceived as an unwarranted attack on the character of a person.

No big deal. It was Friday:)

Personally, I don't care what framework/technology I use is as long as it meets some criteria (not necessarily in this order)...

1) Adequate documentation to reduce the learning curve. (For example, at the time when I wanted to evaluate the web framework part of Spring, the documentation was horrible so I just didn't even try to learn it. I don't have the time or energy anymore to spend hours looking at src code to figure out what's going on).

2) Easy to use. Once the basics are grasped, how much work is it to code using the framework? It is relatively intuitive? I don't need fancy tools to do my job, but the overall architecture should be easy to grasp. This ties somewhat into step 1, but will a new person to the project be able to get up to speed quickly with the technology?

3) Maintenance/Flexibility. When requirements change, is it easy to adapt the code to meet the changing requirements. (Sometimes there is a trade off between this step and the ease of use of the framework - a good balance is what I'm after.)

4) Ongoing development/support. I'm sure so many of us can attest to how much time we have saved because we were able to get help from this mailing list. Also the Struts community has some great people working on the code. You don't always find this kind of support from other frameworks. I'd actually choose a less-than-perfect solution provided it came with a huge community to tap for help, versus a slightly better solution that was more difficult to find help with when you got stuck. Plus, with large community support, the technology only improves (usually:)

5. Monetary cost?

--
Rick

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to