2012-03-07 12 views
12

Recientemente creé un controlador de enlace para incorporar el complemento JQuery Validation en un formulario utilizando la sintaxis de enlace de datos. Me encontré a mí mismo necesitando suministrar más de una información al manejador. Necesitaba proporcionar una bandera para aplicar la validación y una devolución de llamada para disparar una vez que se pasaba la validación.Controladores de enlace personalizado knockout: argumentos múltiples y devolución de funciones a la práctica recomendada.

Preguntas:

  1. ¿Cuál es la mejor práctica para el suministro de múltiples argumentos? Simplemente confié en la sintaxis de notación de objeto, pero también podría suministrar otro enlace y verificar que el enlace a través del parámetro "allBindings" pasara al manejador ...

  2. ¿Cuál es la mejor práctica para suministrar una función de devolución de llamada a un manejador? ?

A continuación se muestra el código JS definir el manejador y el código HTML para aplicar el manejador:

 <form id="step1" 
     data-bind="jqValidation:{enforce: true, 
           submitHandler: doSomethingInVM}"> 
      <fieldset data-bind="with:searchRequest"> 
      //fields 
      </fieldset> 
      <button type="submit">submit</button> 
    </form> 

 ko.bindingHandlers.jqValidation = { 

     update: function (element, valueAccessor, allBindingsAccessor, viewModel) { 
      var accessor = valueAccessor(); 
      //need unwrapobservable?? 
      if (accessor.enforce) { 
       $(element).find(':submit').removeClass('cancel'); 
       $(element).validate({ 
        submitHandler: function() { 
         if ($.isFunction(accessor.submitHandler)) 
          accessor.submitHandler(); 
        } 
       }); 
      } else 
       $(element).find(':submit').addClass('cancel'); 
     } 
    }; 

Respuesta

0

dar respuesta tanto a sus preguntas, una práctica muy recomendable cuando se utilizan knockoutjs y el patrón MVVM consiste en encapsular propiedades y métodos relacionados con sus objetos en sus respectivos modelos de vista.

Dicho esto, funciona muy bien tener propiedades (argumentos si se quiere) y métodos de devolución que serán responsables de actualizar su modelo de vista (o desencadenar actualizaciones a otros objetos debido a cambios en su modelo de vista) para residir en el modelo de vista en sí.

Luego, dentro de su controlador de enlace personalizado, puede simplemente hacer referencia a cualquier propiedad que necesite directamente desde su modelo de vista, así como llamar a cualquier función de devolución de llamada que resida en el modelo de visualización.

El encapsulamiento de miembros y comportamientos de esta manera hace que sea muy sencillo probar también cada modelo de vista.

8

Su enfoque aquí sigue el patrón utilizado por KO en sí, así que creo que es perfectamente válido. De acuerdo, también podría usar allBindingsAccessor. La forma en que he interpretado el uso de este método es a

  1. propiedades comparten entre varios enlaces, por ejemplo, un bubbleEvent unión podría ser utilizado para indicar a cualquier otra unión que se ocupa de los acontecimientos a no burbujear ellos.
  2. Para permitir que los controladores de enlace complejos conozcan otras vinculaciones y ajusten su comportamiento.

La mejor práctica para los controladores de paso es tenerlos como miembros con nombre en su modelo de vista en lugar de en línea en el enlace.

+0

Gracias, ese fue mi pensamiento sobre el método allBindingsAccessor también. Entonces, en mi caso, ¿no pasarías el controlador en el atributo de enlace de datos? – drogon

+0

Lo pasaría como parte del objeto que hace referencia a su máquina virtual exactamente como lo ha hecho. También puede escribir el controlador en línea, que es feo y se considera una mala práctica. – madcapnmckay

+0

Ah, sí, estoy de acuerdo, soy culpable de algunos de los que están en mi primer proyecto de ko :) – drogon

Cuestiones relacionadas