You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2005/09/01 09:14:06 UTC

[ti] Status Matrix

I've talked to several people interested in Ti but unsure where to 
start.  To help define where we are and where we are going, I started a 
"Status Matrix" wiki page containing features, their completion 
precentage, and notes.

http://wiki.apache.org/struts/StrutsTi/StatusMatrix

Please feel free to add/modify this matrix to point out areas that need 
work or have been resolved.  A good way to get started is to run the 
samples in the repository:

With Java 5 as your JAVA_HOME setting, run:
'maven jar jar:install'  in jars/core and jars/java5
'maven war' in wars/samples
to build a war that you can deploy in a Tomcat container.

A big thanks to Rich Feit and James for the Page Flow stuff and Maven 
build respectively.

Don


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

Re: [ti] Ruby on Rails like? (was Status Matrix}

Posted by Ted Husted <te...@gmail.com>.

On 9/2/05, Don Brown <mr...@twdata.org> wrote:
>  In my opinion, Java web frameworks
> have been too much about how great they are (navel-gazing), and not
> enough about making it easy for the end developer.  I see Struts Ti
> zeroing in on creating a great end-user framework, collaborating with
> other projects as much as possible to get there.

What I see as the leading problem with all web application frameworks,
including those distrbuted by Microsoft, Macromedia, and Sun, is the
lack of realistic, best-practice applications that demonstrate why
*each* and *every* feature is needed by the framework. I believe there
should be a suite of applications that drive the development of the
framework itself. If the application suite doesn't need it, then
neither does the framework.

By definition, frameworks are a means to an end. We should clearly
define the end before creating the means.

Another leading problem, as I see it, is that we keep building *web*
application frameworks. IMHO, we should be building application
frameworks first, and then exposing these applications to the web. By
putting the focus first on the web, we end up putting way too much
functionality into the web layer, where it is hard to reuse with other
presentation systems. (Like, say, unit tests!)

If our MVC mojo was up to snuff, it should not be so hard to write a
MailReader application and then expose it on the web to Shale, Struts
Classic, Ti, Spring MVC, Web Works, Tapestry, and so forth. We seem to
be encouraging people to write applications *with* presentation
frameworks, rather than *into* presentation frameworks.

After putting it off way too long, I'm finally reading "Writing
Effective Use Cases" by Cockburn (co-burn). We've started to use his
"fully dressed" Use Cases" at work, and it's really putting things
together for us. I've posted an example here:

* http://husted.wush.net/docs/display/NEO/Log+Facility+Issue

But Cockburn's Use Cases aren't just for users, developers can use
them for the nuts-and-bolts too. Here's another example that I boldly
borrowed straight from the book, used by an actual programming team.

 * http://husted.wush.net/docs/display/NEO/Serialize+Access+to+a+Resource 

My own itch is to start creating and maintaining web application
frameworks in the same way that we create and maintain our own
applications. (Or, at least the way we would create and maintain
applications, if the PHBs let us do things right!)

But, not to save the world or corner the market. But, because life is
too short to use application frameworks that aren't being written by
writing applications.

What I'd like to do next with OverDrive is step back and write
fully-dressed Use Cases for the framework's feature set. If a feature
can't be justifed by a Use Case *and* demonstrated by a framework
application, then out it goes :)

So, I guess what I'm saying is that we might consider analyzing our
own requirements for the framework that we want to use, in the same
way we analyze the requirements of the applications our users want to
use. Of course, not in a waterfall way, but at least  in an Agile way.

-- HTH, Ted.
http://www.husted.com/poe/

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