martedì 30 agosto 2011

How To: javascript ceil e floor

Ceil e Floor in javascript restituiscono un numero arrotondato per eccesso nel primo caso e per difetto nel secondo.

Entrambi appartengono a Math e il loro utilizzo è discretamente diffuso, soprattutto se si sta realizzando un applicazione dove è necessario verificare i dati immessi in
un form ( posto che questi siano numeri ).

Math.ceil(9.9) restituisce 10
Math.floor(9.9) restituisce 9

Di contro potrebbe essere plausibile comprendere quali dei due arrotondamenti utilizzare e in che misura.

var y = 0;

if (Math.ceil(x) == Math.floor(x))
{
// in questo caso è uguale
y =Math.ceil(x);
}
else
{
// esempio
// 10 è il ceil di 9,1
// ma evidentemente vogliamo
// ottenere 9 e non 10
if ( Math.ceil(x)-x > 0)
{
y =Math.floor(x);
}
else
{
y =Math.floor(x);
}
}


In questo caso un esempio di come si potrebbero utilizzare sia il ceil che il floor.

lunedì 29 agosto 2011

How To: javascript Random

Ecco un banale esempio di come ottenere un numero pseudocausale in javascript.

Math.random();

Il metodo deriva dall'oggetto Math, che presenta le principali funzioni matematiche.

Le possibili variazioni sul caso possono essere:

Math.floor(Math.random()*x);

dove floor consente di arrotondare un numero al PIU' basso intero.
Se avete per esempio Math.floor(3.2) il risultato sarà 3
Se avete per esempio Math.floor(3.7) il risultato sarà 3


dove x è un numero per cui ingrandire il risultato di random.

domenica 28 agosto 2011

How To: Create Event in Javascript

Che cos'e' un evento ??? Per javascritp un evento è il frutto di una azione scatenata da un altra azione.

Per ogni azione esiste una reazione uguale e contraria cita la dinamica, ma non è questo il caso.

Creare un evento implica che si sta realizzando un oggetto che consenta la creazione di un delegato che possa gestire l'evento.

Per fare un esempio comprensibile, "Preparare la tavola" è l'evento, l'ora di cena attiva la Mamma che scatena l'evento "Preparare la tavola" e noi siamo i delegati al compito !

function Mamma()

{
this.onOraDiCena = null;
this.OraDiCena = null;

Mamma.prototype.getValue = function () {
return this.OraDiCena;
}

Mamma.prototype.setValue = function (v) {
this.OraDiCena = v;

if (this.OraDiCena =true)
{
if (typeof this.onOraDiCena == 'function')
this.onOraDiCena ();
}
}
}


function DoPreparaTavola ()
{
alert ("E' ora di cena Prepara la tavola " );
}

var oMamma = new Mamma ();
oMamma.onOraDiCena = DoPreparaTavola;
o.OraDiCena (true);


Ed ecco l'esempio "pratico pratico! "
( buon appetito, e non dimenticate i tovaglioli !!)

sabato 27 agosto 2011

XA.EF Entity framework (4)

Benchè nel terzo capitolo abbia speso qualche parola per la costruzione di una proprietà c'e' da aggiungere ancora molto altro. Indubbiamente mancano gli attributi, custom o dipendenti da Linq to Sql.

Verosimilmente il concetto di attributo dovrebbe essere quanto di più esplicativo per il destino della proprietà stessa, ma deve dare anche un "lume" su come potremo utilizzare la proprietà o se questa sarà visibile o meno.

Questo punto diciamo che decisamente "analitico" ossia, dato che l'implementazione è ancora molto lontana posso scegliere arbitrariamente di:

-presentare un form con tutti i campi di una tabella e attribuirgli la visibilità.
-dare la possibilità all'utente di modificare gli attributi agendo sul codice.

A ben pensarci il primo caso sembra sicuramente il più ovvio, di contro portei sfruttare quanto esposto nel post della persistenza, per avere un "registro di quanto implementato" per poi ripresentarlo all'utente che sta rigenerando le classi.

