Mostrando entradas con la etiqueta JavaScript. Mostrar todas las entradas
Mostrando entradas con la etiqueta JavaScript. Mostrar todas las entradas

martes, 22 de marzo de 2016

Property Bag - Buenas prácticas al desarrollar software

Es de lo más común desarrollar software en el que determinadas piezas tienen que ser configurables. Un ejemplo de estas piezas serían aquellas que conectan a base de datos y requieren cadenas de conexión en los que intervienen el nombre del servidor, puerto, instancia de base de datos, etc.
¿En dónde colocan ustedes esa información necesaria para que su aplicación funcione? Hay varias técnicas y todas ellas intentan mantener el mayor equilibrio posible entre Facilidad para gestionar la información y Seguridad de la información. Algunas de ellas pueden ir desde escribir ésta información directamente en el código (muy mala idea); usar archivos XML como el web.config (no recomendable); hasta colocarla en una base de datos diferente (lo cual trae de nuevo el mismo problema). 

En SharePoint existe el mismo reto cuando desarrollamos soluciones para dicha plataforma pero, con un abanico más amplio de herramientas; por ejemplo, crear una lista con dos columnas (Clave y Valor). Su función es la misma que un diccionario en el que la clave nos permite vincular la información con alguna variable en nuestro código y el valor nos da la información que necesitamos. La solución es sencilla; no necesitamos de cadenas de conexión gracias al API de desarrollo; útil y nos provee de una interfaz de usuario con la que podemos gestionar la información. El problema está en la seguridad y es que las listas son rastreables por el motor de búsqueda o bien, se puede acceder a la información desde: Todo el contenido del sitio.
Ciertamente hay trucos para evitar estos inconvenientes pero, probemos una solución mas "elegante". 

Existe una herramienta conocida como Property Bag que nos permite gestionar información y que no es rastreable por el motor de búsqueda ni está disponible por alguna interfaz de usuario en SharePoint. Su funcionamiento es igual que el de un diccionario y la forma en la que lo trabajamos es la misma que con un Ítem de una lista en SharePoint; lo mejor es que está disponible en las versiones más recientes de SharePoint, incluso en el Online.

En el siguiente ejemplo ocupo el API de desarrollo de SharePoint con JavaScript para almacenar una variable llamada _Propiedad_Conexion en el Property Bag.


function crearInformacion() {
    var context = SP.ClientContext.get_current();
    var web = context.get_web();
    var informacion = "Información necesaria para conexión";

    context.load(web);
    var webProperties = web.get_allProperties();
    var propiedad = webProperties.set_item("_Propiedad_Conexion", informacion);
    web.update();

    context.executeQueryAsync(Function.createDelegate(this, function (sender, args) {
        alert("Información creada/actualizada correctamente");
    }),
        Function.createDelegate(this, this.onQueryFailed)
    );
}

En la siguiente función recuperaremos la misma variable del Property Bag. Recuerden ocupar las secciones try/catch para evitar interrupciones de código en el caso de que no exista la variable en el Property Bag.


function cargarInformacionMapa() {
    var context = SP.ClientContext.get_current();
    var web = context.get_web();
    var webProperties = web.get_allProperties();

    context.load(webProperties);

    context.executeQueryAsync(Function.createDelegate(this, function (sender, args) {
        try {
            var propiedad = webProperties.get_item("_Propiedad_Conexion");
            //TODO: Hacer algo adicional.
        } catch (error) {
            console.log("No existe la variable en el Property Bag");
        }
    }),
        Function.createDelegate(this, this.onQueryFailed)
    );
}


Espero que este post les ayude a construir mejores soluciones y recuerden, felices trazos jejeje.

viernes, 26 de febrero de 2016

RemoteEndpoint SharePoint POST

¿No les ha pasado que justo la información que ustedes necesitan para desarrollar un método está incompleta?
Seguramente sí y creo que es una práctica común en el medio de la Tecnología de la Información.
Hace un par de semanas comencé un pequeño desarrollo sobre SharePoint Online en el que necesitaba enviar información capturada en un Add-In de SharePoint hacia un servicio web alojado en otro servidor. Para ello se necesita hacer uso de una herramienta conocida como RemoteEndPoint que proporciona SharePoint para estos casos pero ¿Cómo funciona?
Sencillo (o por lo menos eso es lo que te hace ver la documentación jejeje). Lo primero es seguir la documentación oficial. Ahí nos indican cómo funciona por medio de un diagrama.
Funcionamiento del Remote Endpoint en SharePoint
La idea es simple, nuestro navegador interpretará los archivos JavaScript del Add-In, cuando quiera hacer uso de recursos externos como los de un Web Service ocupará a SharePoint como el intermediario, es decir: le indicará a dónde conectarse, el método, los datos y la respuesta que espera recibir de él entre otras cosas. 
SharePoint tomará la información e intentará realizar la petición; si ésta se lleva a cabo correctamente, el recurso externo enviará la respuesta a SharePoint y éste la enviará al Add-In.
En la documentación ustedes encontrarán cómo crear el proyecto en Visual Studio, cómo formar la solicitud para consultar datos de un Web Service desde JavaScript y finalmente, les indica que registren el RemoteEndPoint en el AppManifest.xml pero, ¿qué ocurre en el caso en el que quieres enviar información al Web Service? Bueno, lamentablemente esa información no está disponible ahí... así que, en este caso nos toca a nosotros encontrar el cómo sí hacer la llamada.
El siguiente ejemplo es muy sencillo pero ejemplifica cómo realizar la actividad.
Pensemos en un pequeño formulario dentro del Add-In que ayude a los desarrolladores a obtener Feedback de sus aplicaciones y, necesitan que la información esté almacenada fuera de Office 365. Para ello se desarrolló un Web Service en Azure que reciba las llamadas y envíe la información a base de datos.
La siguiente función muestra todas las consideraciones para realizar la llamada desde JavaScript y enviar la información:
Los puntos interesantes se encuentran en las líneas 45 y 53 a 58.
En la línea 45 definimos los datos que queremos enviar al Web Service, los cuales son transformados a una cadena de texto correctamente-formada para el envío. Si esto no sucede la llamada al servicio web fallará...
En la línea 53 se define el método en POST que es el ocupado para enviar información (aunque también funciona bien para obtener datos).
En la línea 54 se define el tipo de contenido, esta línea varía ligeramente de la documentación oficial.
Finalmente la línea 58 define el cuerpo de la solicitud, es decir, los datos que serán enviados.
El resto de las líneas son similares al ejemplo en el sitio de Microsoft.

