ampersandjs / ampersand-form-view Goto Github PK

I just noticed that listenTo, listenToOnce, and listenToAndRun are not methods of the form-view instance. Is this correct? Shouldn't it inherit it those from ampersand-view?

Ran into an issue recently with an invalid form field preventing the form from submitting. Right now an invalid class is added to an element, but it would be nice to have a method on the class to get a list of invalid form fields.

var invalidFields = formView.invalidFields();

Try this:

var AmpersandFormView = require('ampersand-form-view');

var TestForm = AmpersandFormView.extend({
    initialize: function(attr, options) {
        console.log('1');
    },
    render: function()
    {
        console.log('2');
    }
});

new TestForm();

The output is:

2
1

This doesn't seem right to me. Ampersand-view does it the other way.

I think the issue is lines 31-35 in the src. Three things happen:

1. Render the form
2. Render all the fields
3. Initialize

I had to reorder them as 3, 2, 1 because:

• I needed information passed from the constructor to build my field elements dynamically. I could not just declare the fields variable in the .extend call as shown in the examples.
• The fields needed to be rendered by the time I get to my render call because I append another element (a submit button) and apply some style-hacks (set autocomplete to off for all fields in the form via jquery properties) that need this.el to be populated.

My render looks something like:

render: function()    {
    AmpersandFormView.prototype.render.apply(this, arguments); // Get all the default FormView stuff done and create Fields

    $( this.el ).find('input').prop('autocomplete', 'off'); // Turn off autocomplete

    this.button = $('<input type="submit">').appendTo( $( this.el ) ); // Add a submit button!
}

I also ended up just making step 2 part of the FormView render call. I don't see why the fields would try to render if the FormView itself hasn't tried to render.

Does this make sense?

Thanks,
Ben

This module uses the same naming as other Ampersand views, but it does not extend ampersand-view, nor does it follow the view conventions specified in http://ampersandjs.com/docs#ampersand-view.
I would suggest re-coding so that it extends from ampersand-view, or renaming this module to just ampersand-form to avoid confusion.
A similar issue has been raised against ampersand-select-view: AmpersandJS/ampersand-select-view#2

state 4.9.1 is pulling in a lot of old lodash 3.x modules.

If all the fields have a getValue and setValue then it would be possible to expose them at this module as getValue(field) and setValue(field, value)

A getValues and setValues that returned and accepted a hash would also be possible.

As a developer, I want to create a form view and only listen to changes of its "data" property, so that I can conveniently handle data changes.

This is especially useful for forms that autosave on data change and forms with dynamic fields.

Currently the "data" property is a cached derived property that will never emit any events. The documentation states otherwise:

https://www.npmjs.com/package/ampersand-form-view#properties

The following are FormView observables, thus emit "change" events:

valid - the valid state of the form
data - form field view values in { fieldName: value, fieldName2: value2 } format

Possible solution: Extend the update method to also trigger a "change" event passing the "data" property.

I feel like I must be missing something but I can't find any reference to adding a submit button to a form. There are references to the submit event, which I imagine would be called by hitting enter while an <input> is in focus, but that's the closest I see. The only thing I can think of is providing a template to the form view. Is that the only way?

EDIT: Looks like the submitCallback isn't triggered by hitting enter unless there's a submit button in the form somewhere

Having a bit of a hard time getting this working. Documentation in this repo and on ampersandjs.com aren't consistent. Also no example of triggering the form submission.
I would love to see a complete example :)

Feature request: support a general change event when a field changes, and not just change:field.

This would match ampersand-state and ampersand-views behaviours.

Currently I do this by:

view.on('all', function(eventType) {
    if (/^change/.test(eventType)) {
        //match all change events
    }
});

which is less than ideal.

It would be nice to simply do:

view.on('change', function() {
    match all change events
});

This issue is related to #8, #20, and #42.

I’m a little confused about the example in the README.md.

Inside the class’s render(), the code calls new FormView and this.registerSubview. To me, these seem like things that should be in initialize() instead.

Is there a reason that they are in render()? Will rendering break if that code is moved?

Oki, I'm new to Ampersand, but here goes;

I have this form:

var FormView = require('ampersand-form-view');
var InputView = require('ampersand-input-view');

EditForm = FormView.extend({
  initialize: function(options) {
    debug('initialize', this.el, this.autoRender, this.submitCallback)
  },

  fields: function () {
    debug('fields!')

    var fields = [
      new InputView({
        label: 'Name',
        name: 'name',
        value: utils.getDotted(this, 'model.name'),
        placeholder: 'Name',
        parent: this
      })
    ];

    debug('fields', fields)

    return fields;
  }
});

And I want to use it in a couple of views, the render-method exemplified here:

