none
Crear un formulario "embebido" RRS feed

  • Pregunta

  • Hola chicos, despues de comerme la cabeza sobre como realizar una funcionalidad para una aplicación web en ASP.NET MVC2 y de no tener a ningún compañero en el trabajo para que me ayude, he decidido contar con vosotros que me resolvisteis los problemas a la primera de cambio de una manera muy cordial y efectiva.

    Bien, os pongo en precedentes: Tengo una aplicación web que es un producto propio que se despliega en diversos servidores (y/o se "alquila" una instancia de dicha aplicación en nuestros propios servidores). Uno de los clientes quiere que se pueda utilizar un formulario desde su propia página que le envíe los datos a la nuestra para concretos usuarios externos que no deberían de tener acceso o conocimiento del producto usado internamente.

    Para ello, la primera idea que me ha venido a la cabeza es crear un formulario embebido, por ejemplo mediante un servicio web. Elos en su página consumen al servicio web y yo les devuelvo la cadena del formulario para que la "incrusten" en su propia página. Hasta aquí todo iría perfecto como la seda y no habría problema alguno. El problema recae en que dicho formulario debería de poder realizar más de un postback. Si yo envío mediante un servicio web la cadena para "pintar" el formulario en cuestión, teniendo en cuenta que el servicio tiene que ser interoperable, yo no puedo persistir los datos entre "recargas" pues cada vez que se pinte, se pintará vacío. Tampoco puedo poner ningún código de control en la cadena del formulario preparándolo para persistir los datos entre recargas por el mismo motivo de antes, tiene que ser interoperable.

    Así pues, se me ocurrieron (o mejor dicho, tengo que pensar) algunas alternativas para realizar esta operación.

    La primera y más obvia (pero que quiero evitar si es posible) es usar un iframe, con un iframe todos mis problemas se despejarían, quedándome sólo uno, el de haber usado un iframe.

    La otra opción es realizar todos los postsbacks menos el del submit (o también, que más da) mediante AJAX, pero según tengo entendido el ajax crossdomain da muchos problemas, y al parecer no se lleva bien con MVC, aunque no he leído argumentos sólidos de por que no.

    La otra opción es persistir los datos de algún modo, ya sea mediante algún archivo temporal o una tabla temporal en la que se indique una key mediante la instancia, el dominio y el timestamp del formulario para revisarlo a la hora de pintar el formulario. (lo cual me parece una chapuza de aupa)

    En principio, para que sea interoperable y evitarme el iframe no se me ocurre nada más, bueno, si fuese "interoperable" pero poco a poco, siempre se podría crear una dll para embeber el formulario mediante ASP.NET, crear un servicio específico apra JSP, otro para PHP y bueno, una vez hecho con todos, pues el dato a la hora de pintar se podría evaluar en la propia cadena que devuelve el servicio, y así "rellenar" el value correcto por cada postback, pero me parece otra chapuza de espanto.

    Por tanto y después de calentaros la cabeza, agradecería alguna idea al respecto, a ver si me iluminais sobre como podría hacer esto.

    lunes, 13 de febrero de 2012 16:07

