Pujar fitxers al servidor

Avui m’he estat barallant amb el control d’ASP.NET FileUpload. Aquest control et permet poder seleccionar un fitxer del teu ordinador i pujar-lo al servidor. Un fet que sembla tant senzill a vegades ens pot provocar algun que altre mal de cap. Tot i que ja ha anat evolucionant la tecnologia i la manera que es tracta aquesta petició no s’ha pogut escapar mai de la mecànica que té, és a dir, seleccionar un fitxer, prémer un botó perquè aquest comenci a  pujar al servidor.

Aquest control està limitat funcionalment per motius de seguretat, per exemple, no es pot preseleccionar un fitxer ni tampoc es pot fer que pugi de forma automàtica sense la autorització de l’usuari. Us imagineu que les webs poguessin pre-seleccionar els fitxer? o pitjor encara que pugessin sense autoritzar?

Tot i així a les webs es veu de tot, tot si val per poder dissimular el comportament funcional o l’aspecte d’aquest control. Per exemple, que immediatament després de seleccionar el fitxer comenci a pujar, o canviar el boto horrible de Examinar. Nom del qual no podem modificar nativament ja que depèn del navegador. Mireu aquesta web com parla dels diferents estils que pot tenir aquest control depenent del navegador i tècniques per poder-lo modificar.

Parlem ara dels controls Ajax que permeten pujar els fitxers asíncronament. Durant molt de temps Google utilitzava iframes per pujar els fitxers fent creure a tothom que es feia asincronament. Ara desconec si encara utilitza aquesta tècnica però tampoc importa massa ja, et pots trobar molts controls per internet que diuen pujar els fitxers asíncronament.

Pujar asíncronament un fitxer si és possible tot i que és més insegur que fer-ho sincronament, però es pot fer un progress bar? Doncs si, existeixen maneres per fer-ho, una d’elles és amb plugins jquery com aquest i flash. De moment els navegadors no permeten saber la mida del fitxer amb javascript, per tant com pots fer un progress bar si ja no saps què envies? doncs un cop ha arribat la petició al servidor és quan ja es sap la mida del fitxer, però clar, ja ha arribat, ja el tens allà. Cap navegador et permet tractar els fitxers del teu ordinador perquè aquest pugui ser pujat en trossos. Aquesta afirmació té l’excepció en la utilització d’ActiveX, Flash o Silverlght que al ser aplicacions que s’executen completament en el client si podrien tenir aquest accés sempre i quan nosaltres haguem acceptat els avisos de perills de seguretat que un bon navegador ens informaria.

Continuant amb el FileUpload hi ha també altres maneres de poder canviar el seu aspecte utilitzant el JQuery.

La tècnica bàsica per fer que un cop seleccionat el fitxer aquest comenci a pujar és simplement:

<asp:Button ID="Button2" runat="server" OnClick="Button2_Click" Text="Button" />
<asp:FileUpload ID="FileUpload1" runat="server" />

On Server side


Button2.Attributes.add("Style", "Display:none" );
FileUpload1.Attributes.Add( "onchange", Button2.ClientID + ".Click()") ;

És a dir, ocultar el botó que ens fa el postback al servidor perquè aquest comenci a pujar i simular un click amb javascript.

Formació de Sharepoint Foundation 2010

La setmana que ve començo una formació de Sharepoint Foundation 2010. Aquesta serà a nivell d’usuari i molt específicament de gestor documental.

Encara que sigui molt especific i una petita part del què fa el Sharepoint comporta explicar bastants conceptes, entre ells, llistes, versions, vistes, aprovacions de continguts a part del concepte general del què és el Sharepoint: sites, subsites i pàgines.

Voler un curs especific no és sempre directament proporcional a disminuir els continguts o el temps. A vegades es necessita el mateix temps i els mateixos continguts per portar els teus alumnes a poder entendre allò que ells volen saber, és a dir, l’objectiu per el qual fan el curs.

Int32Animation amb Silverlight

Quan es treballa amb WPF un es troba amb les animacions. Les animacions es basen en assignar valors a propietats que son Dependency Properties en un determinat punt del temps. Les propietats poden ser de qualsevol tipus i per això tenim ColorAnimation, StringAnimation, DoubleAnimation i altres. Cada un d’ells anima propietats d’un tipus determinat.

Amb aplicacions WPF hi ha l’Int32Animations que ens permet animar propietats que son de tipus enter, però amb Silverlight aquest tipus d’animació no existeix i per tant s’ens planteja el problema de com animen les propietats que son de tipus enter.

La solució passa per utilitzar l’ObjectAnimation. Aquest tipus d’animació serveix per assignar un object a una propietat. Per això el que hem de fer és assignar un objecte de tipus Int32.

<UserControl xmlns:sys="clr-namespace=System;assembly=mscorlib">
<ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="IntProp" ... >
<DiscreteObjectKeyFrame ...>
<DiscreteObjectKeyFrame.Value>
<Int32>5</Int32>
</DiscreteObjectKeyFrame.Value>
</DiscreteObjectKeyFrame>
</ObjectAnimationUsingKeyFrames>
</UserControl>

Això és aplicable fins al Silverlight 4, queda per veure si en pròximes versions Int32Animation si existeixi.

Ocultar les capçaleres dels TabItems en Silverlight

Ocultar les capçaleres (pestanyes) del tabcontrol hauria de ser un procediment molt senzill, doncs, aquesta tècnica ens permet poder tenir agrupacions de controls en una mateixa pantalla i que cada agrupació ocupi la pantalla per separat.

Amb WPF per ocultar aquestes pestanyes és suficient en redefinir per ControlTemplate el tipus TabItem, però amb Silverlight és diferent. No serveix de res el fet de que les dues tecnologies utilitzin el mateix llenguatge. En Silverlight hem de fer el que molt bé s’explica en aquest post: How to hide Tabitem headers.

Bàsicament la tècnica és en reescriure el temlate del TabControl però assignant a Collaplse el valor de la propietat Visibility del TabPanelTop.

Binding WPF : ElementName i RelativeSource

Aquest post vull parlar d’un tipus d’enllaç que podem fer a les nostres aplicacions WPF o Silverlight. Enllaç a les propietats de la instància que pertany el control. Aquesta instància pot ser una Window o Page o un UserControl o un CustomControl.

És una pràctica molt habitual per poder accedir a les propietats de la classe a la que pertany el control sense la necessitat de assignar-lo a cap DataContext. Pràctica no molt recomanada amb Silverlight perquè ens obliga a posar un nom a la instància i això pot provocar problemes ja que es pot repetir el nom dins l’arbre de controls, això mateix amb aplicacions WPF no passa o almenys no diu res.

Per aconseguir enllaçar amb aquesta propietat hem d’indicar la font amb l’atribut ElementName.

{Binding Path=Text,ElementName=me}

A l’exemple ens referim a la propietat Text de la instància.

public string Text{get;set;}

on me és el nom que hem donat mitjançant l’atribut x:Name al fitxer XAML.

<window x:Name=me></window>

En quant apliquem estils per un diccionari de recursos i apliquem el Control Template la manera que tenim de referenciar-nos a la instància és per RelativeSource. Al crear un Control Template aquest es pot aplicar en qualsevol lloc on existeixi el tipus que estem especificant per el TargetType i per tant no podem controlar quin és el nom que es donarà a la instància. És per això que tenim el RelativeSource i TemplatedParent.

{Binding Path=Text,RelativeSource={RelatieSource TemplatedParent}}

Aquest només és aplicable en un Control Template.

Si no estem en un Control Template també podem utilitzar el RelativeSource per referir-nos a elements dins l’arbre de controls.

Twitter vas lent

Porto ja temps amb el problema de quant escric alguna cosa al meu compte de Twitter aquest no respon adequadament. El què fa és estar en espera indefinit en el moment que genero un tweet. Et posa dels nervis perquè cada vegada que escrius un tweet has d’actualitzar tota la pàgina i veure si realment ha acabat el procés.

Busco per internet i no veig res, ningú que l’hi passi exactament el mateix, no ho entenc.

twitter.com/jparareda

WPF Custom control Dependency Property

Tots els que estem al món de la programació coneixem de sobres la diferència entre un User control i un Custom Control.

El post d’avui és un exemple de les inquerencies que sovint ens podem trobar programant. El meu cas és voler passar d’un User control a un Custom Control que en WPF no és res més que la possbilitat de poder aïllar la presentació de la lògica de proces, dit d’una altre manera, crear un fitxer amb extensió cs o vb que hereda de Control i per estils aplicar el seu aspecte.

Aquest pas simplement és posar el contingut de l’XAML del User Control en un diccionari de recursos (que també és extensió XAML) i en el code behind tenir en compte el OnApplyTemplate per poder capturar els elements que en voldrem personalitzar una mica més, com per exemple la capturació d’events.

El problema ha sigut que en el moment de provar el nou control totes les propietats que estaven enllaçades no funcionaven, és a dir, els dependency properties amb Databinding no funcionaven.

Buscant per internet em trobo amb un blog on molt ben explicat ens diu com resoldre aquest problema. Realment no dono crèdit de com a vegades poden ser tant inquerents les coses.

Realment si seguim els passos comentats en aquest blog problema resolt.

Programació Asíncrona Event-based vs IAsyncResult Pattern

La programació asíncrona és cada vegada més i més necessària ja que cada vegada més fem aplicacions orientades a web. Les aplicacions d’aquest tipus com son ASP.NET o Silverlght o Wpf Browser han d’utilitzar crides asíncrones per comunicar-se amb el servidor. Per fer-ho el més comú és utilitzar Web Services o WCF. Aquests ja porten els seus mètodes asincrons que ens faciliten molt la feina.

Precisament quan treballem amb asincronismes és quan veiem que amb .Net tenim dos models o dos patrons d’implementació: Un basat en events i l’altre en delegates AsyncCallback. Cada un d’aquests patrons està ben explicat les msdn de Microsoft. Per les diferencies pots determinar quin és el millor patró que pots escollir però i si no et determina res? quin patró hauríem d’utilitzar?

El basat en events necessita molt més codi per implementar vers el de crides IAsyncResult. A més el rendiment he notat que és superior en el de IAsyncResult.

Per tant, posats a escollir un patró jo prefereixo el de IAsyncResult que és més fàcil i ràpid però tenint molt present les recomenacions que ens fa Microsoft.

Wpf App to Silverlight App (IV part) – Applying styles

Continuo amb el tema sobre els problemes que ens podem trobar al passar una aplicació Wpf a Silverlight.

Problema 1 : Routed Events

Problema 2 : Dynamic Resources

Problema 3 : Triggers

Problema 4 : Applying styles

Ja he parlat amb els posts anteriors la capacitat que tenim des de WPF o Silverlight de poder aplicar estils o templates a les nostres pantalles o controls.

Aplicar estils és una cosa molt comuna i utilitzada al moment de programar en WPF ja que sabem que podem canviar totalment l’aspecte d’un control amb una sola linia de codi.

Aquests estils es poden aplicar en temps de compilació (statics) o en temps d’execució (dynamics), de fet ja n’he parlat en altres posts, però també es pot fer per codi des del mètode onApplyTemplate dels nostres controls. La única cosa que hem de fer és assignar a la propietat Style l’objecte de tipus Style que volem. en WPF podem fer això en qualsevol moment sense problemes mentre que en Silverlight una vegada s’ha assignat un estil aquest ja no es pot canviar.

Solució

Doncs no existeix una solució ja que és un problema de l’arquitectura del Silverlight, penseu que s’executa en un navegador del client. La única cosa que ara mateix crec que es pot fer és tenir dos controls un en cada estil i substituir els controls per l’adequat en el moment que es vulgui fer el canvi d’estil.

Wpf App to Silverlight App (III part) – Triggers

Continuo amb el tema sobre els problemes que ens podem trobar al passar una aplicació Wpf a Silverlight.

1er Problema : Routed Events

2on Problema: Dynamic Resources

3er Problema : Triggers

Una de les coses que més m’agraden de WPF és la capacitat que té de poder donar comportament en funció de events externs o de valors de propietats directament per XAML, és a dir, des de la vista de disseny o dit d’una altra manera sense tenir que picar cap línia de codi. Això s’aconsegueix amb els Triggers que els podem definir des dels estils (Style) o també des dels ControlTemplates.

Els triggers ens serveixen per poder modificar propietats o fer animacions en funció a canvis de valors d’altres propietats del control. Però aquests en Silverlight no son possible.

Solució

Doncs Micorosoft ens diu que la manera de poder simular els triggers és de dues maneres:

  • Col·loquem les animacions com a recursos i des de codi executem el mètode Begin
  • Utilitzem els VisualStates que és una altre manera de poder canviar propietats o fer animacions en funció a events. El que passa és que els events son molt específics i no sempre son els que volem.