Sempre etendendo il ragionamento se genero tutto io, so che cosa ho generato. Ma gli utenti sono utenti ( e del resto anch'io ) quindi è noto il fatto che lanciato un script si ha "il prurito" di vedere che cosa è sucesso.
Quindi tanto vale lasciare la possibilità all'utente di modificare il codice generato.

Una versione semplificata di questi attributi potrebbe essere resa tramite quanto segue.

using System;

using System.ComponentModel;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace XA.EF.Test
{

[System.AttributeUsage(
AttributeTargets.Class|
AttributeTargets.Field|
AttributeTargets.Property,
AllowMultiple = true)]
public class DbMapperAttribute:System.Attribute
{
private string _dbFieldName;
private string _mappingEntity;
private string _headerOrCaption;
private eFieldVisibility _visibility;
private int _columnOrder;

public string dbFieldName
{
get { return _dbFieldName; }
}

public string mappingEntity
{
get { return _mappingEntity; }
}

public string headrOrCaption
{
get { return _headerOrCaption; }
}

public int columnOrder
{
get { return _columnOrder; }
}

public eFieldVisibility visibility
{
get { return _visibility; }
}

public DbMapperAttribute(
int ColumnOrder,
string DbFieldName,
string MappingEntity,
string HeaderOrCaption,
eFieldVisibility Visibility
)
{
_dbFieldName = DbFieldName ;
_mappingEntity = MappingEntity;
_headerOrCaption = HeaderOrCaption;
_visibility = Visibility;
_columnOrder = ColumnOrder;
}
}
}


e per dar maggior chiarezza, questo è l'enumerativo che utilizzo.

using System;

using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace XA.EF.Test
{
public enum eFieldVisibility
{
none,
grid,
details,
both
}
}


Tuttavia è facile comprendere che l'attributo derivante servirà anche per mostrare o non mostrare l'elemento in una griglia o in un form di dettaglio.

Ciò detto mi è utile considerare sempre più che per la realizzazione di un E.F. strutturato e elastico è sicuramente necessario scrivere una serie di classi che vadano ben oltre alle entità.

venerdì 26 agosto 2011

How To: object persistence c#

Per prima cosa chiariamo il concetto di "persistenza".

L'argomento è molto vario, c'e' chi sottintende con persitenza la possibilità di mantenere il valore di un oggetto per la durata di tutta una sessione di lavoro.
E quindi questo implica che l'oggetto stesso sarà di tipo statico. Il che non implica
nulla di diverso dal modificatore d'accesso "static".

C'e' chi per persitenza intende il salvataggio fisico del Dato su db, ma questo implica
che il tipo stesso sarà un entity e probabilmente ha vita e logica direttamente legate
al db stesso.

Quindi quali di questi sostenitori hanno ragione? In parte entrambi, in parte nessuno,
perchè entrambe le definizioni sono carenti o meglio incomplete.

Un oggetto persistente è un classe, che "dopo l'utilizzo", "dopo la distruzione", "dopo aver chiuso e riaperto la nostra applicazione" ripresenta i dati.

Qui qualcuno potrebbe dire Bella scoperta li pre imposto by Default, già ma questa non è persistenza è pre impostazione.

Partiamo quindi con un esempietto che ci permetterà di meglio comprendere la situazione:

public class UserDefinitions

{
private string _Alias;
public string Name { get; set; }
public string Surname { get; set; }
public string Alias
{
get { return _Alias; }
set { _Alias = value; }
}
public DateTime LastAccess { get; set; }
}


Si tratta di un oggetto più o meno semplice, il cui scopo è "mantenere" vive le informazioni di un utente.
Non è difficile notare che ho già fatto in modo che la property Alias già nasconda il field _Alias. Ci servirà per l'esempio.

Così come ci servirà nell'esempio anche quanto già scrissi per la serializzazione ..

public static class XmlDeSerializerTool

{

public static void Serialize<T>(string fileName, T elements)
{
TextWriter tw = new StreamWriter(fileName);
XmlSerializer xmls = new XmlSerializer(typeof(T));
xmls.Serialize(tw, elements);

tw.Close();
tw = null;
xmls = null;
}

public static T Deserialize<T>(string fileName)
{
Type e = typeof(T);

T elements = (T)Activator.CreateInstance(e);

TextReader tr = new StreamReader(fileName);
XmlSerializer xmls = new XmlSerializer(typeof(T));

elements = (T)xmls.Deserialize(tr);

tr.Close();
tr = null;
xmls = null;

return elements;
}
}


Che "come al solito riciclo per questioni di comodità".

Quindi la nostra classe assume un aspetto più interessante, implementado un evento, direttamente da component model.

public class UserDefinitions :System.ComponentModel.INotifyPropertyChanged

{
public event PropertyChangedEventHandler PropertyChanged;

private string _Alias;

public string Name { get; set; }
public string Surname { get; set; }
public string Alias
{
get { return _Alias; }
set {
_Alias = value;
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs("Alias"));
}
}
}
public DateTime LastAccess { get; set; }

}


