incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: Goal for Flex: Strengthening large-scale Flex applications
Date Fri, 13 Jan 2012 10:48:16 GMT
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 <omarg.developer@gmail.com>wrote:

> On Wednesday, January 11, 2012, Sebastian Mohr <masuland@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message