Espero que este pequeño post les haya servido, prueben y comenten porque su retro es muy importante.

Saludos y felices trazos jejeje.

lunes, 14 de diciembre de 2015

Formularios de listas personalizados

En un post anterior escribimos sobre la estructura de datos. En él mostramos cómo definir listas usando archivos XML que están empaquetados en nuestras soluciones para SharePoint sin embargo, los formularios con los que se implementa la solución son los estandar y cuentan con las validaciones básicas como la de campos requeridos.
Para poderle dar un poco más de vida a los formularios que ofrece SharePoint nosotros podemos personalizarlos tanto como queramos (claramente el esfuerzo dependerá de cuánta personalización desees). En este ejemplo les mostraré cómo definir un formulario personalizado al que se le agrega una referencia javascript/jQuery.

Agregando el formulario

El primer paso es expandir la serie de archivos en el que se define la lista en nuestro proyecto de Visual Studio y agregar un ítem al mismo nivel que el archivo Schema.xml.
En el cuadro de diálogo seleccione la opción Page que nos permite agregar un aspx a nuestra App. Tome nota del nombre que le di al archivo (DisplaySolicitud.aspx). Ésto es sólo una convención ya que se pueden agregar tres páginas diferentes por lista: una para Insertar un ítem, otra para Editar el ítem y la última para Visualizar el ítem. El procedimiento para cualquiera de éstos formularios es exactamente el mismo.
Al presionar el botón Add se creará el archivo. Es de notar que sólo se crea el aspx, esto debido a que en mi caso, es un proyecto para SharePoint Online pero, para aquellos que realizan soluciones para On premise, la página se creará con los archivos cs.
Un punto importante es cambiar la propiedad Deployment Type de los archivos aspx a ElementFile. En el caso de omitir este punto, ocurrirá un error al intentar implementar la solución.
El siguiente paso es modificar el archivo aspx agregando las referencias a los archivos CSS y JavaScript a utilizar. Todas las referencias las coloqué en el bloque Content que hace referencia al ContentPlaceHolderId="PlaceHolderAdditionalPageHead". Ten especial atención con la ruta relativa de los archivos que llamarás debido a que no concuerda con la estructura de carpetas del proyecto, en su lugar, concuerda con la ruta de implementación de los archivos en SharePoint.
En el bloque Content que hace referencia al ContentPlaceHolderId="PlaceHolderMain" es necesario agregar el WebPartZone con ID="Main". En ésta zona se crearán los controles que requiere la lista para capturar o mostrar los valores de cada uno de sus campos.
El archivo DisplaySolicitud.js contiene una función sencilla que envía un mensaje cuando se carga la página, por ello no entraré en detalle de ese archivo.
El último paso de configuración se da en el archivo Schema.xml de la lista que estamos trabajando. Es necesario expandir la sección Forms y editar la opción del formulario que nos interesa. Para el caso de éste ejercicio edité el nodo marcado con Type="DisplayForm"

  • Lo primer es cambiar la Url del formulario, para ello sólo coloco el nombre del archivo aspx que agregué (DisplaySolicitud.aspx). 
  • El siguiente paso es cambiar SetupPath por Path y colocar el nuevamente el nombre del formulario. 
  • Finalmente, agregué el atributo UseLegacyForm="FALSE".

Ya con todos los puntos cubiertos podemos pasar a probar el formulario utilizando F5 para implementar la solución. Una vez cargada la solución, me dirigí a la lista y agregué un ítem que posteriormente abrí para que SharePoint mostrara el formulario DisplaySolicitud.aspx que fue el que agregamos en este ejemplo.

Conclusión y siguientes pasos

Este ejemplo aunque sencillo, demuestra una forma de editar los formularios de SharePoint de tal manera que se pueden empaquetar y son implementados sin un esfuerzo adicional de configuración. El mayor provecho se obtiene al usar el API de SharePoint basada en JavaScript del cual platicaremos más adelante; pero no sólo eso, el manejo de los estándares web HTML, CSS y Javascript ayudará a darle una mayor funcionalidad con menor esfuerzo dado a que varias de las validaciones las puede controlar SharePoint y el resto se pueden hacer mediante Javascript.
Nuevamente recuerden que todos sus comentarios son bienvenidos. Saludos y la mejor de las suertes en sus proyectos.