What about localization for templates:forms?
Opposing templates:forms to aldeed:autoform, as I just did, is not appropriate.
aldeed:autoform is a form generation package. It has been designed to automatically generate insert and update forms for collections. It is coupled with aldeed:simple-schema and aldeed:collection2 in many subtle ways. If your goal is, in prototyping phase or for debug purpose, to quickly get forms to populate your collections, then aldeed:autoform is probably the way to go.
templates:forms is a form design package. Its purpose is to to help you designing and reusing form UI components and workflows. It is the best package in its area because, as far as I know, it is the only one! You can try designing forms with aldeed:autoform, but, doing so, you’ll probably end up agreeing with @awatson1978: “Roll your forms from scratch”. aldeed:autoform is just not the right tool for that.
I use templates:forms in its most basic usage:
Designing a reusable input field, with a label and an error message for failed validation (the error message is displayed only after a first submit):
<template name="bootstrapFormInput">
<div class="form-group
{{#unless valid}}{{#if submitted}}has-error{{/if}}{{/unless}}">
{{#if schema.label}}
{{schema.label}}
{{else}}
{{field}}
{{/if}}
<input name="{{field}}" class="form-control reactive-element" value="{{value}}"
maxlength="{{#if schema.max}}{{schema.max}}{{/if}}">
<p class="help-block">
{{#if gh_and errorMessage submitted}}
{{errorMessage}}
{{else}}
{{schema.instructions}}
{{/if}}
</p>
</div>
</template>
Designing a reusable form:
<template name="bootstrapForm">
<form>
<!-- Form fields -->
{{> UI.contentBlock data=data context=context}}
<!-- Submit button -->
<div style="margin-top:25px; height:50px;">
{{#if loading}}
{{> smallLoader}}
{{else}}
<a type="button" class="btn btn-default" href="{{cancelLink}}">
Cancel
</a>
<button type="submit" class="btn btn-primary" disabled=
"{{#if gh_and invalidCount submitted}}disabled{{/if}}">
Submit
</button>
{{/if}}
</div>
</form>
</template>
Using the reusable form:
{{#bootstrapForm cancelLink="/" schema=th_schema action=th_action}}
{{> bootstrapFormInput field='firstName'}}
{{> bootstrapFormInput field='lastName'}}
{{/bootstrapForm}}
templates:forms is unpolished because:
- The doc focuses on advanced usage instead of basic one.
- There are some missing features (see the issue list).
- The guy is alone. This is tough because forms are a fundamental feature with many use cases.
4 Likes
Hmm sounds very interesting but I don’t quite get where template:forms fits in since your code examples look a lot like the way we’d do it with stock spacebars.
So my question now becomes, where do you see the added value in using that against out of box meteor tools?
Also thanks for clarifying that comparing those two packages would not make a valid comparison.
That is, precisely, the mark of a good package.
It provides useful helpers to access field validation states, state of the form (submitting, submitted, etc.), the underlying schema, and many other little things you can implement by yourself.
In that respect, templates:forms could be to forms what collection-helpers is to collections: simple, straightforward, limited in scope. I say “could” because I think there is still some work to do on the doc and naming side.
1 Like
Oh now I see, and wow! Thanks!
I guess this is one of those underrated packages that go unnoticed and needs some marketing.
If perhaps @msavin came up with a cool name and a launch announcement text along with some catchy phrases 
4 Likes
It’s always fun and surprising to see all the various perspectives.
10 Likes
I really like the formation package.
https://github.com/quietcreep/meteor-formation/
It wraps your collection into a model and gives you ready to use input templates which can be overwritten:
Items = new Formation.Model({
collection: new Meteor.Collection('items'),
schema: {
itemName: new Fields.Char({ max: 100, required: false }),
},
savable: function () { return true; },
editable: function () { return true; },
beforeSave: function(){ ... },
afterSave: function(){ ... },
});
<template name="myItems">
<form class="form-horizontal" role="form">
{{# each errors }}
{{! show top level errors }}
<span class="errors">{{ message }}</span>
{{/ each }}
{{> dxField itemName }}
{{> dxButtons }}
</form>
</template>
New Instance are really simple:
var myNewInstance = new Items.newModelInstance({itemName: 'foobar'});
myNewInstance.save();
The package is rather unkown up to now and definitly deserves more attention.
3 Likes
Hi Everybody,
I am the author of the templates:forms package. I can tell you that I will be evolving and maintaining this package for the long-haul, and I am very motivated by the positive feedback I’m getting here and on GitHub. Thank you.
I will be doing some more cosmetic work on the package soon (docs, naming, etc.)–there’s a great draft of some new docs already in the works.
If you haven’t tried the package yet, I hope you will. Building a good non-invasive package is my ultimate goal. That’s why, as was mentioned earlier in this thread, it feels like you’re just using plain old Blaze–because you are. No hacks, no crazy APIs, nothing scary under the hood.
There’s not much to learn unless you’re trying to do something complex, and even then there’s not much to learn. The package supports things like nested components, and offers other features to maximize reusability and make your life easier in development.
I continue to address issues and feature requests, and I am using the package in production on a serious Meteor app at a venture-backed startup where I work as CTO (we’re hiring, by the way–PM if interested).
It’s funny that someone mentioned @msavin helping with promotion. I know him in real life–in fact, we’ve been planning to get coffee and I was going to ask him if he wanted to help me promote this and a few other open source projects I’m working on. It’s possible, but not super easy, for one person to do it all. And of course there’s an open invitation for anyone else to get involved if they want!
Jon
14 Likes
I’d really like to do this, but it’s not just AutoForm. It’s the combination of that with Collection2 and SimpleSchema2 that bring in the value.
To me SimpleSchema is a real gem.
Where do I start when trying to figure out client side schemas, client side validation, default values, and error messages?
1 Like
@yuukan, do you have a simple app that use your package =) i’m too is looking for a simple and lightweight autoform
Kind of an old thread, but I just wanted to say that we should resist the impulse to just jump ship to another package as soon as the one we use gets too big or too unwieldy.
Autoform can seem complex and hard to understand, but it’s still an amazing package that gets a ton of things right. I know @aldeed is planning on simplifying some things, making it more modular, and improving the docs.
So I think it’s worth trying to help him out and contribute to the effort, instead of looking elsewhere for a different solution that will probably end up having the exact same issues a couple months down the road.
9 Likes
Thanks @sacha. And thanks to all for bearing with me on issue backlog. Will be getting caught up soon.
2 Likes
Hey aldeed. Thumps up. I like your work. At least I use SimpleSchema and I love it. But I also love simplicity and flexibility, so when I had to choose a form package for my app, I went for templates:forms. And the beauty is that templates:forms uses SimpleSchema for validation. And this is great for the community. We have options, and we love the options. If you haven’t tried out templates:forms, just give it a try. You will love it.
+1 for templates:forms, although the current doc is not so good and the new doc, despite @jamz’s promises, is still not there 
I’ve made a lot of progress towards removing autoform, simples schema, and collection2 (and heck even Iron Router subscriptions) from my project (with all due respect to aldeed).
I removed all the getFieldValues and use ReactiveVars/ReactiveDict instead. Also, I used this vid and was able to get reactive validation working just the other day. It’s a long road, but every chance I get, I remove more dependencies.
I’ve actually learn a lot from the process of removal.
Thanks to aldeed for helping me get started with forms in Meteor.
1 Like
This.
I’m looking at meteortemplates:forms and typical of many projects, the activity follows a similar inverse parabolic pattern (1/x^2). Last activity 25 days ago on devel, last comment a month ago.
It’s disheartening to hear the more advanced meteor devs drop a open source project to ‘roll their own’ rather than contributing to it. Maybe someday they’ll start a new and awesome forms project which everyone buys into, ask for features, gets large, flexible and complex and then gets dropped because there are too many bugs and no one wants to contribute.
1 Like
There is no response to issues on the autoform repo from aldeed anymore. Currently almost 300 open issues. Aldeed has state he thinks autoforms is ‘complete’. PRs seem to be ignored, 6 open at this time. It doesn’t seem like he’s open to loosening control to others (no one else is abled to accept PRs AFAIK). No viable forks of autoform that I can see at this time.
There are bugs I’ve posted and supplied a repo example of almost a year ago that still are solved.
For example,
Radio controls. A very common form control. Yet validation doesn’t work on them when the form is in ‘update’ mode (only in ‘insert’) mode. This has been an issue for over a year. I recently created a new ticket (even though there’s an old one too), just to see if aldeed would respond: https://github.com/aldeed/meteor-autoform/issues/1270 and here’s the old one from almost one year ago: https://github.com/aldeed/meteor-simple-schema/issues/182
This is why it’s really hard NOT to search for alternatives. But there seem to be none that come close at the moment.
For me, I’ve tried to just do forms without any aldeed tools. But it’s really hard, mainly because of reactive validation and the schema.
If there was an easier way to do reactive validation on any number of controls, I think I’d make jump to doing ‘forms’ completely by hand.
Aldeed is a great guy that has help many, I just hope that he will truly ‘release’ this product to the community to keep it going in his absence.
1 Like
Right, this sounds like a good compromise to me also. I might try this someday. But my main problem is the validation in simple schema custom function not working on select-radio controls in update mode.
Have you tried https://github.com/usefulio/forms ? I saw a devshop presentation on it, looked pretty good
2 Likes
AutoForm “state” is a recurrent pattern or anti-pattern. We have the best form package that any platform can dream but we are bound to his bad part too. Is like Pink Floyd, the best to hear but always going a hear the same songs.
I think Eric, @aldeed, have the same problems than us. Wainting for Blaze future or not future, a lack of resource to mantain and support packages.
Maybe we have to wait a little for MDG official Blaze complains and then decide to start from scratch with other form package.