render: function () {
    this.renderWithTemplate();

    this.form = new EditForm({
      autoRender: true,
      el: this.query('.edit-form'),

      submitCallback: function (data) {
        debug('submit', data);
      }
    });

    this.registerSubview(this.form);
    return this
  }

-this does not work.

Embedding the form code in a non-extended ampersand-form does work:

render: function () {
    this.renderWithTemplate();

    this.form = new FormView({
      autoRender: true,
      el: this.query('.edit-form'),
      fields: [
        new InputView({
          label: 'Name',
          name: 'name',
          value: utils.getDotted(this, 'model.name'),
          placeholder: 'Name',
          parent: this
        })
      ],
      submitCallback: function (data) {
        debug('submit', data);
      }
    });

    this.registerSubview(this.form);
    return this
  }

What am I missing?

Hi,

I've only found this way (setTimeout) to activate a custom checkbox once a FormView is rendered.
Is there a proper way to do so?

var ContactView = View.extend({
    autoRender: true,
    template: '<form></form>',
    render: function () {
        this.renderWithTemplate();
        this.form = new FormView({
            autoRender: true,
            fields: [
                new CheckboxView({ name: 'newsletter', label: 'Newsletter'})
            ],
        });
        this.registerSubview(this.form);

        //
        // here is the temporary fix
        //
        setTimeout(function () {
            $(this.query('.ui.checkbox')).checkbox();
        }.bind(this), 0);

        return this;
    }
});

Not a big deal, but I didn't see docs on the fields property. It looks like field views in this array are generated and placed within <label> tags

A use case: I have two, numeric text inputs. One cannot be greater than the other. How would I validate that using ampersand input/form/whatever and still have input errors/messages work without extra code?

If you do it at the input level using test methods (which only have local value available), you have to use external variables (self.model or something). If you do it at the form level it's the same issue where data available internally to the object isn't enough. If you do it at the model level (with validate()) then you have the issue if manually triggering an invalid state on inputs.

I really hope someone has a simple answer for this. I haven't found one yet.

@wraithgar, I can extend my own formView to accommodate my needs, but thought this feature may be useful for others as well. How would you feel about a PR for adding a complete property to the FormView?

It would signify that the form is in a state where all fields have been validated and the form has been submitted (at least once). The case could exist where you leave your form on the page post-submit, and then additional changes are made. This state could feasibly invalidate the intent of complete in that the form would be complete, but still clearly inwork as it exposed to the user. However, this could simply be documented as an edge case.

What's driving this idea is that I'm making a form-manager/questionnaire view. I need to get state updates on many forms from a single source. Another idea is to perhaps add a mixin to support this feature.

complete, submitted, beenSubmitted, submitCount, completeCount -- all could imply the same thing

After submitting a form, one often wants to clear the form of all _fieldViews values. Add a #reset method.

Just never don't bind it to a "Reset Form" button. Those are awful.

problem statement

Some formField views render() immediately on construction. This is undesired behavior.
If the FormView doesn't render immediately, some child fieldViews will still claim .rendered,
which is a false claim. Consequently those child-views may not display at form.render() as a FormView will think that they are already rendered. :(

potential solutions

1. update each FieldFiew to not autorender. e.g. match &-view behavior
   1. a complimentary update to view-conventions would likely need to be required
      1. maybe a test for visibility or if a parentNode is set, which it shouldn't be, unless render has been called directly or if autoRender enabled
2. update fieldViews to extend &-view, and support autoRender in initialize()
   1. this is a nice solution, as the fieldViews become extendable for user needs with all of the other goodies &-view offers

this was likely introduced by my update to support autoRender in &-form-view, but regardless, needs to be addressed.

In the README.md example, the class simply extends the Ampersand’s normal View, and then recreates a new FormView on every render(). (I asked about the implications of this in Issue #24.)

Why not just extend FormView? Does it not work? Are there disadvantages?

I have been (intensely) learning Ampersand for the past several weeks, but I am a little confused about all this. The example is doing many things differently from what I have come to expect when using extend to create custom States/Models/Views.

I have fields with names like products[] and statuses[] and now, because of the introduction of lodash.set(), the names are being converted to products and statuses (without the brackets). My API is expected the bracketed names.

I'll see if I can create a PR that allows for what 5.2.0 and lodash.set bring to the table without breaking this expected functionality.

It would be nice if the view emitted a valid event whenever it's valid property changed.
Right now, I have something like this:

FormView.extend({
    validCallback: function(valid) {
        this.trigger("valid", valid);
    },
})

However, it's a pain to add it to all my forms, and I fires every time (vs. just when it changes).

Versions of ampersand-view before 9.0.2 depend on [email protected] - this has just been removed from npm.

Any chance of this module updating it's ampersand-view dep?