Questo per definizione ha già la possibilità di indicare quale proprietà è cambiata.

Una breve precisazione, utilizzando il mio DE/SErializzatore non è necessario implementare il costruttore, ne gli attributi necessari per la serializzazione, ma questo lo si deve in parte a XmlSerializer.

A questo punto creiamo un caso di test.

static void Main(string[] args)

{

UserDefinitions ud = new UserDefinitions();
if (File.Exists(@"c:\myData.xml"))
{
ud = XmlDeSerializerTool.Deserialize<UserDefinitions>(@"c:\myData.xml");
}
else
{
ud.Name = "Fabio";
ud.Surname = "Arosio";
ud.Alias = "TheMa!";
}
ud.PropertyChanged += new PropertyChangedEventHandler(us_PropertyChanged);
ud.LastAccess = DateTime.Now;
}


e qui il delegato per la gestione della propertyChange

public class UserDefinitions :System.ComponentModel.INotifyPropertyChanged

{
public event PropertyChangedEventHandler PropertyChanged;

private string _Alias;

public string Name { get; set; }
public string Surname { get; set; }
public string Alias
{
get { return _Alias; }
set {
_Alias = value;
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs("Alias"));
}
}
}
public DateTime LastAccess { get; set; }

}


Di concetto questo caso ha poco valore, se non pochissimo, ma mi è servito per salvare il file xml e per mostrarne il contenuto.

<?xml version="1.0" encoding="utf-8"?>

<UserDefinitions
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Name>Fabio</Name>
<Surname>Arosio</Surname>
<Alias>TheMa!</Alias>
<LastAccess>
2011-08-26T15:18:34.1125638+02:00
</LastAccess>
</UserDefinitions>


E bene questa è la nostra "persistenza".

Attenzione non stiamo parlando di soli dati, ma anche della struttura del dato, non del singolo valore.

Di contro questo concetto sembra molto complesso, anche se secondo me, i dubbi nascono su che cosa realmente deve essere inteso come "persistente", e non tanto su come deve
avvenire la persistenza.




lunedì 15 agosto 2011

XA.EF Entity framework (3)

Per le entity e la collezione rimango ancora due o tre cosuccie da definire.

Dato che a priori non potrò sapere in quale lingua è stato realizzato il db e dato che non voglio studiarmi, quanto meno per il momento, una regular expression, per definire i singolari e i plurali.

Utilizzerò questa convenzione:
-NomeEntita = NomeTabella,
-NomeCollezione = NomeTabella_List,
-NomeAdapter = NomeTabella_Adapter.

Che per il momento ritengo valida e plausibile. Di contro c'e' ancora da considerare come si potrà utilizzare questo prodotto.

La prima idea è stata di realizzare un plugin per la ide, ma non mi ha convinto del tutto. Ritengo che la realizzazione di un prodotto Stand Alone possa dare maggior equilibrio, certo è vero che questo presupposto allontana un po' dall'usabilità stessa.

