Social Icons

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

jueves, 9 de julio de 2015

¿Es JavaScript El Traje Nuevo del Emperador?

Como en el cuento del traje nuevo del emperador... alguien tiene que decirlo...


Script (computing), un programa pequeño y no compilado escrito para un intérprete de comandos o un lenguaje de scripting.

Si JavaScript tiene Script en el nombre, ya te esta dando pistas de que no es el lenguaje de programación adecuado para basar toda la web y la mitad del software de moviles.

Si JavaScript: The good parts es un superventas y solo tiene 150 páginas (y 50 son apendices y solo hay dos de características bonitas del lenguaje y estoy seguro de que hasta el mismísimo Señor Crockford sudó tinta para escribir tantas)

Si te piden que vayas migrando de versión a versión de vez en cuando porque tu proveedor de software va a dejar de soportar tu aplicación en los próximos cinco años, ¿Qué te hace pensar que es una buena idea descargarte e instalar en el corazón de tu software un archivo js minimizado que no puedes leer y que quién sabe de donde viene y cuyo desarrollador se olvidó de el cinco días después de publicarlo?

¿Trabajaré con el?

Claro que sí. De hecho llevo años trabajando con javascript (lustros), pero no a este nivel. Si puedes hacer cualquier cosa con una máquina de Turing ¿Por qué no adoptar un lenguaje de scripting para hacer aplicaciones de miles de líneas? Los valientes llamarían a eso un desafío.

He estado creando clases y constructores y herencia y todo eso se puede hacer en JS pero traducir las vetustas estructuras y patrines OO al modernísimo JS no parece el camino correcto y, seguramente ahí está mi problema. En lugar de abrazar el nuevo lenguaje estoy intentando traducir mis viejos chistes. Y esto cambiará cuando aprenda los chistes nuevos.

El hecho de que no tengamos otra opción también tiene su peso en la decisión. Si trabajas para la web eres libre de elegir entre programar con JavasScript o no trabajar para la web à la Apple.

Entiendo sus ventajas?

La curva de aprendizaje es estupenda, ya que las bases son más simples. No hay tipos ni red de seguridad. No hace falta un IDE ni tampoco hay grandes IDEs, si vienes de Visual Studio te va a encantar perder todas esas funciones a las que estás acostumbrado. Se puede ejecutar en cualquier sitio siempre que tengan el navegador adecuado y no es el caso en muchas empresas grandes. Y una gran comunidad de fans à la Apple.

¿Me gusta JavaScript?

¿Me gusta una tecnología que, si tenemos suerte, solventará dentro de cinco años todos los problemas que resolvimos hace ocho años con Silverlight?

Probablemente cuando tanto la tecnología como yo hayamos madurado.

Por supuesto que me gusta, yo quiero ser guay...


También aprendí a amar WPF pero no me costó tanto tiempo.

No hay comentarios:

jueves, 5 de abril de 2012

Esconder Editar en hoja de datos en el menu Acciones con código javascript

¿Volver después de todo este tiempo para escribir un post tan feo? Ese es exactamente mi estilo…
El título del post explica bastante bien cual era el objetivo a cumplir y todo el mundo sabe que esta no es la mejor forma, pero editar los permisos estaba dándonos problemas en otro lado así que decidimos hacerlo asi.
Este es el enemigo:
Editar en hoja de datos
Y para ocultarlo agregamos un Web Part Editor de Contenido e hicimos click en el botón Editar código fuente:
Content Editor Web Part Source Editor
Allí añadimos el script:
<script type="text/javascript" >
var allMenuItems = document.getElementsByTagName('ie:menuitem'); 
for(var i = 0; i < allMenuItems.length; i++ )   
{
 try
        {
         if (allMenuItems[i].text.toLowerCase() == "editar en hoja de datos")
         {
   var parentNodeOfMenuItem = allMenuItems[i].parentNode;  
                 parentNodeOfMenuItem.removeChild(allMenuItems[i]);                                
  }
 }
 catch(err)
 {}

} 
</script>

Puede parecer un poco desordenado, pero a SharePoint no le importará. Después hacemo click en guardar.
CEWP Source Editor Window
Después de eso podemos poner el web part oculto para que los usuarios no puedan verlo.
Y eso es todo.
Edit in Datasheet Hidden
Enjoy!

No hay comentarios:

jueves, 8 de septiembre de 2011

Web Part Proveedor de Filtro con un árbol Silverlight en un ModalDialog

