Newsgroup: it.comp.appl.access
Titolo: Problema forse difficile, ma (altrettanto forse) stimolante.

Vorrei condividerlo con voi, avere il vostro pensiero.
Dunque abbiamo una maschera Msk, con suo modulo Mm,
un modulo pubblico standard (non di classe) M.
in Mm faccio :
public P_dati as new adodb.recordset
public P_Nome_Recordset as string
...
...
in Msk.open ( )  faccio :
me.P_dati.open "select ...from ... where nome_maschera = ' " & 
me.name
& "';" ; connessione
me.P_Nome_Recordset = me.p_dati("nome_tabella_della_maschera")
me.P ... = ... (altre caratteristica della maschera)
ecc ecc
In questo modo, e' come se avessi aggiunto un insieme di
proprieta' alla maschera facilmente accessibili dall' esterno.
Con vantaggi enormi allo scopo di rendere il sistema molto
parametrico. Ma *molto*, credetemi. Praticamente in questo
modo riempiendo opportune tabelle si puo' manovrare il
programma senza aggiungere una linea di codice.
Ma se in un secondo tempo volessi aggiungere una di
quelle proprieta' P_ ... a tutte le maschere, allora dovrei
aggiungere una linea di codice della forma :
public P_X as ... ad *ogni* maschera.
Per ovviare a cio', ho costruito una struttura pubblica
G in M unica del tipo :
public G as type
     g_1 as new adodb.recordset
     g_2 as string
     ...
end type
E poi in Mm invece di scrivere :
public P_dati as new adodb.recordset
public P_Nome_Recordset as string
...
...
mi limito a scirivere :
public P as G
E in apertura Msk.open( ) eseguo una proc
che ha in ingresso byref un riferimento alla
maschera e alla P, la quale proc mi schiaffa
nella P tutte le variabili e gli oggetti.
Spero dì essermi spiegato.
Ma purtroppo (anche se me lo immaginavo
francamente) ho chiesto troppo al VBA :
il sistema si rifiuta di compilare dicendo che
"Tipi definiti dall' utente non ammessi come
membri Public di moduli di oggetto"  :-)))
Cioe' non puoi scrivere in Mm lo statement
public P as G
Ma puoi scrivere
private P as G, ma allora non sarebbe piu' indirizzabile
dall' esterno. E quindi non serve.
Il modo per uscirne ci sarebbe, ma non ne vale la pena.
Dovrei costruire un mio controllo activex che fa il lavoro
(cioe' che ha in se la struttura dei dati) e aggiungerlo ad
ogni maschera.
Modificando quello, *tutte* le maschere sarebbero
ecc ecc. Me so stufato de scrive scusate ... Tanto ce
semo capiti.
Che ne pensate ?

 Che ne pensate ?
Io bene, visto che nelle mie applicazioni c'e' sempre una tabella 
"parametri" con struttura: chiave(nome della variabile) - valore
che carico in una collezione.
--
ac

che carico in una collezione.
Si ma penso che per fare quello che dico io ci vole un oggetto.
Forse adesso con quello che ho scritto sopra si capisce.
Fammi sapere.

 Fammi sapere.
Ao' , sei vivo ? :D

Ao' , sei vivo ? :D
Ma usare un bel file xml per rendere skinnabile tutte le interfacce invece di
tutti questi voli pindarici? Li memorizzi tutto come vuoi....
-- 

 tutti questi voli pindarici? Li memorizzi tutto come vuoi....
Che significa "skinnabile" ?

 Quando vuoi.
Azz vi siete *fidanzati in casa* ? :D


Forse voleva dire "shredding"... ossia trasformare un xml in tabella?
Xml ... antidatabase :-(
-- 
Daniele
Rispondere scartando OneEDP, spam e 32


E tu hai anche tempo per questo NG? Non e' ripartita la stagione di 
caccia (all'allenatore). Che ha fatto il Napoli?
--
ac


Avevo cestinato questo post ma ora mi sembra "fair".......
 > Ma usare un bel file xml per rendere skinnabile tutte le interfacce 
invece di
 > tutti questi voli pindarici? Li memorizzi tutto come vuoi....
 >
l'XML, se non avesse tutti gli oggetti di manipolazione a corredo, e' un 
volgare file sequenziale,difficilmente gestibile, che scimmiotta una 
struttura dati gerarchica. Come possa riuscire a "scorticare"(*) le 
interfacce lo ignoro
(*) in corretto italiano sarebbe "cambiar pelle"
--
ac


Talmente folle che con i gli esami sui databeis l'8% delle domande sno 
su XML shredding o meno 
http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-451#tab2
La moda č la moda.



Beh...certo che si...ma i dati li tiene lo stesso.....e cmq il NoSQL sta
prendendo piede no?!?! ;)
Cmq intendevo skinnabile nel senso di personalizzabile dall'utente...ho visto
cose MERAVIGLIOSE utilizzando xml come deposito di informazioni per le
interfacce.....l'utente fa quello che vuole, un file xml per memorizzare tutto
(l'accesso è veramente rapidissimo usando XPath o cose simili) e in un baleno
bottoni, colori, caratteri e quant'altro è cambiato....
-- 


La tendeza WPF è quella di separare interfaccia utente dalla logica 
dell'applicazione.
Diciamo non è proprio una cosa nuova. In teoria un algoritmo dovrebbe 
"funzionare" a prescindere dall'interfaccia o da un linguaggio di 
programmazione in particolare mi raccontavano quando non riuscivo a 
premere il pulsante dell'ascensore.
Ma difatti è mai stao così?
Gli sviluppatori sono sempre stati "costretti" a innestare 
inesorabilmente logica e interfaccia in un unico agglomerato poco 
ordinato di eventi e oggetti (dai tempi del DOS) "perdendo" molto tempo 
nella cura dell'interfaccia (necessaria se si vuole rendere il prodotto 
più apprezzabile - e non solo esteticamente)
L'idea è buona, ma vedo dei spargimenti di tonnellate di script per 
legare l'interfaccia ai dati e mi chiedo alla fine se la separazione 
implica un "ricongiungimento" moooolto più oneroso per essere gestito.
Personalmente winzoz rimane winzoz. Non ho mai creduto ai generatori 
automatici di script. Preferisco avere sempre il controllo di quello che 
scrivo, piuttosto che ritoccare e cancellare e riscrivere .
Condivido l'idea di separare logica e interfaccia, ma sinceramente non 
riesco proprio a vedere come questo si possa attuare... meno che in Access.
... a proposito. quando ci sarà il salto ad ADO.net?
Solo il business ce lod dirà.
Buona giornata ragazzacci.


 riesco proprio a vedere come questo si possa attuare... meno che in Access.
Access è l'esempio vivente che logica e interfaccia è più comodo
tenerli a braccetto, altrimenti VB avrebbe preso più piede rispetto al
nostro giocattolino (che avrebbe quindi abbandonato la scena da tempo
immemore)... e invece eccolo qua ancora giovane e vigoroso a tener
testa a prodotti dichiarati *professionali* al suo confronto. Io credo
che separare le due cose sia snaturare il prodotto, che è proprio in
questo che fonda il suo perchè. Logica = funzionalità - Interfaccia =
grafica...La grafica favorisce l'usabilità delle funzionalità, per cui
è necessario imho che l'una sia correlata sinergicamente all'altra
fino a fondersi.


Dico la verità, l'esempio che ho fatto l'ho visto realizzare con il RAD della
Borland (codegere, Embarcadero....quel che è) insomma con il C++ ai massimi
livelli (un'applicazione TERRIFICANTE, con dentro tutto, webservice, db, invio
di comandi a motori e macchine in genere......) e la necessità era quella, una
volta consegnata, di rendere l'apporto del programmatore minimo. Quindi,
interfacce personalizzabili (bottoni, posizioni, colori...), studio su dove
far apparire i popup per non coprire i comandi (il tutto è a touch) a runtime
e mille altre diavolerie per rendere l'applicazione totalmente skinnabile
(appunto) dall'utente...Il tutto tramite alcuni file xml mantenuti
nell'Application Data e nel registro. La velocità di esecuzione è mirabolante,
tenuto conto che tutte le interfacce sono costruite runtime......
-- 


A volte però la cura dell'interfaccia è un dispendio di tempo, perché 
realizzare una soluzione in vista dell'interfaccia piuttosto che della 
business logic allontana dall'obiettivo che si vuole realizzare.
L'IDE di Access dovrebbe essere rivisto! Visto che è fermo da tempo 
immemorabile! Le macro in access 2010... siamo seri per favore!
Ciao



Questo è un esempio di "separazione"
Realizzare con Access Il rendering dell'interfaccia in tempo reale 
convolgerebbe pesantemente anche la logica business che invece dovrebbe 
rimanere intatta e consolidata



Ohhhhh..... andiamo Fair.
Quello che conservi sull'XML lo puoi conservare in trecento altri 
modi:file ini, file json, asci delimitato o meno, tabella relazionale, 
chiavi di registro o nella piramide delle iscrizioni di Coba' (Honduras).
Quei valori li devi poi gestire "via logica" per fare tutte le cose che 
descrivi e, faccio un esempio, se ad un certo punto hai bisogno che un 
controllo "blinki" e non hai gia' previsto l'attributo sull'XML e la sua 
logica di gestione ti puoi fare anche verde, come i marzianetti, ma il 
controllo che blinka non lo attivi.
D'altra parte sei costretto in questo caso a impegnarti su due fronti a 
meno che la specializzazione non sia tale che c'e' l'omino drago 
dell'XML e l'omino volpe del VBA, o qualsiasi altro linguaggio.
La velocita' di esecuzione non la nego e sai che ci vuole, una volta che 
il sistema si e' costruito l'oggetto XML, ad accedere ai nodi? Non e' 
altro che quello che ho descritto in altra parte usando gli insiemi 
(collezioni).
Caricare una tantum 300K di roba, di cui utili sono al massimo 20K se 
togli i tag di attributo, non e' che ci voglia poi molto.
E non rimetto in dubbio che "skin" diversi sia poi facile attivarli ma 
prima ti sei fatto un mazzo per tirare su la loro logica di gestione che 
a confronto le 12 fatiche di ercole sono come bere un caffe'.
Anch'io in access alcune caratteristiche le ottengo cambiando 
semplicemente i valori di riferimento su una tabella parametri.
Se invece di usarne una ventina ne usassi un migliaio probabilmente 
potrei anche stupire con effetti Telefunken.
--
ac

 ac


 Alias xml antidatabase
No. La struttura dell'XML e favolosamente gerarchica. Il punto e' che va 
bene per files contenuti poiche' e' un file sequenziale e se cerchi di 
modificare qualcosa lo devi riscrivere tutto e se lo devi leggere e 
usare te lo devi tirare dentro tutto. Finche' sono pochi kappa non e' un 
problema ma se lo usi per registrarci qualche mila, milioni di records, 
magari da gestire in multiutenza, comincio a ridere e devono spararmi 
per farmi smettere.
Tra l'altro in questo caso ti tiri dentro "garbage"(*) che se ti va bene 
e' comunque il 30-40% del file
(*) i tag di riconoscimento campo che vengono ripetuti per ciascun 
valore, non a caso ha preso piede json.
--
ac

ac
Appunto!!!!! E cmq NON voglio difendere xml a priori (manco lo conosco
bene!!!!!). Dico solo che per alcune cose mi è sembrato ok.....penso per
esempio al caricamento via ftp di dati (in fondo è un file di testo...), alla
costruzione di pagine web al volo e chissà cos'altro! Ovvio NON è un database
e men che meno relazionale!!!! Ma, rispondendo a OneDep, nn esistomo mica solo
quelli.....i db denormalizzati (olap o cose così) son ben più simili a excel
che ad Access.....ma anche qua solo per fare un esempio...la mia ignoranza in
materia è ABISSALE!!!! :)
RobertoF
-- 


In giro (vedi Navition e LinQ) vedo cose più terribili :-)



QUANTO E' VERO!!!!!!!!! :)
-- 

 L'ENEL vi darebbe la caccia!
Si,
ma il restante 99% degli Italiani ci proteggerebbe.


Siccome l'unica cosa che ho capito finora è che ci sono rovine a Coba
in Honduras, pensate che mi convenga smettere di usare Access e mi
procuri un casco da esploratore? :-)
Riccardo Baldinotti


Decisamente le scelte commerciali intraprese da mamma microsoft mettono 
a dura prova gli accessisti e gli sviluppatori in genere che devono 
sempre adeguarsi seppur non condividendole
Access è diventato più accattivante ma sono secoli che aspetto... e aspetto.
Non ci resta che esplorare invece che aspettare non credi? :-)
