Serializando con tag-helpers

[juanvvc]

coñe, que el ejemplo te lo he puesto arriba ya dos veces. Venga, la tercera:

<input class="form-control nombre" asp-for="@Model.lista[i].nombre">
<input class="form-control apellidos" asp-for="@Model.lista[i].nombre">

...

// lo de antes igual, incluso para obtener la referencia a la row si no quieres usar identificadores por alguna razón

// aquí lo realmente nuevo: saca los datos uno a uno, no todos a la vez:
var data = {
   nombre: row.find(".nombre").val(),
   apellidos: row.find(".apellidos").val(),
   apellidos: row.find(".otracosa").val(),
}
window.location.href = url + '?' + data.serialize();

No he dicho que usar clases sea arcaico porque no lo es. Al revés, es totalmente normal en HTML

Todos los elementos html tienen un atributo data- donde puedes poner información extra para javascript, pero no lo uses, haz pocos cambios como los que te propongo y ya está

Porque mi propuesta fundamental es esta:

- Tú has usado la línea var data = row.find("input, select, textarea").serialize();, que mete todos los datos en una cadena. Luego propones parsear esa cadena
- Yo te digo que no te canses, que saques los datos uno a uno y no parsees.

var data = {
   nombre: row.find(".nombre").val(),
   apellidos: row.find(".apellidos").val(),
   apellidos: row.find(".otracosa").val(),
}

y lo único que tienes que hacer para aplicar esto es añadir "nombre" o "apellidos" a las clases de los input correspondientes

[josepzin]

Cuando pones "data-" en realidad funciona como un atributo normal que se puede leer de cualquier manera, lo de "data-" es mas un convencionalismo.

Por ejemplo data-pache="LOL" se puede leer lo mismo si pones pache="LOL"

En JS puro sería algo asi como element.getAttribute("pache");

-----Actualizado-----

lo de "data-" es mas un convencionalismo.

Igual lo he dicho sin comprobarlo... en todo caso creo que funciona de las dos maneras sin problema.

[Drumpi]

Gracias.

Juanvvc, me refería que me hablabas de los data-, pero no me dabas ejemplo de eso. El resto sí que lo he pillado.
Fíjate si lo he pillado que ya lo he implementado y me funciona, pero...

<script>
    $(document).ready(function () {
        $(".submit").on("click", function (event) {
            console.log("Prueba 1");
            event.preventDefault();
            var url = '@Url.Action("Update", "EmployeeWorkLogger")';
            var row = $(this).parents("tr").first();
            var data = {
                Id: row.find(".modelDoc-id").val(),
                nombre: row.find(".modelDoc-nombre").val(),
                apellidos: row.find(".modelDoc-apellidos").val(),
                edad: row.find(".modelDoc-edad").val(),
                activo: row.find(".modelDoc-activo").val(),
            }
            window.location.href = url + '?' + jQuery.param(data);
        });
    });
</script>

Primero, serialize no me lo permite hacer con data, pero he encontrado lo de jQuery.param (lo ideal sería enviarlo como JSON por el body, pero ya me tiré una hora intentándolo en su momento). Eso resuelto.
Segundo, pues he podido enviar los datos y he conseguido actualizarlo todo... salvo el checkbox. Según he leido, no se puede serializar un checkbox no seleccionado porque, simplemente, no existe checkbox.
https://stackoverflow.com/questions/...ter-checkboxes

Pero eso lo tengo que dejar para mañana.

[Drumpi]

Me está costando encontrar una solución a esto. En la página que puse ayer, actúan directamente sobre la URI que se genera, pero tal como genero yo la serialización, provocaría un valor doble en la misma.
Estoy buscando alternativas.

Por otro lado, es curioso cómo el html tag que uso para el checkbox, genera el siguiente código HTML en el inspector:

<td style="vertical-align: middle; text-align: center">
       <input type="checkbox" class="form-control modelDoc-active" checked="checked" data-val="true" data-val-required="Please, set if employee is active" id="DocumentsList_0__active" name="DocumentsList[0].active" value="true"><input name="DocumentsList[0].active" type="hidden" value="false">
</td>

Hay un comentario que habla sobre esto, de generar un campo escondido, para leerlo si el checkbox se desactiva.
Lo que no veo es que se modifique el HTML cuando desactivo el checkbox, cosa que sí he visto con otros elementos.

[TRaFuGa]

Me pasó algo parecido una vez, que se añadian los campos de la tabla a los parámetros de la URL, tuve que usar URLSearchParams para ir añadiendo los parámetros que necesitaba (dinámicamente) para luego pasárselos a la api...
Ojo, uso React y axios para las llamadas...

https://developer.mozilla.org/en-US/...RLSearchParams

[juanvvc]

Entiendo que puedes hacer tu el if. Estoy con el móvil así que pseudocódigo

Data = {
...
valor: (row.find(".checkbox") && row.find(".checkbox").val())
}

Es decir, mira que el checkbox existe y que su valor es true

[Drumpi]

No lo pillo.
Al final, lo he resuelto escribiendo lo siguiente después de la declaración de data:

if (row.find('input[type="checkbox"]').is(':checked')) {
                data.active = true;
            }
            else {
                data.active = false;
            }

No sabía si había forma de poner "unchecked" o qué (aún estoy leyendo la doc de JS de w3schools), así que tiré de lo seguro... and it works! :P

Ahora tengo que rizar el rizo: para mañana debo conseguir que
- Un input de un artículo, al perder el foco, abra una ventana modal.
- En esa ventana modal debo mostrar una lista de lotes, que debo obtener del servidor.
- Cuando se le de al botón guardar del modal, debo almacenar "en algún sitio" los valores (a ser posible, >0). Y cerrar el modal.
- Al final de la página, hay un botón de guardar: debo enviar al servidor los datos de la página (datos de tres tablas, con campos editables, incluida la de artículos), e integrar los datos de los lotes en las correspondientes líneas de los artículos.
Y todo partiendo de la premisa de que, anteayer, de JS sabía cero.

Hace ya tiempo que no hago una GameJam, estoy desentrenado :P

[josepzin]

Para leer el estado de un check creo que está bien como lo hiciste!

Vaya movida tienes allí... no queda otra que ir cogiendo punto por punto e ir resolviendo y avanzando.

[Drumpi]

No quiero llenar el foro de dudas mías sobre JS y JQuery, asíq ue voy a seguir en este hilo.

A ver, resulta que tengo una tabla, con una serie de artículos. Antes, metiendo la tabla en un formulario y haciendo submit con un botón podía enviar la información de la misma al servidor.
Pero ahora resulta que, a algunos elementos de la tabla, les tengo que incrustar una lista, la de lotes seleccionados, por lo que según he entendido, tengo que crear un objeto JS que contenga la información de la tabla, al que le pueda incrustar dichas listas. Así que, mi primer paso es tener una función que inicialice ese objeto.

De momento he escrito esto (resumido y modificado, por si licencias de uso)

const toSendData = {};

