On 8/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
I guess what I'm saying here is that the Struts learning curve should be as flat as possible, allowing developers to ease into the framework without forcing them to learn about things like custom interceptors and results when they don't have the need for them.
In my experience, the easiest way to flatten the learning curve is consistency. Right now, our approach to default result types is inconsistent. Most results work out of the box, but some require people to add optional JARs to the distribution. For the "optional" results, we've started to add apologetic logging statements, saying "Oops, I'm here, but my JAR isn't, but you probably don't care anyway." If we are going to have optional result types, then let's have optional result types. Let's add an "optional" attribute, so that we can render more meaningful logging statements. 1 When optional=true, and the support class is absent, then nothing is logged. 2 When optional=true, and the support class is present, then a DEBUG logging statement saying the result is enabled is logged 3 When optional=false (the default), and the support class is absent, a runtime exception is logged and thrown (fail fast). 4 When optional=false, and the support class is present, then nothing is logged (the nominal case). Even if we mark a result type optional in the configuration, we can still override the setting in a package, so if we need to do a problem determination, we can add the result again as "optional=false" in a package, so that we can be sure the system sees the result, but not the JAR. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