Empecé con esto hace un par de días... No quería hacerlo, porque sabría que iba a ser doloroso... pero me obligaron... Y entonces pensé que sería un post perfecto para el blog por lo de painful.

Lo que queríamos conseguir era filtrar elementos en un List View Web Part por Entidad. En nuestra solución tenemos una jerarquía de entidades por lo que pensamos que sería buena idea que el web part mostrase la jerarquía como un árbol.
Bien, así que necesitamos un web part con un TreeView que sea capaz de mandar la entidad seleccionada como filtro a un LVWP. Fantástico. Lo hice... Y no le gustó a nadie. Lo querían en Silverlight y no solo eso, lo querían en una ventana pop up. Sip, me cogieron, nunca había hecho nada parecido pero, ¿Quién dijo miedo?

Es un montón de código, la mayor parte feo así que solo postearé la parte interesante (básicamente la parte relacionada con la comunicación entre las páginas y el Silverlight) y las URLs de donde cogí las ideas.
Lo primero es poner a funcionar un Filter Provider Web Part. Para ello seguí las instrucciones de aquí. Primero lo intenté con un IWebPartRow, pero no era lo que yo quería así que cambié a ITransformableFilterValues. Esta parte es bastante simple así que no comentaré nada más.
La segunda parte es crear una ventana emergente. Después de googlear si googlear te parece un palabro raro deberías escucharme decir overridar o rollupear un rato me enconté con este post, que me pareció un buen sitio para empezar. Mi código en el web part terminó así:

        protected override void OnLoad(EventArgs e)
        {
            if (Page.IsPostBack)
            {
                if (!string.IsNullOrEmpty(GetFormValue("HiddenEntityName")))
                {
                    Page.Session["SelectedEntityName"] = Page.Request.Form["HiddenEntityName"];
                    Page.Session["SelectedEntityID"] = Page.Request.Form["HiddenEntityID"];

                    RenderHeader();

                    //SelectedEntityText.Text = string.Format("{0}  ", Page.Request.Form["HiddenEntityName"], Page.Request.Form["HiddenEntityID"]);
                }
                else
                    RenderHeader();
            }

            string CurrentWeb = SPContext.Current.Web.Url;
            string height = "500";
            string width = "500";
            string page = "/_layouts/stratex/EntityTree.aspx";

            // use next line for direct with  between  and  
            string scrp = @"
                            ";

            Type t = this.GetType();
            if (!Page.ClientScript.IsClientScriptBlockRegistered(t, "bindWebserviceToAutocomplete"))
                Page.ClientScript.RegisterClientScriptBlock(t, "bindWebserviceToAutocomplete", scrp);
        }
Tuve problemas trayéndome los valores del ModalDialog. No era capaz de encontrar los ID ni los Titles de los controles porque son creados dinámicamente. El truco que usé fue crear dos campos ocultos en el CreateChildControls:
        protected override void CreateChildControls()
        {
            base.CreateChildControls();

            ...

            Page.ClientScript.RegisterHiddenField("HiddenEntityName", "");
            Page.ClientScript.RegisterHiddenField("HiddenEntityID", "");

            ...
        }
Oye Chan, ¿Te has dado cuenta que podrías usar solo la sesión y olvidarte de los HiddenFields? No preguntes, te lo advierto…
La próxima parte es crear la página aspx para el modal dialog. La guardé en un directorio que me creé en _layouts. El código de la página quedó así:
<%@ Page Language="C#" Inherits="StratExFramework.EntityTree,StratExFramework,Version=2.2.0.0,Culture=neutral,PublicKeyToken=311246df7412ca98" %>

<html>
<head>
<title>Select Entity for filtering</title>
<script type='text/javascript'>
    function PassParameterAndClose(EntityName, EntityID) {

        window.returnValue = new Array( EntityName, EntityID) ;

        var version = parseFloat(navigator.appVersion.split('MSIE')[1]);
        if (version >= 7) 
            { window.open('', '_parent', ''); }
        else
            { window.opener = self; }

        window.close();
    }
