Good alternative for AutoForm

community
1

For last 4 months I’m using aldeed:autoform for building CRM system. In the beginning I fall in love with it, but after a while I found how hard is to use and modify and debug it’s components. It’s really complex package with a lot of layers.
Second problem is that it’s quite buggy. There are quite a few bugs in autoform’s issue tracking where people are reporting bugs and aldeed is not able to reproduce them. I also tried to reproduce a few bugs reported by me and a few other guys, and on new codebase it’s kind of works, but on my app, it’s not :frowning:

Do you know any other good alternative I could try?

6 Likes
2

Why use anything? Roll your forms from scratch. I’ve been finding that only using aldeed:simple-schema has been a nice compromise between getting validation and having the extra customization available.

8 Likes
3

Agreed, I really like collection2 & simple-schema (albeit there are still some bugs & outstanding PRs). I still use autoform for 1 form, but I’m looking to replace that with my own code soon enough.

4

I too feel like autoform and any forms package is just unnecessary external complexity/dependency but if the app is one where there are lots of forms, one tends to require a component library to handle all the html boilerplate, visual presentation of the multiple states of the form etc.

So I think we indeed need a reactive and lightweight forms framework which does not try to do everything.

I think there are two or three other forms packages on atmosphere and at least one of them claims to be way better than autoform.

1 Like
5

I think you’re referring to templates:forms:

https://atmospherejs.com/templates/forms

I’m still too new to know the various pro’s and con’s but I do like the ability to automatically create forms that work while figuring out what the app needs.

The other factor here is this is open source: the more advanced programmers that can check out aldeed:autoform source and debug and fix it aren’t likely to be the ones relying on it for their apps, but at least it is possible. I also haven’t gotten to debugging into package source yet either.

2 Likes
6

Yep, that’s the one.

I often find myself getting in a package and after some time using it, if I see that I use only some percentage of it, grabbing out those parts that I actually depend on and know I could maintain.

1 Like
7

Not good advise to roll own form, why not just roll own framework? We need forms packaged to help adopters gradually find their way around. The problem with autoform is the main maintainer got his hands on many other packages. We need experienced developers like you to help make contrib packages better

2 Likes
8

Does anybody already tried templates:forms on production? Any comments?

1 Like
9

Aaaw. Thank you. I appreciate that.

I’d love to be able to concentrate on framework development more; but it’s tough because bills have to be paid, which means taking on client work, which means I don’t get to focus as much time maintaining packages and doing framework development.

Regarding OP, I think he’s been using autoforms and meteor long enough to be ready to start rolling his own forms. Maybe there needs to be a better alternative to autoforms for other people new to meteor. But OP seems to be getting familiar enough with autoforms that he understands the layers, is able to judge the pros and cons of different packages, and is looking around for other solutions. Rather than looking around for a replacement, I’d suggest that he’s actually ready to take the training wheels off, so to speak, and use the underlying core APIs.

1 Like
10

I like autoforms, but when I do not need its complexity, I use my own tiny package for client/server validation. You can have a look here: https://github.com/YuukanOO/lily . I have implemented a fromTemplate and fromObject to construct a simple validation object respectively from templates and raw objects.

I’m kinda satisfied for now :slight_smile:

1 Like
11

+1 for templates:forms.
I am using it for a while now. It is still young and unpolished, but its architecture is better than autoform’s one IMO.

12

@Steve there seems to be no other reference to templates:forms’ awesomeness other than its author’s remarks.

Now that you back him up :slight_smile: could you please share your experience with it and the ways you actually think it is better than autoform and the polished/unpolished parts in your opinion?

Thanks!

13

What about localization for templates:forms?

14

@serkandurusoy:

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
15

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.

16

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
17

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 :slight_smile:

4 Likes
18

It’s always fun and surprising to see all the various perspectives.

10 Likes
19

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
20

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