Todas las respuestas

  • @frikinside

    No termino de entender tu problema... Quieres mostrar un formulario de TU aplicación en una aplicación web de OTRA empresa?

    Yo, o te recomiendo un iframe o te recomiendo un conjunto de servicios web de tu aplicación llamados desde código adhoc de la otra aplicación. Efectivamente Ajax en crossdomain da ciertos problemas (especialmente en POST), pero se pueden solventar con el uso de jsonp (http://en.wikipedia.org/wiki/JSONP).

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    miércoles, 15 de febrero de 2012 7:20
  • Si es que en ocasiones me lio a escribir como un ceporro para intentar explicarlo todo con pelos y señales, y al final acabo liándola más.

    Como bien dices lo que quiero es poder mostrar un formulario de MI aplicación en una aplicación/página web de OTROS empresas/usuarios/irrelevante.

    O traduciéndolo un poco más, lo que quiero es que la aplicación provea de un servicio que permita mostrar un formulario de MI aplicación en otra página a la que yo no tengo acceso ni control ni nada por el estilo.

    Así a bote pronto y sin más detalles, el problema no existe, es decir, es una memez crear un SW (o ni eso, una página de la aplicación podría darte el código para que lo pongas en tu página incluso) que como valor de retorno tenga la cadena con el formulario "pintado". El problema reside en que el formulario no es de un único POST, se realizan un mínimo de 2 POST y un máximo de "infinito". Si sólo fuese un POST el problema no existiría. Al ser necesario realizar varios POST para "actualizar" la información y el formulario en sí, cuando la página se recargue, el servicio pintará de nuevo el formulario, pero claro, lo pintará vacío otra vez.

    El iframe solucionaría todos esos problemas, pero no quiero utilizar el iframe, o mejor dicho, preferiría evitar caer en las malas prácticas del iframe.

    La otra opción que me parecía viable era AJAX pero había leído que había problemas con crossdomain... pero dices que con JSONP se solucionan los problemas de crossdomain? Vaya eso ya me llama más la atención. Lo revisaré por ahí, muchas gracias.

    P.D. El objetivo o motivo de mi duda, era buscar una forma de o evitar recargar la página con los posts (AJAX) o persistir de alguna manera los datos en cada recarga.

    miércoles, 15 de febrero de 2012 8:03
  • Bueno... te voy a decir antes que nada que esto es una necesidad... curiosa :)

    Si yo tuviese que realizar esto, lo que haría es:

    1. Como tu ya dices un servicio (o algo) que devuelve el HTML a incrustar dentro de la página "principal externa". Vamos, devolver una PartialView en ASP.NET MVC. Este HTML debería ser incluído en el cliente (con algo parecido a jQuery.load).
    2. De alguna manera debería pasársele a tu código cual es el contenedor (<div>) en el que se carga. P.ej. por querystirng cuando se llama a jQuery.load. Tu código debe guardarse este ID, porque este div es el que va a ir "reemplazando".
    3. Ahora viene el tema: no hay postbacks. No puedes gestionar tu un postback que pertenece a otro. Lo que te propongo en este caso es, que las actualizaciones de tu formulario se gestionen via AJAX. Es decir, tu formulario junto con el HTML renderiza también el javascript necesario para que cuando alguien pulse un botón de tu formulario embebiddo se genere una petición AJAX hacia tu controlador que a la vez reemplazará el código del <div> (por lo tanto a él mismo) con el nuevo código. Esto requiere que todo el paso de "información" se realice de forma manual, pero no es especialmente costoso.

    No es trivial, pero creo que puede conseguirse sin muchos problemas... De todos modos me has dado una idea para realizar un post de esto al respecto... :)

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    jueves, 16 de febrero de 2012 7:59
  •  Bueno.. vamos por partes...

    Curiosa la necesidad? Al parecer es bastante habitual que diversas empresas quieran utilizar una aplicación pero sin que el usuario "final" vea nada de esa aplicación, un modo de "ocultarla" al usuario final, me explico.

    Empresa A desarrolla una aplicación "Patatas". Empresa B quiere comprar la aplicación "Patatas". Empresa B tiene unos clientes que van a poder utilizar (además de los propios empleados de la Empresa B) parte (en este caso un formulario de un create y nada más) de la aplicación. Pero la Empresa B no quiere que se vea nada de "Patatas" para el usuario final, quiero que sólo se vea "B" por todas partes!

    Me parecía que era una práctica bastante común, pero sin tan extraña te parece me están tocando todas a mi o que? xD Soy un acaparador!

    Bien, sobre lo de que "No puedes gestionar tu un postback que pertenece a otro".... o yo te lo he entendido mal o no estoy de acuerdo. Es decir, en http://www.patatastraigo.com pueden tener un formulario con un action a un dominio llamado "http://www.fresasconnata.org" perfectamente, y en fresasconnata.org pueden coger ese formcollection (o lo que fuera) y jugar con el, e incluso devolver "una respuesta" (una respuesta por llamarla de una manera, vamos un redirect como una casa).

    No obstante, cada vez veo más claro que el hecho de necesitar varios postsbacks me va a hacer falta AJAX crossdomain. A la hora de pintarlo yo no tengo ningún problema (de pintarlo vacío eh?) Lo puedes coger desde cualquier sitio, sólo hay que encasquetar un string dentro de un html, que el navegador ya se encarga de interpretarlo como se merece, con un simple servicio web y si me apuras con un return de un action esa cadena se puede "pegar" en el html sin problemas, el problema como bien resaltas viene cuando tienes que recargar y "persistir" los datos del formulario antes de la recarga.

    Pero bueno, esto que estyo diciendo ya es marear a la perdiz sin objetivo ninguno. Ajax parece una excelente solución, y encima me evito un iframe que era mi alternativa "chapu", así que perfecto! ^^''

    Una vez más... chapó Eduard!


    • Editado frikinside lunes, 20 de febrero de 2012 12:05 Patadas a la RAE
    jueves, 16 de febrero de 2012 11:06