function ReadLinesData() {
    console.log("Read Lines Data");
    var rows = $("#miTabla").children("tbody").children("tr");
    var element;
    for (var i = 0; i < rows.length; i++) {
        element = {
            Id: rows[i].find("tableField='Id'"),
            whsCode: rows[i].find("tableField='whsCode'"),
            uomEntry: rows[i].find("tableField='uomEntry'"),
        };
        toSendData.HeaderData.push(element);
    };

Lo que intento hacer es guardar en rows la lista de las líneas de la tabla, y luego, por cada línea, coger los datos de algunas celdas.
Lo de HeaderData es que en realidad son tres tablas, pero vamos a por la primera, de momento.
El caso es que este código me dice que "find" no es una función cuando hago

Id: rows[i].find("tableField='Id'")

Seguro que es error de novato, pero ¿no se supone que rows[i] es una fila? ¿Me falta indicar de alguna forma que estoy usando jQuery ahí?

-----Actualizado-----

PD: los campos los he definido más o menos así:

<td style="display:none"><input readonly="readonly" asp-for="@Model.HeaderData.Id" table-field="Id"> </td>

Es decir, a todos le he creado un atributo, o como se llame, "table-field" y le he dado como valor el nombre del campo. Lo digo porque el find me acaba de dar error, y me he acordado que no lo he dicho ^^U My bad.

[josepzin]

Intuyo que .find es para buscar en el DOM, quizás ese sea el problema.

Si fuera JSvainilla yo haría algo asi:

var elements = document.querySelectorAll("#miTabla tbody tr");
for (var i = 0; i < elements.length; i++) 
{
  console.log( elements[i].querySelector("tableField='Id'").value );
  console.log( elements[i].querySelector("tableField='whsCode'").value );
  console.log( elements[i].querySelector("tableField='uomEntry'").value );
}

Pero bueno, un código asi yo nencesitaría meterlo al navegador y darle 20 veces al debuger hasta que me funcione bien asi que suerte con mi sugerencia :V

Que por cierto, hacer una busqueda usando querySelector es tremendamente mas rapido que usando JQuery, aunque no se note.

[Drumpi]

Puede ser. Mi idea era guardar la lista de rows y hacer la búsqueda desde ahí, pero parece que no sé cómo almacenarlos o cómo leer desde esa variable.
De momento lo he resuelto así:

const toSendData = {
    HeaderData: [],
    ItemLines: [],
};

function ReadLinesData() {
    console.log("Read Lines Data");
    var element;

    $("#miTabla").children("tbody").children("tr").each(function () {
        element = {
            Id: $(this).find("[table-field='Id']").val(),
            whsCode: $(this).find("[table-field='whsCode']").val(),
            uomEntry: $(this).find("[table-field='uomEntry']").val(),
        };
        toSendData.ItemLines.push(element);
    });

Aún así, me gustaría saber qué estoy haciendo mal para no poder usar "for" en la variable rows que tenía declarada en mi anterior mensaje. En teoría "find" es una función de jQuery, y en otra parte del código funcionaba (el otro código JS que puse en este hilo).
Ahora estoy aprendiendo a usar $.ajax para mandar la información al servidor, y cuando lo consiga, tengo que crear una función que coja los campos editables de las tablas, y modifique los datos del toSendData antes de enviarlos. Sigo leyendo JS, pero creo que voy a echar de menos Linq para buscar los campos ¿verdad?

No sé qué es JSVainilla, ni como funciona queryselectorall... me estoy metiendo un atracón entre JS, jQuery y AJAX que bastante raro es que no esté mezclando cosas ya (de código y no de código :P). De momento, necesito ir a lo más básico y sencillo, cuanta menos información necesite, mejor, porque si la curva de aprendizaje es larga, la tengo que condensar para entregar algo mañana.

[juanvvc]

Creo que con "JS vanilla", josepzin se refiere a JavaScript a secas sin ninguna librería adicional. Por eso te lo recomienda, para que no tengas que aprender nada más que JS.

JQuery surgió en su día para ofrecer cosas que JS no tenía en el estándar y se hacían de forma diferente en cada navegador, pero desde hace años JS se ha estandarizado mucho y por eso JQuery se ha quedado un poco obsoleto. Por ejemplo ese ajax() que dices, ya se puede hacer directamente en JS con la función estándar fetch() sin más. queryselectorall() funciona igual que el find() de JQuery, es la nueva función estándar para hacer lo que antes se hacía con find() ó children()

No sé por qué el find() del final no te funcionaba, pero no estabas haciendo find() sobre un elemento único sinó sobre el resultado de ejecutar $().children().children(), y a saber qué es lo que tenías ahí después de tres búsquedas encadenadas y totalmente innecesarias. Hace muchísimo que no uso JQuery!

$("#miTabla").children("tbody").children("tr") seguramente es equivalente a $("#miTabla tbody tr") con menos problemas porque no encadenas nada. Y eso a la vez es seguramente igual que document.queryselectorall("#miTabla tbody tr"), sin necesidad de jquery.

[josepzin]

Creo que con "JS vanilla", josepzin se refiere a JavaScript a secas sin ninguna librería adicional. Por eso te lo recomienda, para que no tengas que aprender nada más que JS.

Exacto! no se porque se le dice vanilla/vainilla al javascript puro, sin librerías, ¿quizás porque es uno de esos sabores básicos?? ni idea... de esas cosas que uno usa sin saber el porqué.

JQuery surgió en su día para ofrecer cosas que JS no tenía en el estándar y se hacían de forma diferente en cada navegador, pero desde hace años JS se ha estandarizado mucho y por eso JQuery se ha quedado un poco obsoleto.

Antaño usar JQuery facilitaba la vida de forma HENORME!! recuerdo haber intentando hacerme el valiente con Javascript en esa época y mi conclusión fue determinante: MEJOR USAR JQUERY.

Pero claro, los tiempos cambian y ahora con javascript basico (sabor vainilla) se pueden hacer facilmente esas cosas en las que era imprescindible JQuery, ademas sin cargar una librería extra y ademas mucho mas rapido.

Para mi fue como haberme quitado de encima el código de Google Analytics una mierd$ menos para cargar.

$("#miTabla").children("tbody").children("tr") seguramente es equivalente a $("#miTabla tbody tr") con menos problemas porque no encadenas nada. Y eso a la vez es seguramente igual que document.queryselectorall("#miTabla tbody tr"), sin necesidad de jquery.

Eso mismo, en vez de estar encadenando instrucciones se puede seleccionar encadenando los selectores dentro de un mismo query, lo que no puedes hacer es mezclar los resultados obtenidos con un query de JQuery con los del JSvanilla, porque no van a funcionar, o uno o el otro.

A mi me ayuda muchísimo separar las cosas en distintas lineas, usando variables para ir almacenando los resultados y metiendo consoles.log a cada valor asi hago un seguimiento de los valores que tengo en cada instrucción y detectar donde está el problema. Luego si hace falta optimizarlo en una sola linea.

-----Actualizado-----

Aquí este chaval sabihondo te lo explica, mi razonamiento parece que era correcto:

[swapd0]

Tambien a la version original de un software se le llama version vanilla, despues esta la version chocolate que es la que cambia el codigo especifico para la plataforma original por una version igual pero en C (normalmente) para que el codigo sea portable a otras plataformas.

[Drumpi]

Creo que con "JS vanilla", josepzin se refiere a JavaScript a secas sin ninguna librería adicional. Por eso te lo recomienda, para que no tengas que aprender nada más que JS.

JQuery surgió en su día para ofrecer cosas que JS no tenía en el estándar y se hacían de forma diferente en cada navegador, pero desde hace años JS se ha estandarizado mucho y por eso JQuery se ha quedado un poco obsoleto. Por ejemplo ese ajax() que dices, ya se puede hacer directamente en JS con la función estándar fetch() sin más. queryselectorall() funciona igual que el find() de JQuery, es la nueva función estándar para hacer lo que antes se hacía con find() ó children()

No sé por qué el find() del final no te funcionaba, pero no estabas haciendo find() sobre un elemento único sinó sobre el resultado de ejecutar $().children().children(), y a saber qué es lo que tenías ahí después de tres búsquedas encadenadas y totalmente innecesarias. Hace muchísimo que no uso JQuery!

$("#miTabla").children("tbody").children("tr") seguramente es equivalente a $("#miTabla tbody tr") con menos problemas porque no encadenas nada. Y eso a la vez es seguramente igual que document.queryselectorall("#miTabla tbody tr"), sin necesidad de jquery.

Sí, bueno, ya sabes que la etiqueta table debe contener un theader y un tbody, y dentro de este último, es donde se meten las líneas (tr), que es lo que estaba buscando.
¿Por qué poner children().children()? No sé, es lo que he leído para obtener todas las rows. Si con "#miTabla tbody tr" obtengo lo mismo y es mejor, pues lo probaré.
Como digo, he empezado hace una semana y aún me estoy adaptando, no he tenido tiempo de hacer pruebas ni ejercicios.

Puede ser que el problema que me estaba dando era el contenido del find, que al ser un atributo inventado por mi, con un valor, debería haber ido metido en corchetes, pero ya lo he resuelto así, y tengo que pasar a lo siguiente ya. Ayer me estaba dando problemas el jQuery.ajax porque no sabía cómo cargar de nuevo la página, cosa que desde .NET core resolvía con un "redirectToAction". Ahora lo tengo que hacer manualmente desde JS.
Por usar JS, todas las ventajas de .NET core se van a la porra.

Exacto! no se porque se le dice vanilla/vainilla al javascript puro, sin librerías, ¿quizás porque es uno de esos sabores básicos?? ni idea... de esas cosas que uno usa sin saber el porqué.



Antaño usar JQuery facilitaba la vida de forma HENORME!! recuerdo haber intentando hacerme el valiente con Javascript en esa época y mi conclusión fue determinante: MEJOR USAR JQUERY.

Pero claro, los tiempos cambian y ahora con javascript basico (sabor vainilla) se pueden hacer facilmente esas cosas en las que era imprescindible JQuery, ademas sin cargar una librería extra y ademas mucho mas rapido.

Para mi fue como haberme quitado de encima el código de Google Analytics una mierd$ menos para cargar.

Ni idea. Como quien dice, me he metido en programación web ayer mismo, y a trompicones.
A mi me facilitaría mucho la vida no tener que depender de otras librerías, y sólo aprender un lenguaje, pero mi "instructor" me dijo que jQuery unificaba código para todos los navegadores, y no dejo de ver funciones en w3schools que no funcionan en iExplorer. Esto es una aplicación para clientes, por lo que debe ser lo más compatible posible, y deben poder usarlo gente que no sabe lo que es un navegador. Las posibilidades de que aún haya quien no ha instalado ninguno, y siga usando "el navegador por defecto" (que podría ser IE, que aún hay quien tira de Windows Server 2012) existen, y el ingeniero que llevo dentro me dice que, si hay la más mínima posibilidad, hay que tenerla en cuenta.

Eso mismo, en vez de estar encadenando instrucciones se puede seleccionar encadenando los selectores dentro de un mismo query, lo que no puedes hacer es mezclar los resultados obtenidos con un query de JQuery con los del JSvanilla, porque no van a funcionar, o uno o el otro.

A mi me ayuda muchísimo separar las cosas en distintas lineas, usando variables para ir almacenando los resultados y metiendo consoles.log a cada valor asi hago un seguimiento de los valores que tengo en cada instrucción y detectar donde está el problema. Luego si hace falta optimizarlo en una sola linea.

Esa es la cosa, aún confundo JS con jQuery, y no sé cuándo estoy guardando datos de uno u otro. Ayer empecé a entender el debugger, tanto el de chrome como el de VS (que creía que no estaba funcionando), y eso me está aclarando muchas cosas. Sigo sin entender por qué los errores de sintaxis y demás sólo se me informan cuando estoy en ejecución, y no en compilación, y encima, la mitad de las veces, no veo los detalles del mismo (¿que se esperaba ":"? ¿Dónde?).
Por eso, como no conseguía iterar sobre las rows guardadas en una variable, pues iteré directamente sobre la búsqueda, y como funcionaba, pues adelante.

No, yo tampoco estoy orgulloso de eso (va totalmente en contra de mis principios de programación), pero no sé lo que hago, y hay que hacerlo YA. De todas formas, voy arreglando cosillas conforme las voy entendiendo.

Aquí este chaval sabihondo te lo explica, mi razonamiento parece que era correcto:

¿En serio ha hecho un vídeo para explicar que JS Vanilla es JS base? ¿Y encima pide likes, suscripción, campanita, etc, etc, etc? Si lo sé, no hago vídeos de 30 minutos sólo por diversión