Custom Resource Classes, cosa ne pensate?

Ciao a tutti! Volevo intavolare questa discussione sulle CRC. Ne fate uso? Qual'è il motivo per cui avete deciso di implementare delle CRC, magari al posto delle TV o di MIGX?

Inoltre, che tipo di CRC avete sviluppato? CRC che estendono xpdoSimpleObject o anche che estendono modResource?

Io ho quasi sempre sviluppato le CRC in tutti i miei progetti, e specialmente nell'ultimo, ho creato circa 6-7 CRC che estendono le modResource, e devo dire che sono davvero ottime per la personalizzazione del back-end, inoltre mi hanno permesso di ridurre il numero di snippet da svilupparci sopra poiché ciò che avrebbero dovuto fare gli snippet ora sono i metodi delle classi a farlo, di conseguenza anche il richiamo di tali funzioni è divenuto molto semplice!

Voi cosa ne pensate?

Ciao solidusite
personalmente non ho mai sentito il bisogno di implementare delle Custom Resource Class,
mi son sempre bastate le 4 Resources Class già presenti (Documents, WebLinks, SymLinks, Static Resources).
Per la personalizzazione del back-end in particolare della visualzizazione delle risorse uso spesso la Form Customization.

Sono piuttosto allo scutro delle potenzialità delle CRC, puoi farci qualche esempio di utilizzo, qualche tuo caso studio?

Grazie

Ciao!
Le CRC sono uno strumento potentissimo e permettono una gestione molto più ampia delle risorse in modx.

Il punto non è se utilizzarle o meno al fine dello sviluppo del sito web (modx è un framework che permette di realizzare una struttura in tanti modi diversi), ma riguarda diversi aspetti, come la possibilità di rendere il back-end uno strumento molto più personalizzabile e "user-friendly" per i clienti. Diciamoci la verità, modx non è un CMS, non è come wordpress che persino le persone più "inesperte" possono utilizzarlo.
Lasciare una risorsa come tale non la rende immediatamente comprensibile ai clienti, e le TV non risolvono tutti i problemi.
Faccio un esempio stupido: I campi della scheda "Resources" (introtext,resource URI, hidemenu, etc) non sempre vengono utilizzati o comunque non è necessario visualizzarli, o magari gli si vuole dare un significato diverso, oppure cambiargli il nome, il punto è che se applichi delle modifiche alla risorsa "modResource" poi tutte le risorse del sito saranno affette da quelle modifica! assolutamente non adatto).

Prendiamo ad esempio il mio caso di studio di un'agenzia viaggi online.

Questa agenzia viaggi, come ogni altra, propone delle destinazioni, che si diversificano in base al loro tipo: Crociera, Hotel/Resort oppure un Evento.
Ognuna di queste classi di destinazione possiede informazioni diverse (alcune gestite con le TV, altre no). Prendiamo l'esempio delle Camere di un Resort, o delle Cabine di una Crociera. Ad ogni camera/cabina, che possiede le sue informazioni, è abbinata una tabella prezzi, con tutte le sue relative informazioni (costo, periodo di validità, tipologia di prezzo, utilizzo, etc etc).

Come affronteresti tutto questo su modx? Come gestisci la tabella dei prezzi di una camera? Certo puoi utilizzare MIGX e fare una collezione di TV, ma per mia esperienza personale MIGX è assolutamente un extra non adatto da far gestire alla mia clientela (oltre ad essere pieno di errori).

Sviluppando invece delle CRC ho la possibilità di diversificare le risorse, in modo che ognuna di esse possieda le giuste informazioni da mostrare/personalizzare (anche in relazione a ciò che il cliente richiede), inoltre le CRC permettono di elaborare in maniera totalmente autonoma la disposizione delle informazioni all'interno di una risorsa.

Ovviamente la scelta di utilizzare le CRC (CRC di tipo xpdoSimpleObject) riflette anche sulla struttura del database, poiché per ogni CRC xpdoSimpleObject coincide una tabella del DB, con tutte le conseguenze che ne derivano. Invece le CRC che estendono modResource fanno riferimento sempre alla stessa tabella DB (modx-site-content, quel che cambia è la class_key)

