Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 14292 invoked from network); 20 Jun 2002 19:57:10 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Jun 2002 19:57:10 -0000 Received: (qmail 5623 invoked by uid 97); 20 Jun 2002 19:56:45 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 5545 invoked by uid 97); 20 Jun 2002 19:56:44 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 5374 invoked by uid 98); 20 Jun 2002 19:56:42 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D12336A.20603@mitre.org> Date: Thu, 20 Jun 2002 15:56:26 -0400 From: Michael Stanley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Make your stand now - Is Avalon for more than ReUse ? References: <006501c21889$89406480$ac00a8c0@Gabriel> <3D122742.7020008@osm.net> <3D12310B.2030407@datafundamentals.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N My quick 2 cents -> I've followed the Avalon project (quitely) for some time. I've experienced its use with projects like James and Cocoon, both of which I'm very familiar with. I recently read all there is to read about Avalon (as I plan to use it on my new work project), including the source. Let me say first off that I'm very impressed with the project, its goals, and its overall design. To me Avalon is much more that Component Re-Use. Avalon is a prime example of good software engineer and good OO practice. It is a great patterns reference, and model for all component oriented programming. Component Re-use is just an added benefit. Pete Carapetyan wrote: > Submitted this question within earlier, but it got ignored. > It needs to be answered. > > Is Avalon for ANY other purpose than *Component Re-Use* or not? That is > certainly my only interest. It is arguably what attracts most people to > it? True or false? > > If it is, then Berin's excellent viewpoints on simplicity and ease of > use may still be valid, and it seems much more likely that an easy to > learn, easy to code version of Avalon is still quite possible, or at > least that a ratched complexity model of behaviour is attainable. > > If not, then what other purposes does Avalon serve? For example, if a > component was NOT going to be re-used on another project, is there any > reason whatsoever to Avalon it or should it just be instantiated as any > other OO object ? Is Avalon then becoming complex and difficult to learn > and use because of the inherently complex objectives, or is because it's > objectives aren't clear, so a shotgun approach is required to make sure > that every avenue is accounted for? What a nightmare. > > Without a very clear objective, solving it keeps appearing to be > possible, but then evaporates as the details are discussed, not because > of the details themselves, but because the participants are trying to > solve different problems. It's a pot of gold at the end of a rainbow - > closer you get..... Hence Stefano's commentary on Cocoon using Avalon > where it shouldn't be used in the first place. > > Mark Shepard, a suit from TI was credited with the saying that "More > than two objectives is no objectives at all". > > If you don't know where you are going, any road will get you there. > Someone else said that. > > *Component Re-Use*. Is that the only objective or not? True or False. > Make your stand now, and then stick to it. > > Not fair to cite SoC or IoC or Separation of Interface and > Implementation. They still make sense, but only because the objective is > assumed as common sense. > > > > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- -- To unsubscribe, e-mail: For additional commands, e-mail: