Newsgroup: it.comp.www.php
Titolo: [OT] Una stringa per domarli, Una stringa per trovarli, Una stringa per ghermirli e nel buio incatenarli

Scusate il titolo, ma è stato più forte di me ;)
 
Dunque, stiamo implementando in un progetto php una stringa che, formattata in un certo modo, consente di recuperare elementi di qualsiasi tipo all'interno dell'applicazione (quindi utenti, informazioni sugli utenti, contenuti [articoli, etc..].. insomma qualsiasi cosa) invocando i vari controller.
 
Queste stringhe vengono poi utilizzate per la personalizzazione da parte dell'utente di molti aspetti dell'applicazione (label dei campi nei form, eventi/regole, permessi ACL personalizzati, condizioni, etc..)
 
Mi domandavo se è una pratica comune, già vista (e di conseguenza se esiste un pattern) per vedere se abbiamo per l'ennesima volte reinventato la ruota e, evantualmente, vedere se ci siamo dimenticati qualcosa e prendere spunto.
 
Idee?

 eventi/regole, permessi ACL personalizzati, condizioni, etc..)
 
Da quanto scrivi sembra che stiate registrando le impostazioni del 
programma in un stringa. Sarebbe forse più comodo usare una struttura 
più articolata (un oggetto, un array) e serializzarla.

 Mi domandavo se è una pratica comune, 
 
esistono i file .ini, fin da win 3.1 :) e li supporta pure php.
 
-- 
Alessandra
 
Il prete è come un bagarino all'ingresso del paradiso - Henry Luis
Mencken

utenti, contenuti [articoli, etc..].. insomma qualsiasi cosa) invocando i vari controller.
 
Detto cosi' e' un po' vago.
 
Se e' qualcosa del tipo "/content/articles[id=123]/form/name"="Nome:",
potresti indagare qualche libreria per l'uso di selector, e/o staresti
chiedendo all'utente di scrivere qualcosa di simile a XSL.
 
Anzi, alcune cose a quel punto potresti farle forse senza neanche gran
controller, solo con XSLT. Se ho vagamente capito di che si parla, che
non e' proprio sicuro :-)
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 Mi domandavo se è una pratica comune, già vista
 > (e di conseguenza se esiste un pattern) [...]
 
Era una pratica molto comune fino agli anni '80, poi si sono diffusi 
database relazionali, linguaggi ad oggetti, protocolli di rete e 
fortunatamente la pratica è stata abbandonata ;)
 
Battute a parte:
- per i pattern puoi cercare sotto "Metadata Pattern", "Memento pattern" 
o "Proxy pattern" (ovviamente i pattern riguardano un più alto livello 
di astrazione);
- in che formato è la stringa? Qui vi consiglio di evitare di 
reinventare la ruota, usando formati diffusi (XML, JSON, 
serializzazione, etc.).
 
E' un approccio che adotto spesso anch'io. Ultimamente mi sono orientato 
sempre più verso JSON (è leggibile, conciso e ha parser veloci in tutti 
i linguaggi), in generale uso appositi oggetti serializzati.
Problemi ne compaiono solo con grosse moli di dati, lì conviene usare 
apposite basi dati strutturate per gestire chiavi -> valori in modo 
gerarchico. Mi trovo bene con HDF5 ma ci sono anche vari database NoSQL 
validi allo scopo.
 
Buon lavoro! :)
Pablo

 Come si implementano le stringhe?
 
Un esempio di stringa potrebbe essere "nod:3;opr:values;key:commenti;key:user_email|*" per recuperare tutti i commenti fatti all'articolo 3.
 
Fondamentalmente la stringa è composta da una parte fissa di 3 lettere che identifica il tipo di risorsa (e la funzione che dovrà gestirla), seguita da i vari parametri/opzioni (che dipendono dal tipo di funzione)
 
@Alessandra R: no i file .ini non c'entrano niente ;)
 
@pablo: l'applicazione gira metà su Postgres+json e metà su Mongodb, quindi il json è già largamente utilizzato.. non è male come idea, mi leverebbe tutto l'impiccio di controllare il formato della stringa tramite regexp e il parsing (anche se abbastanza semplice)..
 
Ci ragiono un pò su

Edit: la stringa di esempio sopra recupera tutti gli indirizzi email di chi ha commentato l'articolo 3, non tutti gli articoli ;)