</script>
</head>
<body></body>
</html>
También me creé una clase de code behind como puedes ver en la primera línea del aspx... :
    public class EntityTree : WebPartPage
    {
        string CurrentWeb;
        string SelectedEntityID;

        protected void Page_Load(object sender, System.EventArgs e)
        {
            CurrentWeb = Request.Params["CurrentWeb"];
            SelectedEntityID = Request.Params["SelectedEntityID"];
        }

        protected override void CreateChildControls()
        {
            base.CreateChildControls();

            string Source = CurrentWeb + "/Lists/XAPLibrary/SilverlightEntityTreeSelector.xap";
            string SilverlightHeight = "515";
            string SilverlightWidth = "500";

            LiteralControl obj = new LiteralControl();
            obj.Text = "<object id='silverlightHost' style='height: " + SilverlightHeight + "; width: " + SilverlightWidth + @"; margin: 0; padding: 0;' data='data:application/x-silverlight-2,' type='application/x-silverlight-2'>
                            <param name='Source' value='" + Source + @"' />
                            <param name='MinRuntimeVersion' value='3.0.40624.0' />
                            <param name='Background' value='#FFFFFFFF' />
                            <param name='initParams' value='" +
                                string.Format("{0}={1}", "site", HttpUtility.UrlEncode(CurrentWeb)) +
                                string.Format(", {0}={1}", "selectedentityid", HttpUtility.UrlEncode(SelectedEntityID)) +
                                @"' />
                            </object>";
            this.Controls.Add(obj);
        }

        public override void VerifyRenderingInServerForm(Control control)
        {
            return;
        }
    }
Lo que hago aquí es coger los parámetros del entorno en donde se ejecuta el web part y pasárselos al Silverlight. Uso el CurrentWeb para decirle a los web services del Silverlight cual es el contexto y el SelectedEntityID para resaltar la entidad que fue seleccionada la última vez que se abrió la ventana modal. Este es el código del Silverlight.
namespace SilverlightEntityTreeSelector
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();

            Tree.PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(Tree_PropertyChanged);

            Tree.Show(string.Empty);
        }

        void Tree_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
        {
            if (e.PropertyName == "SelectedEntityID")
                HtmlPage.Window.Invoke("PassParameterAndClose", Tree.SelectedEntityName, Tree.SelectedEntityID);
            else if (e.PropertyName == "TreeLoaded")
                if (Application.Current.Resources.Contains("selectedentityid"))
                    if (!string.IsNullOrEmpty(Application.Current.Resources["selectedentityid"] as string))
                        Tree.ChangeSelectedItemTo(Application.Current.Resources["selectedentityid"] as string);
        }
    }
}

Ya tenemos todos los componentes.
Esto funciona de la siguiente manera: Seleccionas una entidad en el árbol de Silverlight, luego el Silverlight llama a la función javascript de la ventana modal y que pasa los parámetros al web part padre y cierra el popup. Finalmente el web part manda el filtro al List View WebPar.
Si usas este código te faltarán algunos métodos, pero lo que quería compartir aquí es el método que he seguido para conseguirlo básicamente porque no quiero tener que volver a pensarlo si alguna vez me vuelven a pedir que haga algo parecido en el futuro.



Me encantaría enseñaros algunas fotos, pero los web parts no han sido retocados por las hábiles manos de Adam, nuestro diseñador, y se os podrían salir los ojos de las órbitas.

No hay comentarios:

viernes, 5 de agosto de 2011

Ocultando las Scrollbars en los web parts de SharePoint 2010

Después de desplegar la primera versión alpha de nuestra solución en SharePoint 2010 noté que los web parts Silverlight estaban enmarcados en unas antiestéticas barras de scroll. Me di cuenta también que si cambiaba la altura y anchura a automático desaparecían, pero claro, entonces mi web part no tenía la talla que yo quería...

Leí este post: http://blog.benfox.info/?p=11 y, como probablemente hayas adivinado, me tiré de cabeza a la solución fea.

Había un problema, que el código javascript estaba en una foto… mal… y entonces pensé “Voy a demostrarles a todos que puedo ser tan cazurro en SharePoint 2010 como siempre lo he sido en SharePoint 2007” ¿Por qué no crear un post sobre esto?
<script type="text/javascript">

 function HideScrollBars()
 {
 document.getElementById('WebPartWPQ2').style.overflowX = "hidden";
 document.getElementById('WebPartWPQ2').style.overflowY = "hidden";

 document.getElementById('WebPartWPQ3').style.overflowX = "hidden";
 document.getElementById('WebPartWPQ3').style.overflowY = "hidden";
 }

_spBodyOnLoadFunctionNames.push("HideScrollBars")</script>
Y después de pelearme por lo menos 15 minutos con el Content Editor Web Part me las arreglé por fin para esconder las barras de scroll verticales y horizontales en mis web parts.

Ahora puedo mandar orgulloso una foto del sitio con la Vista de SharePoint 2010.

--- Actualización --- he cambiado el codigo de los web parts y ahora no es necesaria la guarreria del javascript.

No hay comentarios: