getVar Vs getInput

[mau_develop]

Altra stranezza... nelle docs viene deprecata la getVar verso una miglior getInput ... mmhh d'accordo...

poi nell'entry point viene usato, all'interno dei componenti lo mischiano ancora col getVar...

...c'è qualcosa che non afferro?

M.

ps: questo è un bellissimo post che se qualcuno dei saccenti developers si degnasse di rispondere diventerebbe una bella risorsa... sono le domande che si fa chiunque cerchi delle best practices http://forum.joomla.org/viewtopic.php?f=642&t=709375

[skyline81]

Ciao Mau,


non credo di saper dare una risposta corretta al tuo quesito ma credo di essermi fatto un'idea sui due metodi get:


getVar (JRequest)
----------------------
la classe JRequest come riportato ufficialmente nelle docs provvede a fornire un'interfaccia per accedere alle variabili in senso generale


getInput (JForm)
---------------------
la classe JForm nonostante nelle docs non viene fornita alcuna descrizione sembra utilizzabile esplicitamente per i form e quindi - secondo la mia piccola opinione - adatta a maneggiare dati provenienti da richieste utente esplicite.


Quindi il getVar viene utilizzato per per valutare l'entry point del componente (in quanto richiesto dalla struttura di Joomla! e non da un form) mentre il getInput dovrebbe essere utilizzato per valutare e recuperare i dati inseriti dagli utenti nei form.


Potrebbe essere valida come spiegazione?


 

[mau_develop]

Quindi il getVar viene utilizzato per per valutare l'entry point del component
-----------------------------------------------
sicuro?

M.

nel framework: @deprecated 12.1 Get the JInput object from the application instead

[skyline81]

Assolutamente no dopo aver dato un'occhiata a Joomla (sorry)


Avevo fatto un po' di confusione

[simone83]

e la stessa cosa che dicevo io, xche utilizzano ancora getVar se è deprecato, l'unica differenza che avevo notato poi magari ora e stato modificato è che get var ti permette di decidere se prendere i dati dal get o post ecc mentre la classe Jinput prende i dati dalla request

[mau_develop]

...se vanno avanti ancora un po' senza pulire il fw si ritrovano a riscrivere il php...
stessa cosa comunque con gli State .. ce ne sono svariati e ognuno elabora la sua teoria sul corretto uso... ora hanno aggiunto anche lo store temporaneo nella cache...

..mamma mia...

M.

[simone83]

si infatti, stanno andando avanti senza troncare con il passato, a me urta che siamo alla 3.0 con una paltform che ti fa usare il mvc in versione legacy senza sapere di che morte si muore, qui ogni anno tocca rifarsi da capo. Comunque gia che ci siamo hai visto un modo alternativo per fare il set invece che il get ovvero Jrequest::setVar ? io non l'ho trovato

[mau_develop]

$input = JFactory::getApplication()->input;
$input->set('view', 'la_mia_view');
o
JRequest::setVar('view', 'la_mia_view);

M.

[simone83]

Bene questa cosa non l'avevo ancora vista grazie.

[mau_develop]

Cià dai... continuiamo un po' qs post che mi piace....

dopo aver spulciato un po' il codice dei componenti del core sono arrivato a dirmi che:
-Continuano a sfruttare/creare/lasciare retrocompatibilità esclusivamente perchè le estensioni del core sono sostanzialmente quelle della 1.5 al max 1.6... qualche smanacciata per farle funzionare e basta.
- In realtà i miglioramenti che ottiene joomla cms sono solo relativi alle nuove funzionalità, quelle antiche continuano a funzionare con logica antica.
- Si evince chiaramente l'interesse verso la plattform, usando quella per sviluppare sei tu che ti dimentichi di queste logiche antiche e delle scemenze della legacy...
- Credo che la strada che cercherò di percorrere sarà sempre più quella di crearmi un mio core.

M.

[simone83]

si hai ragione, basta vedere anche la generazione delle query alcune sono create utilizzando le funzioni per renderle compatibili con l'ambiente in cui si trovano, altre no. In  questa fase siamo un po in un buco nero

[mau_develop]

a me urta che siamo alla 3.0 con una paltform che ti fa usare il mvc in versione legacy senza sapere di che morte si muore,

avevo un po' sorvolato questa frase poichè già nella 2.5 usano il legacy poichè sta nella plattform 12, e ho continuato a ragionare "2.5"

Ho letto un po' di documentazione della plattform (poca confusa sparsa per github) e diciamo che più o meno ho capito cosa hanno fatto con le classi "base" e all'mvc ( a parte che secondo me così è meno flessibile ..ma lasciamo perdere...), poi volevo vedere come avevano applicato questa cosa nel CMS... ma porca paletta! non c'è un estensione che li usa!
... come giustamente dici... jpippolegacy jplutolegacy ... e te legherei si che te legherei...
...ravani in quelle 4 extensions per j3.0... native -> 0

Sto testando un po' la 3.0 e devo dire che mi piace la nuova grafica... ma il resto cosa è cambiato?
Alla fine l'mvc consente il "trucchetto" di cambiare le skin e di avere qualcosa che sembra nuovo.... sembra!

Cioè il mondo sta testando la 3.0, poi un giorno o l'altro dovranno smetterla con sto legacy e passeranno alle estensioni native....e pensano di farlo senza cadaveri?
Finito di testare la 3.0 uno crede di avere in mano una cosa stabile e questi ti cambiano le estensioni?
Ovvio che poi parlando di plattform tutto questo non vale... quella, una pulita e va che è un gioiello, ma dovrebbero avere almeno il coraggio di dire chiaramente basta col cms... farlo così non ha senso.
... sono veramente perplesso... ma sicuramente se leggeranno queste righe faranno il team anche per le perplessità

M.