Que son las Visual Quick Funtions y como las implementamos.

Funciones, vistas, registros, usos

Que son las Visual Quick Funtions y como las implementamos.

Entender el flujo de trabajo de Viral es elemental


Un poco de contexto

Para comprender en profundidad los que son las "QVF" (quick visual function) en el universo Viral Click (VC) , es primordial entender la filosofía de trabajo, de todo producto que vuela bajo el ala de este Software.

Cuando un usuario/visitante accede un link cualquiera de una plataforma VC, esta accediendo a través de una petición (GET, POST u otra), a la data web, que no es más que toda la información necesario para construir la vista de ese link, empaquetada en un par de variable, la más importante de todas la "$web".

A partir de este momento, toda interacción queda a cargo de la ui, por que refrescar la vista es la ultima opción y el recurso de redireccionar, solo esta pensada para cambiar de vistas y navegar en la web. 

Entonces, para definir el formato de una plataforma, es importante saber crear y gestionar nuestras variables de data web, como también, modificar y agregar nuevos datos a las ya existente variable $web.

Para entenderlo de una manera practica, las VQF son las que dan la identidad, en concepto de funcionalidad a una plataforma.

Toda VQF requiere de :

  1. Formulario visual para presetear parámetros de funcionamiento.
  2. Lógica gestora de información y/o vistas.
  3. Modelo de Registro de datos *si se requiere.
  4. Vista interactiva o una zona de ejecución *si se requiere.

Creando una QVF

Okay, a lo que vinimos, vamos a implementar una QVF, que formara parte del pool de funciones que hacen a viral click. 

Las QVF son todo, y sobre todo, es importante verlos como un bloque funcional dentro de un conjunto de bloques. Siguiendo, con este pensamiento, vamos a desarrollar un bloque que clausure el registro de administradores cuando el sistema ya este instalado para el cliente.


1) Formulario para la configuración de mi bloque.

Como solo necesitamos saber cuando ya no queremos que este disponible el link de registro, vamos a requerir de un "switch" que es un checkbox para definir el estado "close" y "open".

Ubicaremos este check, dentro del menú flotante lateral derecho, en la sección de configuración. El archivo blade que vamos a trabajarlo, se encuentra en view/metronic/parts/quick-sidebar.blade.php

El pedazo de html base, que agregamos en el lugar adecuado y con cuidado, dentro del archivo es:

                            <span class="m-list-settings__item-control">
<span class="m-switch m-switch--outline m-switch--icon-check m-switch--brand">
<label>
<input
class="btn--change"
data-token="{{ csrf_token() }}"
data-url="{{ route('change.state') }}"
type="checkbox" {{ (($web->r('state_registre')==="open")?'checked':'') }}
name="change">
<span>
</span>
</label>
</span>
</span>


Si observamos detenidamente el atributo checked, es el que define el estado del check, por lo tanto requiere de una mínima lógica que consulta el estado dentro del resource del $web, para ello usamos la función r('state_registre') y pasando la clave del resource a obtener.

type="checkbox" {{ (($web->r('state_registre')==="open")?'checked':'') }}


Ahora por medio de este checkbox, hacemos uso de una función jscripts que incorporaremos al archivo public/mtc/assets/app/js/connect.js, para un futuro uso dentro de VC. 

Para ello, le defendimos la clase "btn--change", que será la responsable de capturar el click que cambia el estado y dispara la función que registra en el servidor el cambio de estado.

Pero para hacer más rico el artículo, también incorporaremos los recursos js que captura el estado, registra e informa al usuario de cambio.

//@Change & Push
$ ('.btn--change').click (function () {
toastr.options = {
closeButton: true,
debug: false,
newestOnTop: false,
progressBar: true,
positionClass: 'toast-top-right',
preventDuplicates: false,
onclick: null,
showDuration: '300',
hideDuration: '1000',
timeOut: '5000',
extendedTimeOut: '1000',
showEasing: 'swing',
hideEasing: 'linear',
showMethod: 'fadeIn',
hideMethod: 'fadeOut',
};
//@ico--span>
//@connectsData
let token = $ (this).attr ('data-token');
let url = $ (this).attr ('data-url');
$ (this).attr ('disabled');
$.post (
url,
{
_token: token,
state: $ (this).is (':checked') ? 'open' : 'close',
},
function (response) {
let data = JSON.parse (response);
if (data.status == '200') {
return toastr.success (data.response);
} else {
return toastr.error (data.response);
}
}
);
$ (this).removeAttr ('disabled');
});


Este recurso es codificado con jquery, cuenta con un  toastr para informar los resultados y un método POST para gestionar la inserción de datos. Es importante no olvidar las etiquetas data-url y data-token, que son requeridas en el post.

En el checkbox solo nos preocupamos por especificamos la url a donde enviamos la información y el token de acceso a los datos, todo lo demás lo realiza el evento js.

A la url que la definimos en la etiqueta data-url del check, la obtenemos con la función route(), la cual quedaría,

route('change.state'), a esta ruta la enlazaremos con los controladores encargados de registrar el dato que queremos guardar.

2) Controladores para el registro de estado.

Definimos una ruta del tipo POST dentro del archivo web.php y la llamo "change.state". Esta ruta apunta a una función __actualizeDataWeb(), dentro del trait ManagerData.php que se encuentra en la carpeta App\Tasks.

# web.php

//Pablo: gestiona el estado del Registro admin
Route::post('/change/data/web','Structure@__actualizeDataWeb')->name('change.state');


#Función __actualizeDataWeb() que pertence al trait App\Tasks\ManagerData.php


/** Gestiono los datos del resource del Web */
function __actualizeDataWeb(Request $request){
$web = Section::getHome();
if($request->has('state')){
$data = $web->getResource();
$data->state_registre = $request->state;
$web->update([
'resource'=>json_encode($data)
]);
return json_encode([
'status'=>200,
'response'=>'Se cambio con éxito el registro a '.$request->state,
]);
}
}


3) Haciendo uso de nuestra Quick.

Ahora solo nos queda implementarla y que cumpla con lo que promete, para ello vamos a codificar un poco el controlador App\Http\Controllers\Auth\RegisterController.php, incorporando un bloque de verificación en la función showRegistrationForm() que entrega la vista del registro. La lógica que escribimos no es complicada y se adapta perfectamente a lo que buscamos.



public function showRegistrationForm()    
{        
if(Auth::guard()->check()){            
return view('auth.register');        
}else{           
$web = Section::getHome();
return $web->r('state_registre') == 'open'            
? view('auth.register')            
: redirect()->route('viral.hello');        
}    
}


Todo cliente que pretenda acceder al formulario de registro, lo hará a través de la función showLoginForm(), la cual consiste en verificar, que si el usuario esta logueado, será redirigido al panel de control. Pero si no lo está, aquí entra en juego todo lo que hicimos.

Obtenemos la section "home", donde se encuentra toda la data web de la plataforma, que a la vez contiene nuestro estado de registro y la guardamos en la variable $web.

Por último, decimos que si el estado es "open", permitimos el acceso al formulario, si no, será redirigido a la página principal.


CONCLUSIÓN 

Este bloque funcional, se podría seguir mejorando y optimizando. También, se lo tendría que incorporar, dentro de la función que realiza el registro de un nuevo usuario, para evitar que realizando una petición post, sin necesidad del formulario y pudiese llegar a hacerse de esta función. Pero es material para otro artículo.

Otra variación de la solución, sería guardar el estado del registro, en la tabla de estados generales usando el modelo GeneralState, pero también es para otro artículo especial.






Publicado hace 1 año