wllm wrote:
>
> this is a large initiative that Ralph could use some help
> with even before presenting class skeletons. That said, I also mentioned
> that we *really* need use cases in my comments; Ralph, it's clear that's
> our top priority here.
>
What I was commenting on before is simply general proposal advice. You need
a clear statement of the problem you're trying to solve. Otherwise neither
you nor any reader can guess if the proposed solution is anything close to
solving the problem you're supposed to be solving.
It's amazing how frequently this aspect of proposal design is overlooked. I
couple of years ago I consulted for a VC to provide a review of a business
plan for a technology startup company. The business plan said lots of great
things about their intended market, and then launched into a lot of
technobabble about their fancy software solution. Nowhere did they say what
the software would actually _do_, or how that would connect with the needs
of the market they described.
So a proposal must include these three pieces:
1. Problem statement
2. Proposed solution
3. Explanation of how the proposed solution solves the problem
Regarding use cases, here's a way you can jump-start them. Many open-source
frameworks have come out of work that people are already doing. They come
up with productivity tools that helped their own project, and then they
realized with a small effort they could package up those tools and others
could use them too.
You already have the code for a few modest-sized websites built with ZF:
framework.zend.com, devzone.zend.com, and www.zend.com. What I would
suggest is that Ralph take a look at these, figure out a sequence of
commands--a script--to invoke Zend_Tool that would reproduce these websites
(or something reasonably similar). Then these become three real-world use
cases.
This exercise is likely to reveal some requirements for Zend_Tool that have
been overlooked so far. I haven't looked at the current design for
Zend_Tool in great detail, but I predict that you will find some features
needed even for the simple framework.zend.com app, that aren't handled
gracefully by Zend_Tool yet.
Then you might want to recruit some folks in the ZF community who have
developed their own ZF apps, and ask them to do a similar exercise. Work
with them closely, and give advice on the usage of Zend_Tool. Together
produce a script that can reproduce their web app from scratch.
(These aren't actually use cases by the strict definition; they're more like
scenarios.)
By working with a community member, you will also learn some things about
the usability of Zend_Tool that will help you refine its interface and
documentation.
Obviously, any code-generator can't flesh out all the custom logic inside
functions, but it's worthwhile to add notes in your script where it's
necessary for the developer to write code, because it gives a reviewer a
good feel for which tasks of app development Zend_Tool can or can't
automate.
Regards,
Bill Karwin
--
View this message in context:
http://www.nabble.com/Why-haven%27t-you-reviewed-the-Zend_Tool-proposals--tp18221384p18266535.html
Sent from the Zend Framework mailing list archive at Nabble.com.
