I would be glad to write it but it seems to me that people are suggesting resources or tutorials (no matter what they are) shouldn't be apart of this project. I disagree with that. Or I'm suggesting that we have a descendant site that does provide these resources.
As far as the best way to design a large scale enterprise application I would say there are recommended approaches to creating scalable apps and I think that's what Sebastian was asking for. We can't forget the learning curve it takes to use Flex. Many beginners are presented with only code examples not application architecture examples. Instead what happens is they continue to build their own frameworks or carry on architectures from other languages into Flex. I've gotten into many discussions about whether coding is an art or a craft. I will not argue my opinion on that but when working in a team environment there are a set of code principles and practices that emerge that are expected in a production environment. What I would say is that if an getting started article on building large scale Flex application "as is" without other frameworks existed it would be well read. Actually, if there is a resource that lets people to submit articles or blog posts who cares what they write about? The community would vote it up or down and read it or not. On Fri, Jan 13, 2012 at 5:43 AM, David Arno <da...@davidarno.org> wrote: > > From: jude [mailto:flexcapaci...@gmail.com] > > Sent: 13 January 2012 10:48 > > > > 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. > > I'm going to repeat myself from yesterday here. If you think this > documentation is useful, get writing it. Clearly some folk disagree with > you > and they won't help you write it. Others might agree and may help you. > > If what you commit it or submit it as a patch gets approval, then it'll > form > part of future Apache Flex releases. If folk veto it, it won't. Either way, > it has to be more productive than this endless "Yes we should. No we > shouldn't" bickering over this topic. > > David. > >
