Monitoraggio e tracking

[Giuseppe72]

Ciao Giovi, sto inserendo i codici...qui fila tutto liscio
Se mi permetti lancio una dritta. (sempre che non mi bacchetti  )
Sarebbe bello che il tuo componente si associasse ad un modulo.
Mentre scrivevo una pagina dove spiegavo le procedure dell'acquisto, a metà pagina ho dovuto dare il link: clicca qui per verificare il tuo codice.  Sarebbe bello che il tuo componente diventasse anche un modulo, cosi' anzichè dare un link che riporti al componente , si potrebbe mettere direttamente nell'articolo con il loadposition , cosi' la pagina dell'articolo avrebbe il suo tocco professionale.
Cmq , è solo una mia opinione.
Poi ho visto che quando salvo un nuovo codice , non c'è il "Salva e nuovo" ma solo salva.
Naturalmente quello che dico è solo per dare un miglioramento al componente, a me va bene anche cosi' , anzi...non finirò mai di ringraziarti.
Ciao 

[giovi]

Grazie per questi consigli, ne terrò sicuramente conto nelle prossime versioni. Vorrei solo informarti che forse può esserti utile la variabile $introtext (nei parametri del componente mi pare sia "testo di introduzione") in cui potresti incollare il testo che ora è salvato sotto forma di articolo: in questo modo otterresti il componente come se fosse all'interno dell'articolo stesso!
L'escamotage non vale però se intendi inserire del testo anche dopo il form di ricerca.

[Giuseppe72]

è si, la pagina che ho creato ha caratteri diversi e immagini.
Vabbè magari se fai il modulo lo inserirò più in là.
Buon lavoro.

[giuseppecalo85]

Giovi...
Sei uno spettacolo... è il componente che cercavo da anni....
mi viene da piangere....


adesso ho solo un problema... non è compatibile con J1.5!!


sarebbe una cosa complicata per renderlo compatibile??


grazie in anticipo
e ancora complimenti


Giuseppe

[giovi]

ti ringrazio giuseppe per l'apprezzamento,
ma sarò sincero: probablimente non sarà difficile, ma lo è per un ignorante come me che da poco ha scoperto come si crea un componente per joomla!!! Anzi se non fosse stato per mau_develop e per le informazioni che joomla.org (ed altri siti) mette a disposizione degli sviluppatori a quest'ora starei ancora cercando di capire perchè il "controller" non si può attaccare alla playstation! 
La licenza con cui il componente è rilasciato è la gpl2 quindi chiunque di buona volontà può farsi carico di "dis-aggiornare" il componente adattandolo alle api della 1.5 senza troppi problemi


Come mai non vai ancora d'accordo con la 2.5? (anche se qui usciamo un pò dal tema principale della discussione)

[giuseppecalo85]

grazie della risposta,
tu ti definisci ignorante, ed hai creato un componente...
io invece che mi limito ad usarli che sarei??


comunque non è che non vado d'accordo con la 2.5, ma ho già un sito funzionante con la 1.5
e siccome mi è costato tanto lavoro, ora non mi va di sbattermi ancora facendo la migrazione.


ma se non c'è nessuno che mi darà una mano, credo che sarà l'unica strada...


ciao Giuseppe

[giuseppecalo85]

ragazzi,
chi mo da una mano per questa impresa??? (per me)


rendere compatibile questo spettacolare componente per j1.5??

[Aikanaro]

Ciao Giovi, intanto grazie perché esisti e sopra tutto perché hai creato questo componente fantastico che mi viene veramente utile per il sito.


Dunque in due parole ho da farti alcune richieste per un eventuale upgrade del componente. Gestendo un'azienda di trasporti questo componente mi viene molto comodo, ora il modulo di inserimento dei codici attualmente è in backend, il che implica il dover dare i dati di accesso amministratore ad un utente per inserirli, mi chiedevo se era possibile aggiungere anche un modulo inserimento codici frontend da assegnare con accesso ristretto solo ad alcuni utenti.


Seconda cosa aggiungerei come ulteriore campo nel modulo di inserimento codici anche la possibilità di caricare un'eventuale immagine per esempio della lettera di vettura del pacco firmata alla consegna, o ancorameglio un campo per uplodarla e nel modulo di ricerca frontend un pulsante per scaricarla accanto al risultato della ricerca.


Questi due cosette a mio avviso renderebbero il componente più professionale.


Grazie.

[giovi]

L'organizzazione no-profit Open Source Matters, proprietaria del marchio registrato "Joomla!", ha finalmente approvato l'estensione JTracking concedendo (in poche parole) l'utilizzo della J (che sta per il nostro amato Joomla!) all'interno del nome del componente.


Per l'occasione ho rilasciato un aggiornamento alla 1.4.1 (ossia la ver. 1.5) che contiene per la prima volta i file di lingua del compoente che potrà quindi essere tradotto in altre lingue (che stia cominciando a montarmi troppo la testa??! Ma no! Volevo solo semplificarvi un'eventuale modifica delle parti testuali del componente!)


A presto per i prossimi aggiornamenti: continuate con le vostre segnalazioni!

[Giuseppe72]

Siii siiiiii, montati pure la testa e facci altri capolavori come Jtracking.
10+10+10+10+10+10+

[mau_develop]

Gioviiii ...ciao Giovi mi sembra di essere Crozza prima dello show a Ballarò

... mi fai venire il mal di cuore con i tuoi annunci.... vediamo di sistemare un po'... prima f/end...
------- riga 20 del model
$this->searchterm =  JRequest::getVar('code','','POST');

nì... manca il casting! Se non puoi determinare cos'è devi fare anche qui' un filtro altrimenti passano i +UNION+SELECT o similari

---------- sempre nel model, nn sono propriamente errori, ... diciamo ridondanze
tutto quel "giro" di $this->information.... che serve?

if (!isset($this->information)) ... perchè dovrebbe esistere? dove viene creato qs oggetto se non nella query?

Perchè deve esistere? basta che la funzione.. pardon metodo ritorni $db->loadObjectList();
o è vuoto o è in errore o hai la tua information...senza creare un oggetto $this per poi proteggerlo.

lo stesso search sopra... la getVar già ti ritorna un default se fallisce e non può esistere già

secondo me in 10 righe fai tutto.

poi....

anche nella view ci sono cose simili, quando crei una variabile runtime (credo sia il caso di $open) se "muore all'interno del metodo" non ha senso aggiungerla al $this a meno che poi tu non debba usarla in altri metodi della classe o serva per sovrascrivere qualche oggetto appartenente alla superclasse.

tutto ciò che nel display aggiungi a $this si serve unicamente per averlo nel template.

poi io sono un maniaco del controller... tante cose preferisco farle lì senza andare a farle nella view, dove per la logica di joomla devono arrivare dei dati e non essere "gestiti" se non per le necessità del template.... ma non è sbagliato comunque come hai fatto

M.

EDIT ... sorry... mi sono accorto ora che ti serve il $this->open..perchè la usi nel template ma vale comunque per le altre...openingtime.. closingtime..

A RIEDIT...bisogna che rivediamo la logica... le regex vanno nel model...

cioè, puoi fare a meno del controller perchè per default alla tua view viene associato il model con il medesimo nome ma a questo punto è il model che deve fare un po' da controller per capire che dati dare alla view e non far fare alla view questa cosa.
La view a seconda di cosa gli arriverà switcherà il template o il suo codice, nel tuo caso basta la seconda.
se gli arriva l'errore decidi che fare, se gli arriva il dato lo fa vedere altrimenti se il dato non esiste mostrare il form se esiste ed è vuoto mostrare form e il messaggio che vuoi

[giovi]

------- riga 20 del model
$this->searchterm =  JRequest::getVar('code','','POST');

nì... manca il casting! Se non puoi determinare cos'è devi fare anche qui' un filtro altrimenti passano i +UNION+SELECT o similari
-----------------------------------------------------------------------------------------
Oh ragazzi, siam pazzi??
Pensi che qui un filtro STRING sia sufficiente?





---------- sempre nel model, nn sono propriamente errori, ... diciamo ridondanze
tutto quel "giro" di $this->information.... che serve?

if (!isset($this->information)) ... perchè dovrebbe esistere? dove viene creato qs oggetto se non nella query?
-----------------------------------------------------------------------------------------
Detto-fatto: cancellato. E grazie per la spiegazione!

Per questa sera mi fermo qui, domani approfondisco il resto! Grazie come sempre per la "consulenza"!

[mau_develop]

Giovi, dobbiamo trovare un'attimino per vedere bene la logica... nn ti spaventare perchè ci vogliono 10 minuti a sistemare... ma è necessario visto che qualcuno incomincia ad usarla e magari a metterla su server pubblici.
Praticamente bisogna decidere se usare il controller o lasciare com'è e usare solo il model ma tutto quel casino dalla view va tolto.

E' vero che è oop però esiste ugualmente una "sequenzialità" .
Ogni click che fai ogni dato che spedisci etc il giro del tuo componente è sempre lo stesso

entry point ->controller->view associata al model->template

Ora Joomla con la 1.6 si è creata delle comodità, il modelitem, l'aminform, il modellist etc... ma non è che puoi sempre semplificare o che sempre convenga farlo.
Inoltre odio quel cavolo di helloworld per la 2.5 perchè sembra che quel modo di sviluppare l'mvc sostituisca quello usato nella 1.5 ma non è vero nulla.
Il procedimento corretto è quello della 1.5 che può essere agevolato dalle nuove classi introdotte che però limitano molto quando voi fare "tante cose" in un componente solo.
Amy sostiene che quando senti il bisogno di fare tante cose in un componente vale la pena di ragionare se tu non abbia invece bisogno di tanti componenti che facciano cose semplici.... non so, a volte è così a volte no...

Vabbè comunque tornando al nostro JTracking...
Forse un buon compromesso sarebbe prendere spunto da com_contact anche perchè l'altra obbiezione che ti avrei sollevato è quella del token, direi obbligatorio se non vuoi che quel form possa essere usato "cross site".

A me piacerebbe partecipasse a questo 3d anche qualcun'altro che sviluppa, è bello e impari molto confrontando le opinioni e ho molto da imparare anch'io, anche se è un componente semplice può diventare un ottimo riferimento per lo sviluppo leggere qs righe, in fondo sono i ragionamenti che ti fai mentre scrivi codice che spesso ti fanno fare e disfare


Pensi che qui un filtro STRING sia sufficiente?
---------------------------------------------------------------
io insisterei con le regex altrimenti specializzerei direttamente il filter() di php, che poi gira e rigira è quello che fa questo metodo...

M.

[giovi]

Quale componente posso analizzare per attenermi il più possibile al tuo punto di vista?
Sto guardando il com_search perchè sembra quello più simile a jtracking ma ho notato che in default.php della view fa questa cosa:

Codice: [Seleziona]

<?php if ($this->error==null && count($this->results) > 0) :
echo $this->loadTemplate('results');
else :
echo $this->loadTemplate('error');
endif; ?>
E' ancora corretto ragionare così?

Quali sono invece le operazioni da spostare nel controller? E' molto difficile riadattarle o posso buttarci dentro gli stessi metodi che ora sono nella view?

edit: sto sbirciando il com_contact, ma mi demoralizzo un po a leggere tutto quel codice senza una spiegazione passo-passo

[mau_develop]

direi di si.
Anche perchè non so (devo guardare) se poteva fare la stessa cosa nel controller, con le classi che ha usato.

L'importante è non andare ad elaborare codice nella view se non per ciò che interessa il template, in quel caso ha fatto solo uno switch.
Il "mio punto di vista" come tu dici (oltre a contare veramente poco) è che non devo accorgermi di un errore quando ho già associato model e view, semplicemente questo.
Poi cmq puoi fare di tutto che non è per forza sbagliato è che ti accorgi che se rendi molto lineari le cose anche a costo di qualche file o metodo in + è difficile che scappi qualche controllo.

..io stavo guardando il com_contact... ma va bene anche quello, anzi forse è meglio perchè prevede un ritorno di dati.

M.

[giovi]

Ok, ho aggiunto anche il token!


Scherzi? Le tue info sono preziose quanto vitali e per il componente e per chiunque voglia cominciare a svilupparne uno! Tutte queste cose non sono mica state dette nella guida allo sviluppo...

Torno però a chiederti se non sia sufficiente fare il controllo delle regex prima di inviare la query piuttosto che nel get della variabile contenente il termine di ricerca! perchè se io prendo una stringa qualunque ma prima di inviarla al model la analizzo ed eventualmente restituisco l'errore, non sono già abbastanza protetto?

edit: la guida che ho seguito per inserire il token è questa: http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms

[giovi]

cioè, puoi fare a meno del controller perchè per default alla tua view viene associato il model con il medesimo nome ma a questo punto è il model che deve fare un po' da controller per capire che dati dare alla view e non far fare alla view questa cosa.

userei il controller veramente volentieri se non temessi la sintassi :S
Posso adottare questo accorgimento di usare il model come controller (temporaneamente) anche per tutti i vari casi (aperto chiuso-ricerca non valida, ecc..)?

[mau_develop]

si, scusa... è che il post di ieri era un po' convulso...

dove conviene fare quel controllo dipende da come vuoi gestire il tuo componente:
- se usi il controller è lì che andrebbe fatto, col redirect in caso di errore, se complichi un po' le cose puoi anche fare diversi messaggi per il redirect, puoi accorgerti se hanno inserito un carattere speciale e restituire il msg "non puoi inserire caratteri speciali... questo lo puoi fare con le funzioni stringhe di php es. strpos()

- oppure può essere gestito nel model, fai la query solo se arriva è ciò che ti aspetti (può ugualmente essere inserito un messaggio di errore.

Prova magari a fare un disegnino a penna su un foglio per abbozzare una logica... quì faccio questo ... sono molto comode le mind map dove hai una visione di insieme del componente ... invece della carta usi il pc

... stavo postando ho visto che hai aggiunto un msg, continuo quì...

perchè paura del codice? guarda che è molto più semplice poichè devi fare tutto ciò che il framework fa per default, non vedi e non capisci.
Nelle guide dovrebbe esserci in italiano quella dello sviluppo F/End di un componente per la 1.5... tranne l'xml va benissimo tutto..

praticamente la differenza grossa è sto cavolo di proxi per il model se nella 1.5 non avevi il display nel controller non avevi ne model ne view, non associava per default quelle con lo stesso nome evitandoti il getModel setview etc.

in pratica cosa succede... quando invii qualcosa esegui più o meno implicitamente una task e la task la "intercetta" il controller se la task è una di quelle già gestite dalla classe controller e tu non la sovrascrivi lui si infila nel default.

Quando ad esempio in admin clicchi su modifica stai eseguendo una task che però nel controller non trovi, perchè se hai seguito il CRUD di joomla sa già cosa fare di quella richiesta... ma tu potresti volergli far fare altro quindi aggiungi nel tuo controller (...extend JController) il tuo edit() che sovrascriverà quello della superclasse JController.

Ma ho paura di crearti casini in testa... non ho una gran proprietà di linguaggio

M.

[lig52]

Cè una versione per jommla 1.5
ciao

[giovi]

no