A section of links to "Patterns" in the wiki would be useful too.
Some example Patterns could be how Howard implemented various aspects
of the new Tapestry: custom/overriden engine services, new binding
types, etc
And laid out like standard patterns:
* Pattern Name and Classification:
* Intent:
* Also Known As:
* Motivation:
* Applicability:
* Structure:
* Participants:
* Collaboration:
* Consequences:
* Implementation:
* Sample Code:
* Known Uses:
* Related Patterns:
see http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29
Geoff
On 5/30/05, belaran <[EMAIL PROTECTED]> wrote:
> I was hoping that somebody was going to submit a draft for the new
> documentation ( or at least the list of chapter), but geiven the fact that
> nobody did , i'm going to try :
>
> The way i see it, the "summary" of a new hivemind doc should be :
>
> 1 - IoC pattern : no way we could skip this part but we should be quick
> about it ( maybe a short description plus some usefull links). What you'll
> be great, would be a text describing how HiveMInd see and implements the IoC
> and especially what HiveMind does differently from Spring and PicoContainer.
>
> 2 - A small tutorial , the "adder example" for instance, but fully
> described and commented. I personnally had some difficulty when i first
> tried hivemind because of some piece of info missing ( such as where do i
> place META-INF). The idea would be that even a java beginner should be
> able to go through this tuto without any difficulties. This way when
> somebody try HiveMind he should find it very very easy to use ( even more
> than hivemind is now).
> The second part of this tuto would be deploying HiveMind in Tomcat ( to
> show how HIveMindFilter does a lot for you, and to demonstrate efficiently
> object's lifecycle handling)
>
> 3 - Description of each HiveMind features ( configuration, interception,
> lifecycle object) with fully documented example.
>
> 4 - The XML documentation ( as it is)
>
> 5 - Why use HiveMind : some ( a lot ideally) of use case for HiveMind and
> something on migrating from, let's EJB, to HiveMind
>
> I don't know if this organisation is smart or not, i'm probably missing
> some stuff here... This is really a "request for comment".
>
> 2005/5/25, belaran <[EMAIL PROTECTED] >:
> > Indeed, use's case is a very important part of the documentation...
> >
> > Maybe some user could write up something about theirs use's case and all
> that stuff could be placed in a chapter dedicated to this ("Why or When use
> HiveMind ?").
> >
> > The refactoring part is important too... If you use hivemind for "scratch"
> it's easy, but what are the cost of migrating from XXX to HiveMInd ?
> >
> >
> > 2005/5/25, Howard Lewis Ship <[EMAIL PROTECTED] >:
> >
> > > I've been travelling. The HiveMind documentation explains the
> > > mechanics of HiveMind but not the theory and design, or even the
> > > real-world practice. What's needed are some real-world examples, that
> > > include the time element ... showing how, you code, and test, and
> > > refactor even over a short period of time.
> > >
> > > I've been, ah, busy working on a fairly comprehensive example of just
> > > how far you can push HiveMind; I've been calling it Tapestry 4.0 :-)
> > >
> > > On 5/24/05, Achim Huegen < [EMAIL PROTECTED] > wrote:
> > > > I was hoping to get some feedback on this topic.
> > > > Any opinions?
> > > >
> > > > Achim Huegen
> > > >
> > > >
> > > > Am Tue, 17 May 2005 23:34:00 +0200 schrieb Achim Huegen <
> [EMAIL PROTECTED] >:
> > > >
> > > > >
> > > > > I just came back from the german JAX congress. I attended a workshop
> that compared Pico, HiveMind and Spring IoC. Good news: HiveMind was not the
> framework blamed for having the worst documentation ;-) It was a close
> second place. Close to the third one unfortunately.
> > > > > The problem is that the current state of the documentation even
> leads to wrong statements about HiveMind (for example very lengthy registry
> setup example, pojo support etc.).
> > > > > The feedback from the user mailing list and some other reviews
> underline the need
> > > > > for improval of the doc.
> > > > >
> > > > > To address this issue I've set up a page on the wiki that tries to
> identify weaknesses in the current docs and makes a proposal for a new
> documentation structure:
> > > > > http://wiki.apache.org/jakarta-hivemind/DocRevision
> > > > >
> > > > > I'd suggest this approach:
> > > > > - First Release another 1.1 beta or even the final 1.1
> > > > > - Discuss and ratify a new documentation structure
> > > > > - Find volunteers for each chapter
> > > > > - Setup the new site structure and distribute the existing content
> > > > > - Vote me in as committer ;-)
> > > > > - Write new content
> > > > >
> > > > > I'm willing to do a (significant) part of the work but I would
> appreciate to do this as committer. Patching is quite laborious.
> > > > >
> > > > > Achim Huegen
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator, Jakarta Tapestry
> > > Creator, Jakarta HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work. http://howardlewisship.com
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
