Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AF0EF9419 for ; Fri, 13 Jan 2012 10:48:57 +0000 (UTC) Received: (qmail 9493 invoked by uid 500); 13 Jan 2012 10:48:56 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 9390 invoked by uid 500); 13 Jan 2012 10:48:47 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 9382 invoked by uid 99); 13 Jan 2012 10:48:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 10:48:45 +0000 X-ASF-Spam-Status: No, hits=3.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of flexcapacitor@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-tul01m020-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 10:48:37 +0000 Received: by obbuo6 with SMTP id uo6so2278741obb.6 for ; Fri, 13 Jan 2012 02:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QXAE90+OiyjwB+ZXDOqqfjUQEVI79oBbkE39FtVWhz0=; b=pAURG8/DvVW3cBygodOK+AC1MFSNVt4kohjiY90ejRsENb0z/5KXk5SJWybC2ZnAMi Jf5mTgjIlF8oDLBvtINFkWX8ir/EfFaI3aL3Fl8c1cj2ONqCjbU9Re3CxANepXQv1s9H EsuC6IEhWKUAWd+Ie/Sr5QOFffOydrbzO8RDQ= MIME-Version: 1.0 Received: by 10.182.134.71 with SMTP id pi7mr126474obb.77.1326451696530; Fri, 13 Jan 2012 02:48:16 -0800 (PST) Received: by 10.182.42.2 with HTTP; Fri, 13 Jan 2012 02:48:16 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Jan 2012 04:48:16 -0600 Message-ID: Subject: Re: Goal for Flex: Strengthening large-scale Flex applications From: jude To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=e89a8f838e412ef35604b6669af6 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f838e412ef35604b6669af6 Content-Type: text/plain; charset=ISO-8859-1 I have to agree with Sebastian on this. I think it is the responsibility of the architects to show how they intend the architecture should be used. At least in an abstract way. Flex apps with or without micro frameworks have a common setup across them in general. It would be helpful going forward to describe separation of concerns and when and where to apply certain principles. For example, if you looked at any of the Twitter client examples currently online you'd see how to get the feed and hook it up to a data grid in as few lines of code as possible. In a production edition you wouldn't do that. You'd want to describe the package structure, the use of data models and data providers and services. You'd include when and how to use item renderers. On Wed, Jan 11, 2012 at 5:02 PM, Omar Gonzalez wrote: > On Wednesday, January 11, 2012, Sebastian Mohr wrote: > > @Roland > > > > hmm ... maybe you are right ;) But this is not my concern > > now. I am talking about building large-scale Flex apps and > > how to build them the best way. > > > > > > -- Sebastian > > > > > > I get what you're saying and I totally feel you, but I don't think it is > the responsibility of this project to teach how to use the framework in a > best practices type of way. We're here to advance the SDK. Although I agree > more educational material is required I don't think that is something we > need to focus on at this point. > > That being said, nothing is stoping you from drafting such a document and > bringing it to the list for discussion. If it is good and everyone agrees > it can get voted to be adopted as official Apache Flex Best Practices, > otherwise the community will vote it down and we will keep moving forward. > At least this is my understanding of the "Apache way". > > -omar > --e89a8f838e412ef35604b6669af6--