Great start. I just made some additions and changes. Hopefully I helped make it clearer and not the other way around… ;-)
I just want to say, that while PAYG is hard both from a framework development perspective and from an application development perspective, I firmly believe that strict adherence to the concepts are worthwhile. I say this after using FlexJS full time on both sides of the equation for more than a year. We DEFINITELY want to make it easier for application developers to get started, and hopefully the Express set is a step in the right direction. We also DESPERATELY need better documentation and guides. Unfortunately most of us are not great writers. :-( Harbs > On Jul 2, 2017, at 1:40 AM, Greg Dove <greg.d...@gmail.com> wrote: > > Thanks Alex, > > I look forward to your feedback. It would be great to see (from you or > anyone else) - within this thread - suggested improvements/corrections or > other topics that should be added, or questions that should be addressed. > > I know there are areas that need improvement in a number of areas of the > document, but I'm hoping that this will be 'fixed' by making it a shared > goal and getting input from others, not by me kludging away in the > background. I wanted to get something up that is a starting point only. > > I do understand the avoidance of the 'swiss army knife' approach to base > classes in Flex 4, but had wondered about whether we were focusing on the > 19% of functionality that might be useful for 5% of developers (Basic) vs. > the 20% of that will suit 80% of developers (e.g. express) -I'm not saying > that the pareto relationships there are correct, just using it for > 'relative' comparison. But I think it is just a case of getting used to a > new way to thinking, which is different to Flex4 (and Flex3). It would be > really great if you can lead a thread specifically about this. > > I also suspect there will be no 'one true way' to make incremental > functionality beads either. But documenting the pros and cons of each > approach (which we already started in one of the other threads) might > provide useful guidance about when to choose which approach (inheritance > and/or utility functions etc). I'm looking forward to that discussion > because I think I was getting a lot out of the earlier discussion on that > already. > > In the end writing these things in a document is not something I call fun. > "I'd much rather be coding". But I do believe that having 'team-sourced' > content, as an output of focused list discussions, could make the > generation of the document content a much easier process, and that the > process itself could help improve decision quality, build consensus, and > provide resources that will be useful for team alignment and future > reference info for others. I think any one of those reasons is enough for > me to stop trying to create more of the content myself! > > > > On Sun, Jul 2, 2017 at 3:57 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > >> Hi Greg, >> >> Thanks for writing this up. I took a quick read. I'll do a more careful >> read next week and have more detailed comments. One thing I wanted put up >> for discussion now is the notion of "defaults". Really, I'm trying to get >> away from the notion that there is one default we have to decide on. IMO, >> that's another old way of thinking from Flex. FlexJS is designed to >> support multiple component sets. Express will have different defaults. >> MDL has different defaults. The Basic set has a particular design goal >> (feature parity with SWF) and thus will have different defaults. There is >> often no one right answer, so we build different component sets and folks >> will try them and decide for themselves. >> >> Thoughts? >> -Alex >> >> On 6/30/17, 3:29 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >> >>> Following on from other discussions, I have made a start on something here >>> https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fcwiki.apa >>> che.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId% >> 3D71013028&data=02 >>> %7C01%7C%7C35f519d4ea87431fd80808d4c0078bc3% >> 7Cfa7b1b5a7b34438794aed2c178de >>> cee1%7C0%7C0%7C636344586020292933&sdata=aj4YiAsUQDGoW5Bf% >> 2BQ2wyJxgqmguZ18T >>> Zng2jGcWIkY%3D&reserved=0 >>> >>> In the end this will only work if people want to do it. But I do believe >>> that one way of getting everyone on the same page here (and we do have >>> clear signs that not everyone is), is to, quite literally, get everyone on >>> the same page :). >>> >>> It is currently half content, half notes. There is more to harvest from >>> list discussions I think, some topics have progressed further than when I >>> started trying to capture ideas, so please correct any mistakes in the >>> definitions or add topics and questions that need 'resolution'/guidance. >>> >>> I personally would like to see some concrete guidance in the 'How does >>> PAYG >>> get implemented' section. There were definitely the beginnings of some >>> healthy discussions around some of the options for beads for example. >>> (DRY, >>> inheritance, utility functions etc). >>> >>> The goal here is to turn any list discussions around >>> uncertainties/misunderstandings into something that represents consensus. >>> I >>> think this should be do-able by simple discussions about specific topics, >>> maybe with informal voting if necessary. If there is no consensus then I >>> guess PMC could do a formal vote? (I don't know what makes sense here) >>> >>> Beyond work on the SDK, this type of information (in some form) might also >>> be helpful as part of the documentation for 1.0 when we get there, so it >>> could save someone time later on as well as being useful in the near term >>> (I hope). >> >>