Tornando al mio caso di studio, ti ripropongo l'esempio di un Resort e delle sue camere:
Un Resort è una CRC che estende modResource, quindi in quanto tale ripropone tutte le informazioni e i metodi delle classiche risorse di Modx.
Anche la Camera di un Resort è una CRC che estende modResource. Utilizzando quindi questa relazione ho creato un albero di risorse adeguato al mio caso:
Un resort può contenere al suo interno solo risorse di tipo Camera (vedi figura 1) (filtraggio che non puoi fare se non con le CRC, poiché ti permettono di personalizzare il Resource Tree e le azioni applicabili su di esso).
Quindi uno dei primi vantaggi visibili è la gestione dell'albero delle risorse, che altro non è che la struttura del tuo sito web dal punto di vista del back-end. Come puoi vedere dall'immagine, il menu delle opzioni è diverso da quello classico e privo quindi di possibili errori da parte dei Content Editor (puoi solo creare una camera dentro un resort).

Il secondo vantaggio immediatamente visibile è, come già preannunciavo in precedenza, l'aspetto delle risorse. A tal proposito nella seconda schermata è possibile notare come una Camera di un resort possieda informazioni totalmente differenti dalla risorsa classica di modx.
Innanzitutto mi permette di scegliere come e cosa visualizzare tra i vari campi della risorsa. Come vedi dalla fig 2 la prima schermata è il pannello delle TV (e fin qui non cambia niente, se non l'ordine di visualizzazione delle schede), poi c'è una scheda chiamata SEO che gestisce ogni aspetto del SEO relativo a quella pagina(titolo,keywords, uri, mostra/nascondi dal sito, etc).
La terza scheda è forse la più interessante (fig 3).
Questa scheda è l'implementazione dei prezzi relativi a quella camera. Anche il singolo prezzo è una CRC, ma a differenza delle altre non estende modResource, ma xpdoSimpleObject, il che la rende una classe totalmente diversa e priva dei metodi delle classi modResource. Ovviamente queste classi sono mappate in modo tale da poter ricavare, ad esempio, tutti i prezzi di una camera con un semplice $room->getMany('price') (ringraziamo xpdo).
La cosa interessante è che appunto la rappresentazione grafica di tale classe è espressa in quella scheda secondo la mia realizzazione, ho quindi il pieno controllo su di essa.
Si può implementare, ad esempio, attraverso extJS la funzionalità che selezionando/compilando un campo generi l'elenco di un altro campo (il classico select Stato-Regione-Città).

Questi sono degli esempi diretti di come la gestione delle risorse cambi all'interno del back-end, rendendolo "personale" e adatto alle esigenze del cliente.

I vantaggi però non sono solo da quel punto di vista, infatti la creazione di CRC permette poi lo sviluppo di metodi aggiuntivi alle classi modResource, che altro non sono che i nostri snippet.

Ovviamente è sempre meglio valutare se ne valga la pena o no di creare le CRC. Nel mio caso direi che non ci fosse alternativa a questa metodologia. Ogni classe possiede i suoi metodi, le sue informazioni e le azioni applicabili su di essa.

I vantaggi possono anche essere di natura operazionale, rendendo la gestione delle classi CRC più "veloci" e dinamiche in confronto alle classiche modResource.
Senza considerare che in quanto CRC che estendono le modResource, per definizione possiedono tutte le loro caratteristiche, quindi ciò che già puoi fare con le risorse classiche puoi farle anche con le CRC.

spero di essere stato abbastanza chiaro nella mia esposizione. Di cose da dire ce ne sarebbero molte altre, però già questo dovrebbe farti capire la differenze nella gestione di CRC vs MIGX o derivati.




[ed. note: solidusite last edited this post 10 years, 6 months ago.]

Ciao solidusite

ti ringrazio innanzitutto per il tuo contributo con questo ottimo post ben argomentato.
il resort per scambisti è eccezzionale

E' magnifico constatare come MODX lasci svariate opportunità per gestire ogni situazione.

Rimango comunque perplesso riguardo la scelta di utilizzare CRC, la personalizzazione che puoi ottenere con l'uso del Form Customization è pressochè identica; puoi gestire set diversi in base al template della risorsa, al gruppo utente alla Modifica o Creazione della stessa, al settaggio di una certa TV, piuttosto velocemente. Anche con le MIGX mi son trovato sempre bene, io come i clienti alle quali le ho proposte.

Le CRC saranno sicuramente più raffinate, e lo studio per l'implementaziione delle stesse credo che spalanchi nuovi orizzonti, anche in altre situazioni, ma il tempo di sviluppo va ampiamente a loro svantaggio.

Mi piacerebbe leggere altri pareri.

Scusa la frettolosità del post ma devo scappare.
Grazie ancora per aver introdotto questo argomento

ciao

ps.
"Un resort può contenere al suo interno solo risorse di tipo Camera (vedi figura 1) (filtraggio che non puoi fare se non con le CRC, poiché ti permettono di personalizzare il Resource Tree e le azioni applicabili su di esso)."

quando ho dovuto affrontare questo problema utilizzavo un plug-in all'evento di creazione risorsa che controllava il template della risorsa padre e in base a quella settava il template alla figlia

ahahah si lo ammetto ho scelto un caso di studio un pò particolare, così ci facciamo anche due risate xD
Comunque ti ringrazio! modX è davvero un gran sistema.

Devo ammettere che, come scritto anche nell'altro topic, ero all'oscuro delle potenzialità del Form Customization.
Come hai detto tu:

Le CRC saranno sicuramente più raffinate, e lo studio per l'implementazione delle stesse credo che spalanchi nuovi orizzonti, anche in altre situazioni, ma il tempo di sviluppo va ampiamente a loro svantaggio.

Non posso che darti ragione a riguardo. Il tempo di sviluppo è sicuramente maggiore, o almeno lo studio di tale tecnica. Vero è anche che, almeno per quanto riguarda la mia esperienza personale, una volta capito il meccanismo e fatta un pò di pratica la rapidità di sviluppo accresce non di poco.
In realtà la creazione di un CRC che estende modResource di per se non richiede alcuno sforzo, si tratta di replicare la struttura di una modResource dandogli semplicemente una "class_key" differente e realizzando lo schema xml che dichiara tale relazione (2 righe di codice).
A parte questo lo sviluppo delle funzionalità che dovrà avere il sito web esula da tale contesto: che tu affronti le problematiche con o senza le CRC comunque sia le funzioni che elaborano le informazioni devi farle, o dentro uno snippet o dentro una classe, e il maggior tempo sottratto è quello (nulla vieta l'utilizzo di Form Customization all'interno di CRC!!).

Con l'esperienza acquisita durante lo studio e l'utilizzo delle CRC ho anche avuto modo di apprendere approfonditamente molti aspetti di modX e Xpdo, il loro funzionamento interno e le relazioni tra i vari elementi del ORM.

Non ho dubbi che ciò che ti ho elencato nel post precedente possa essere fatto anche con l'uso di plug-in e/o extra (god bless modx!!!), devo però momentaneamente smentire l'uguaglianza che affermi nel tuo post-scritum (e spero mi smentirai nella tua prossima reply ahah):

ps.
"Un resort può contenere al suo interno solo risorse di tipo Camera (vedi figura 1) (filtraggio che non puoi fare se non con le CRC, poiché ti permettono di personalizzare il Resource Tree e le azioni applicabili su di esso)."
quando ho dovuto affrontare questo problema utilizzavo un plug-in all'evento di creazione risorsa che controllava il template della risorsa padre e in base a quella settava il template alla figlia.

Non fa una piega, ma... per quanto riguarda la personalizzazione delle azioni (e quindi delle voci) applicabili ad una risorsa all'interno del Resource Tree? Come ti sei comportato a riguardo? non ne hai mai avuto la necessità?

Per il Content Editor tutto ruota attorno al Resource Tree, si cerca di dare massimo comfort per la sua gestione.
Se dovessi gestire io il sito dell'agenzia probabilmente molte cose non le avrei raffinate.

Ovviamente mi esprimo sempre in relazione alle esigenze (e competenze soprattutto) di coloro che dovranno poi utilizzare il sistema. Può essere forse considerato non "necessario" dover gestire le voci e il menu del Resource Tree, ma cerco sempre di mettermi nei panni del cliente (anche del più incompetente).
In un progetto come quello dell'agenzia viaggi che ho proposto, il mio cliente si perderebbe se le voci dell'albero delle risorse risultassero tutte uguali (anche se poi con un plug-in lo reindirizzo al giusto settaggio della risorsa).
Farebbe fatica, ad esempio, a riconoscere quando creare una camera, o un resort, o un evento, o una crociera, o una cabina, etc etc. Non so se sono riuscito ad esprimere in maniera adeguata il concetto.
Si basa in maniera maggiore sul comfort e sul utilizzo "user-friendly" del back-end. E' forse uno dei principali vantaggi delle CRC (oltre ad interfacciarsi in un ambiente Object Oriented con tutti i vantaggi che ne derivano, funzionalità, portabilità, efficienza, ecc ecc).

Un altro aspetto che non mi convince del tutto riguardo l'uso di TV (o collezioni di TV con MIGX) è la parte relativa ai prezzi (o ad esempio, relativa al programma di un evento, composto da giorno,titolo,img,descrizione).
Sarà anche più complessa la realizzazione, ma la futura gestione di tali informazioni??

Eccoti un esempio a riguardo:
In alcune parti del sito è necessario mostrare il prezzo più basso disponibile in quel periodo. "A partire da 100€ al giorno all-inclusive a persona in camera doppia" oppure "A partire da 200€ weekend B&B in coppia". Come puoi notare da questi due esempi il prezzo è composto da più informazioni (quindi collezione di TV?).
Questa funzione, in sostanza, deve verificare qual'è il prezzo più basso tra tutti i prezzi di tutte le camere di un hotel. Come affronteresti tale filtraggio in uno snippet con le TV?
Con le CRC (con lo sviluppo di metodi delle classi, quindi con una visione totalmente O.O.) riesco agilmente a ricavare ogni tipologia di prezzo.
Mi bastano 2 funzioni (1 per la classe Resort, 1 per la Camera), con cui posso facilmente richiedere al mio hotel di darmi, ad esempio:
- il prezzo più basso di una camera X: $room->getLowestPrice()
- il prezzo più basso dell'hotel: $resort->getLowestPrice() che con un semplice foreach e un confronto di $room->getLowestPrice() mi ritorna il prezzo più basso.
- posso filtrare la tipologia di prezzo che ricerco (il più basso prezzo all-inclusive,il più basso prezzo all'interno di un range di date, il più basso prezzo solo di camere singole, ecc ecc): $room->getLowestPrice($criteria)

Come gestiresti tali richieste?

A parer mio, da questo punto di vista, guadagnano le CRC anche in fase di sviluppo, gestione e organizzazione.
Un altro vantaggio diretto che mi viene in mente è anche l'aspetto che riguarda l'inserimento delle funzionalità del front-end all'interno delle classi e non attraverso snippet; diretta conseguenza è l'assenza di gestione degli snippet nel manager di modx, o l'abuso di TV. Che gli snippet siano statici o no, il numero a volte è fastidioso, soprattutto se devi replicare tale struttura su più contesti o addirittura (come nel mio caso) su più domini con manager differenti.


E ancora, c'è un altro aspetto che sinceramente non saprei come gestire se non con le CRC: gli EVENTI.

Gli eventi sono classi particolari, sono legati ad un resort e come tali, usufruiscono delle camere (e delle loro informazioni, compresi i prezzi) di tali resort. Come affronteresti quindi tale situazione? Replicheresti i valori TV delle Camere negli Eventi? Le camere rimangono Risorse o diventa Collezioni di TV? E i prezzi poi??e se poi uno cambia un valore nel resort deve modificarlo anche nell'evento? Risulterebbe ridondante e inefficiente, puoi smentirmi?
E' come se diverse risorse condividono altre risorse, un pò come dire che la Camera possiede più di una risorsa padre (nella realtà non è così).

E ancora, alla luce di ciò, come ti comporteresti con i prezzi delle camere?

Per ora mi fermo o metto troppa carne al fuoco


Questa conversazione si sta rivelando più utile di quanto pensassi. Spero presto che altre persone ne verranno coinvolte.



Ciao!







[ed. note: solidusite last edited this post 10 years, 6 months ago.]

Mi introduco con un po' di ritardo, ma ti ringrazio per lo spunto sulle CRC,
in effetti anche io ho quasi sempre utilizzato la personalizzazione del form, ma indubbiamente le CRC offrono strumenti notevoli...

Se ti va ti potresti prenotare per una breve introduzione da fare agli altri utenti al prossimo meetup in Italia