Quindi tornando alle mie preziose definizioni, direi che per l'entità posso raccogliere:
-Using ( servono sempre )
-Namespace ( per forza )
-Modificatore
-Nome classe
-Elenco di Field
-Elenco di Property
-Flag per creare il costruttore
-Flag per creare il distruttore
-Override di ToString ( che lascerò come fisso ... vedi post: ToString


Questo implica che dovrò implementare un writer overridabile per ogni elemento presente in questa lista.
Non solo devo creare anche un Tipo per i Field e un tipo per le proprietà, in questo modo prevengo il dover effettuare un continuo accesso al db.
Di concetto mi piacerebbe estrarre tutto fin dall'inizio, leggerlo e processarlo. Mi sta quasi balenando l'idea di creare un seriliazzatore anche se forse non è il caso.

public class PropertyPrototype

{
private string _accessType;
private string _valueType;
private string _name;
private string _description;
private bool _isReadOnly;

public string AccessType
{
get { return _accessType; }
set { _accessType = value; }
}

public string ValueType
{
get { return _valueType; }
set { _valueType = value; }
}

public string Name
{
get { return _name; }
set { _name = value; }
}

public string Description
{
get { return _description; }
set { _description = value; }
}

public bool IsReadOnly
{
get { return _isReadOnly; }
set { _isReadOnly = value; }
}
}


Partendo quindi dal prototipo più interessante mi sono ricavato questa classe, che per il momento descrive egreggiamente una proprietà.

public class PropertiesPrototype : List<PropertyPrototype>

{

}


E giusto per non smentirmi questa è la mia collezione.

domenica 14 agosto 2011

XA.EF Entity framework (2)

Il post precedente si era concluso con queste affermazioni:

L'Entità per il mio framework deve:
A)contenere delle proprietà che rappresentino la fonte da cui arriva,
B)contenere un metodo o un delegato che ne esegua la traccia,
C)contenere un evento che mi sappia indicare che lo stato è cambiato.


La collezione di elementi per il mio Entity Framork:
A)sarà reso con un lista,
B)conterrà i commenti come per l'entità,
C)non avrà bisogno d'altro.


Entrambe vere e parzialmente incomplete. Nel senso che mi ero già permesso di asserire, che avrei lasciato spazio a più possibilità. Quindi questo implica che volendo un utente potrà comunque scrivere una sua entità, magari indipendente dalla base dati da cui siamo partiti per realizzare le nostre entità.

Quindi potrbbe tornarci utile avere una base astratta che rappresenti l'entità

abstract class XAEntiy

{
public event EventHandler

}

delegate void XAEntityChangedEventHandler(XAEntityChangedEventArg Args);


class XAEntityChangedEventArg : EventArgs
{
public string ActualEntityValue { get; set; }

public XAEntityChangedEventArg( string Arg )
{
ActualEntityValue =Arg ;
}
}


abstract class XAEntiy
{
public event XAEntityChangedEventHandler StatusChanged;
}


Il tutto potrebbe sembra decisamente incomprensibile, ma analizzando il codice scopriamo che :
delegate void XAEntityChangedEventHandler(XAEntityChangedEventArg Args);


Sarà il nostro delegato che firma l'evento.

In più abbiamo anche gli eventuli argomenti legati all'evento, e di seguito la classe
astratta.

abstract class XAEntiy

{
public event XAEntityChangedEventHandler StatusChanged;
}



Tuttavia, vorrei anche implementare un interfaccia IXAEntity che ci darà la possibilità di avere un legame forte con la struttra.

In tutto questo emerge che il mio E.F. fondamentalmente si occuperà di scrivere le classi e di renderle sempre disponibili. Verosimilmente l'idea ora mi convince, tuttavia ho qualche dubbio sulla sincornizzazione.

Quindi :

L'Entità per il mio framework deve:
A)contenere delle proprietà che rappresentino la fonte da cui arriva,
B)contenere un metodo o un delegato che ne esegua la traccia,
C)contenere un evento che mi sappia indicare che lo stato è cambiato,
E)Implementeranno un interfaccia, un contratto solido,
F)una base astratta per tutti quello che non dovrà essere reimplemenato.
G)Le mie classi saranno scritte fisicamente nella soluzione.