Il 15/06/2012 00:39, Strae ha scritto:

Più che altro, battua per battuta,  mi pare un "Ritorno al futuro" dal 
celebre film.
Il metodo molto simile a quello che che tu descrivi  lo utilizzai negli 
anni '80 per implementare un database per Commodore 64.
Leonardo
 

 
 
A parte i complimenti per l'oggetto della discusisone :)
 
Perche' non implementate una struttura basandola sulle risorse (tipo RESTFul)?
 
Una cosa del genere: /commenti/ID_ARTICOLO/ALL/user_email,desc
Per avere tutti i commenti all'articolo ordinati per "user_email" discendente
 
Io trovo questa cosa molto comoda perche rende immediato individuare le risorse
 
J.

 tramite regexp e il parsing (anche se abbastanza semplice)..
 
Valuterei anche io se puoi fare la stessa cosa con URL REST-like. Dipende 
dalla complessita` delle operazioni, ma il REST potrebbe anche porti un 
limite psicologico che dica "guarda che l'utonto fin qui ci arriva. Oltre 
fa fatica". :)
 
Bye.

Abbiamo cercato di mantenere il formato in "tanti piccoli pezzi consecutivi" perchè questa stringa deve permettere di recuperare qualsiasi risorsa dall'applicativo, oltretutto consente anche stringhe annidate (che potenzialmente però rompe la _consecutività_) e considera il versionamento; Quindi ci è sembrata una buona soluzione separare i tipi di risorsa avendo per ognuna un callback diverso (e ogni tipo implementa le proprie opzioni)..
 
Il RESTFul mi sembrava un pò troppo 'vincolante', ma tanto vale provare (visto che nel frattempo abbiamo deciso di riscriverlo in json, siamo a un punto dove _o ora o mai più_)
 
 
@Pellizzari l'opzione |* è valida solo per array (key) e attributi di oggetti (opr), e significa "prendi solo questa chiave di tutti gli elementi", quindi se nell'esempio sopra "nod:3;opr:values;key:commenti;key:user_email|*" si ritrova questo valore:
 
stdClass{
   'values' => array(
    'commenti' => array(
      array(
        'testo' => 'foo',
        'user_email' => '
b...@example.com
'
      ),
      array(
        'testo' => 'bar',
        'user_email' => '
f...@example.com
'
      ),
    ),
    'titolo' => 'un articolo'
  )
}
 
mi recupera un array con 
b...@example.com
 e 
f...@example.com
 

 Idee?
 
REST + JSON
Con qualche ricerca troverai moltissime informazioni e anche qualcosa 
di già pronto, da utilizzare o da cui prendere spunto.
Un saluto
 
-- 
Emanuele Desideri
 
 

 Queste stringhe vengono poi utilizzate per la personalizzazione da parte dell'utente di molti aspetti dell'applicazione (label dei campi nei form, eventi/regole, permessi ACL personalizzati, condizioni, etc..)
zac
Io mi concentro su questo aspetto...versatilità per la swhouse ed 
interazione uTontifera!
 
Mia esperienza
progetto web ASP.net
progetto standalone VB.net/C#
....le impostazioni stanno tutte in un mdb: config.mdb
 
progetto web php
.....le impostazioni stanno tutte in un sqlite : config.sq3
 
recentemente visto che ho trovato il modo di agganciare sqlite anche ad 
asp.net....uso sqlite anche sotto windows!
 
Una query di select
una query di insert
una query di update
passa la paura
ed  hai il livello di complicazione che vuoi
 
Nessuno
Versioning (metti un campo 'versione')
MultiUtonto(ad esempio: metti un campo 'livello' sopra quel livello 
possono leggere il valore dell'opzione!)
Strutturato(Categoria IDpadre IDfiglio per valori dipendenti da altri ad 
esempio: l'iva la cambiano se hanno il modulo fatture installato!)
 
rimane pulito leggere il tutto....
rimane facile fare una tabella con le opzioni elencabili e modificabili 
(anche nascosta all'utente...classico: per te swhouse che fai 
manutenzione/personalizzazione!)
 
etc etc
 
Io lo trovo comodo e versatile: il db me lo faccio prima ....è un 
file....posso anche scrivere una miniapp che fa l'update in automatico 
da remoto!
Rallenta???
Boh pochissimo...non lo noto!
.....ma son convinto che parserizzare una stringa....ora per test...che 
sono poche e non incasinate sarà velocissimo!
Quando avrai file con stringhe lunghissime da memorizzare e ritrovare e 
decodificare....ne riparliamo!
E anche lo scrivere un tool che gestisca la creazione e manutenzione di 
queste stringhe non sarà semplicissimo!!!
 
Ovviamente sempre e soltanto IMHO ...è la mia esperienza sul campo!

Scusa ma non ho capito cosa c'entra con la discussione ;)
 
Quello che interessa a me non è dove sono i dati, che fondamentalmente non deve (non deve proprio) dipendere da questa stringa/oggetto json, ma solo un metodo per poter accedere a qualsiasi risorsa in modo flessibile e _pseudo_ semplice (l'utonto non mi scrive la stringa o il json, ma lo crea da una gui fatta su misura)
 
Poi ho una classe che _macina_ questa stringa e recupera i valori (invocando i vari controller, tutto sotto strict MVC)
 
 
Abbiamo già deciso di passare a Json in toto, eliminando anche il problema dell'annidamento di più stringhe


 
Chiedevi se è pratica comune mettere le risorse in una struttura 
descritta da una stringa! Più o meno articolata!
 
Probabilmente si!Per microsoft e l'assurdo numero di file XML di 
configurazione che crea per un qualsiasi progetto...sicuramente si!
...per noi no!
 
Noi ficchiamo tutto in un DB...possibilmente basato su file...access o 
sqlite!
 
L'ho visto fare da programmatori molto più esperti di me...ed ha una 
mission: bacarsi poco le palle con le frequenti richieste dei clienti! 
Anche se non è alla moda o non è elegante!
 
Dentro una classe... uno script....dove vuoi
 
SELECT varTXT FROM Config WHERE chiave='EmailCliente'
SELECT varBOOL FROM Config WHERE chiave='modCaptchaEnable'
SELECT varTXT FROM Config WHERE chiave='pathimgFaviconCliente'
etc etc
Lo troviamo comodo!
...il core è sviluppato e manutenuto....
mentre il config.db cambia da cliente a cliente....invece che avere una 
ventina di XML/JSON ...o un mega XML....abbiamo un file database!
 
Chiedevi se si fà!
SI....noi no....ma gran parte della mondo lo fà...gli garba spippolare 
un file di testo!
eh eh eh :)

Ehm non hai capito.. ovvio che i dati li tengo su un DB e non in file di testo..
 
Ti faccio un esempio, prendiamo un utente: io a database ho tutti i suoi dati, ma l'applicativo mi genera (MVC) un oggetto rappresentante l'utente, con vari metodi (ad esempio quelli relativi all'ACL).
 
Se, per qualsiasi motivo devo recuperare (in modo dinamico, senza dover scrivere una riga di codice) qualche dato dell'utente per metterlo, bhò, nel titolo di un articolo, o per fare dei controlli, utilizzavo la stringa di questa discussione.
 
Ma nella stringa _non_ ci salvo alcun dato, era solo una rappresentazione che una classe utilizza per sapere a sua volta dove andare a recuperare i valori.

 Ehm non hai capito.. ovvio che i dati li tengo su un DB e non in file di testo..
 
 
Abbi pazienza ...di MVC l'ho capito ora! ....E' venerdì anche per me!
 
Tu mi parli di risorse...ed io capisco storage di setup ed affini 
(...alla windows)
 
tu invece mi parli di risorse intese secondo REST e quindi mi parli di 
"come" rappresentare/scambiare queste descrizioni di risorse!!!
 
Ho letto che MongoDB implementa una ...aspetta come dice...
 
"The simple ReST interface uses strict JSON (as opposed to the shell, 
which uses Dates, regular expressions, etc.). To display non-JSON types, 
the web interface wraps them in objects and uses the key for the type."...
 
 
...quindi forse una particolare attenzione a parserizzare la stringa e 
costruire il JSON come ti diceva Alessandro....
 
Ma il framework di supporto esiste? E' roba vostra? ...che preferisce?
 
Sorry per la mia durezza di comprendonio!!!!
 

Tranquillo ;)
 
Il framework lo stiamo facendo ad-hoc da zero..
Cmq ho appena finito di aggiornare la classe che gestiva la stringa con il json ;)