The discussion here (knowingly or otherwise) mirrors something that
comes up a lot when people are debating the pedagogical approaches in
academia. A framework like Tapestry, which comes into its own on
larger projects, is not served well by using toy examples to
illustrate framework features. If the toy example is not something
that anyone would ever do in the real world, it's essentially not a
very good example.
Many introductory approaches to software development feature examples
with two or three classes and no persistence. In other words, an over-
engineered solution that essentially achieves next-to-nothing, and is
consequently unsatisfying to implement. A far better approach (along
the lines of what Howard and Thiago have suggested) involves giving
the students a working system to begin with, large parts of which are
intended to be black boxes to them, and will remain black boxes even
at the end of the course. Students deal very well with this.
A variation on this approach (which might work well here), is that
some parts of the system could be black boxes at the outset but the
intent is to peer inside them at some later stage. So, for example,
you could provide some custom components at the outset that would
make the first cut implementation more satisying to the student.
(Using custom components is identical to using built-in components
from their perspective.) You could subsequently examine how some of
the custom components are implemented and then move on to creating
custom components from scratch.
It is worth pointing out that the structure of such an approach is
fundamentally different to the structure of a more traditional
approach. The "chapters" would essentially be phases in a development
project and the topics would be covered as a side-effect of being
taken through each phase. Trying to label each "chapter" in terms of
what topics are covered may not be entirely possible. So Timothy's
suggestion of going ahead with "compiling and organizing information,
and then later on creating the narrative structure" wouldn't really
work here. Neither would such a book serve Patrick's objective of
something you could easily peruse bits of. So it's swings and
roundabouts so some extent. You do lose some things. But, in my
humble opinion, you gain a vastly superior pedagogical approach.
Added to that, you get a non-trivial demo application thrown in for
free. (Whereas you can typically achieve much less in your standard
last-chapter-of-book "case study", due to space constraints.)
Regards,
Don.
P.S. Incidentally, these ideas have been around a long time. Some
authors refer to is as an "inverted curriculum" in that you start
with a working system rather than end up with one and that you
interact with relatively complex objects first rather than start by
building the nuts and bolts.
This message has been scanned for content and viruses by the DIT Information
Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
