Awesome, @sashko. I’m sure a new thread will do.
Perhaps, something along the lines of the Microscope app will be for a good start. It doesn’t need to handle all the possible form combinations under the sun, but at least the ones such as, Inserting, Updating and Deleting all aspects of a form, i.e. strings, date, arrays, objects etc.
Thanks. Will keep close eye with the guide. 
What about ViewModel? It’s not a “form package” but it makes form validation and handling much easier in combination with Blaze.
The Microscope article uses pure Blaze with jQuery which I can’t really recommend anymore, especially because everything goes into component logic now.
@sashko That’s exactly what Simple CRM is intended to be. I’ve tried to come up with the smallest possible example that covers all the common scenarios. It’s currently React/Redux, but I’m sure someone savvy in blaze could knock up a different UI pretty quickly, perhaps also an example in autoforms.
I’m very happy to change Simple CRM’s functionality to work as per MDG’s requirements for the line of business example if that helps.
Simple CRM is the basis for our production code, but our production code has a lot of improvements over Simple CRM now (components converted to ES6 or functional stateless components, more testing, beginnings of React testing etc.). I’ll start to feed those improvements back into Simple CRM over the next few weeks.
The Clinical Trials demo app is the third iteration (v3) of a forms-based app that various pharmaceutial companies have experimented with and invested in. It was the basis for the California Kids Cancer Comparison rewrite (v4), and is now in private-beta running campaigns for a group in New Zealand (v5), and we’re working on a 6th iteration.
And I just have to say… we got burned badly by Autoforms in v4. And it wasn’t for a lack of trying and getting working solutions out the door. There’s just too many abstraction layers in it; and all the nested templates make it very difficult to debug. The ecosystem of packages looks compelling… until you realize many of them are abandoned and/or don’t theme with the rest of your app; meaning it’s not a coherent framework and you have to fork and hack them (then give up in frustration, thereby increasing the overall number of not-great packages in the ecosystem).
We also found that there were competing interests between wanting to define everything in a schema; wanting to store those schemas themselves in the Mongo database; wanting control over styling; and wanting custom flow-control. It’s one thing to create a form from a schema. But when people start asking for form builders, the schema then needs to be dynamic. And Autoforms just wasn’t designed for such use-cases.
So we backed it out and removed it in v5, and are having much better success writing forms with pure Blaze. End result is that we spent nearly six months of work trying to implement a generalized Autoforms solution that stored dehydrated schemas to disk; when we could have just written pure-Blaze forms in a fraction of the time.
I hope this isn’t taken as criticism of Eric, who did an awesome job with SimpleSchema, which we currently use in all of our apps. It’s just that Autoforms sort of developed a life of it’s own and grew way beyond what it was originally intended for. (It’s sort of the Audrey II in the Flower Shop.)
Personally, I would ask that Autoforms not make it into the Guide, precisely because I think people will try to abuse it and use it for things that it wasn’t designed for. Which sets them up for frustration and failure. And then folks like me get called in to try to clean up the mess that’s made as a result. And I don’t want those kinds of kludged apps landing at my doorstep.
Do you have some examples of what this looks like in your app? Curious how writing forms without autoform ends up looking.
It’s just mostly plain-jane Blaze code.
UpsertQuestionnaire
QuestionnaireActionButtons
Ignore the inline styling hooks, but do take a look at how we’re using the {{linkId}} and {{getLinkId ..}} helpers to tie each question in the questionnaire together. Getting the parent context is the important step for associating answers with the questions.
Other than that, the biggest philosophical question seems to be whether to hook to the submit action, which requires your Save button to be physically within the <form> itself; or if one needs to save the form from elsewhere in the GUI, in which case one would need to to use a click event.
By the way, those components are relying on SimpleSchema and the HL7 Questionnaire and QuestionnaireResponse resource schemas.
So simple-schema is being used, just like Autoforms… but at the collection level; rather than at the form level. IMHO, it’s a much more manageable approach and scales better.
Just noticed that Guide now has a search powered by SwiftType. It works so fast and seemingly well, I wish more Meteor-related sites had search working that well 
Just noticed the new search engine too, it works great! +1 for same thing in docs and other sources.
+1 to make a guide on how to implement such instasearch in my own app!
@sashko thank you so very much for writing the guide. When it was introduced first, I was against it in my heart because I was working as the only developer for my project. Now that I am working with 5 other guys in a project, the only savior from the clusterf**k of messy code seems to be the guide.
Its defined app structure & code style has saved us from doom. Thank you man !
I’m officially in love with Sashko and MDG.
Amazing guide, amazing docs. I especially love that the guide sometimes teaches you about things other than Meteor, in order to make the Meteor developer experience better.