stranezza array

[mau_develop]

nel model che fa la lista, all'inizio c'è il preset dei parametri filtrati.... perchè tutti quegli array finiscono con una , (virgola) ?

M.

[simone83]

dove in $config['filter_fields'] ?

Bella domanda, se è li penso che sia una convenzione loro xche funziona benissimo anche senza una virgola in fondo

[mau_develop]

dove in $config['filter_fields'] ?
----------------------------------------
yess

mmhh sì ma un array con la virgola in fondo da errore o viene letto un indice in più?
... mo guardo...

ieri ho perso una giornata per la pluralizzazione... di default finiva nell'edit, ...poi ho scoperto nel modo legacy come si fa... bisogna dichiarare la default_view, non basta prenderla dalla input o request

M.

[simone83]

mmhh sì ma un array con la virgola in fondo da errore o viene letto un indice in più?

Non lo aggiunge, è solo una convenzione per facilitare l'inserimento di ulteriori celle future.

ieri ho perso una giornata per la pluralizzazione... di default finiva nell'edit, ...poi ho scoperto nel modo legacy come si fa... bisogna dichiarare la default_view, non basta prenderla dalla input o request

Non ti seguo che volevi fare ?

[mau_develop]

usare il legacy.
Nel controller principale del componente, se non dichiaro il default:

protected $default_view='pippos';

quando clicco il menù, non passando nessuna view, dovrebbe automaticamente usare il default ... set view (get view, default)
..eccco quest'ultimo nn mi funziona con il legacy, semplicemenete devo dichiarare la var di cui sopra.

... poi magari sbaglio io qualcosa ma ho controllato infinite volte e debuggato...
M.

[simone83]

Stai parlando di joomla 3? nella 2.5 la default view è uguale al nome del controller principale se non diversamente specificato.

[mau_develop]

no, nella 2.5 usando il legacy.
mi sta venendo il dubbio sulla pluralizzazione...
se ho un Y finale posso pluralizzare sia con IES che con YS ... giusto?

M.

[simone83]

Se devo essere sincero non mi sono mai interessato a questa cosa, non saprei che dirti

[mau_develop]

secondo me è un problema antico che c'era sulla 1.6 e me ne ero scordato... nn ricordo nemmeno bene il "meccanismo" che dava errore... cmq dovrebbe essere una cosa tipo questa che viene mal interpretata:

stavo facendo un componente admin per un cliente che necessita di gestire delle policy di visita al sito in base a un certo profilo
il componente si chiama policy, com_policy , le views sono policy e policys

per joomla, policy, è plurale! ... non andrai mai su policys con il default e nemmeno con policies

... non chiedermi perchè ... non ho voglia ... devo finire ma sono già alla fine io...

[mau_develop]

simone, prova a guardare una cosa.... magari è una scemenza ma anche cambiando il nome dell'estensione ho sempre lo stesso problema. La cosa in comune è che uso per l'estensione il nome singolare... un po come se com_hellos tu lo chiamassi com_hello, usando comunque le views hello ed hellos per l'editing e il listing.

Ho visto un'altra cosa osservando i main controller, quelli nella root dei componenti controller.php, delle estensioni del core joomla.:
com_weblinks -> plurale -> nel controller non ha nulla
com_contact -> singolare -> nel controller ha la $default_view
com_content che ha le views diverse, article e articles , ha bisogno anche lei della $default_view
con_banners -> plurale -> non ha nulla

...sarà una coincidenza, sarà che è documentata da pena, che non ho capito na cippa, che non ho voglia di andarmi a leggere il framework....

M.

[simone83]

Sai com'e anche i componenti nativi non sono sviluppati tutti dalla stessa persona quindi uno lo puo mettere  e un'altro no. comunque io non ho mai riscontrato questo problema.

Ad esempio sto creando uno showroom virtuale che si chiama com showroom nell'amministrazione nel controller principale imposta la default view nella funzione display con

$view = JFactory::getApplication()->input->getCmd('view', 'exhibitors');
JFactory::getApplication()->input->set('view', $view);

e non uso ad esempio showrooms che visualizzazione di default

poi nei singoli controller di editing imposto la view delle liste che li contengono.

Forse non stiamo parlando della stessa cosa 

[mau_develop]

esatto ma se vedi qs: JFactory::getApplication()->input->set('view', $view);

non esiste più

M.

[simone83]

Ok la default view la puoi impostare o dal costrutture della classe JController
riga 427

// Set the default view.
if (array_key_exists('default_view', $config))
{
           $this->default_view = $config['default_view'];
}
   elseif (empty($this->default_view))
{
            $this->default_view = $this->getName();
}

quindi mettendo nell'array config la default view oppure ti prende il nome del controller

oppure riscrivendo la funzione display come nel post prima

non so se mi sbaglio

[mau_develop]

ah ok... nella config... nn ci avevo pensato.. cmq ci vuole da qualche parte, il set non va bene con il legacy... sei d'accordo?

M.

[simone83]

si certo, guardando la direzione con cui sono create le estensioni la strada giusta e quella di non utilizzarlo ed impostare la default_view nell'altro modo.

Comunque e chiaro che funziona anche nell'altro modo xche il controller prende la view dal parametro nell'url e se lo imposti non ci sono problemi.

[mau_develop]

Comunque e chiaro che funziona anche nell'altro modo xche il controller prende la view dal parametro nell'url
--------------------------------------------------------------------
si senza il legacy si.
Infatti se guardi come è sviluppato com_weblinks e guardi com_hellos del tutorial (sempre per 2.5 ovviamente) sono diversi.
In tutti i componenti della 2.5 è già presente il legacy ...a qs punto credo siano compatibili anche con la 3.0
... magari ho scoperto l'acqua calda o dico qualche scemenza... ma è in pratica la prima estensione che sto facendo guardando alla compatibilità futura

M.

[simone83]

si il legacy della 3.0 penso che non sia altro che la struttura attuale del MVC della 2.5 proticamente ti fanno usare l'interfaccia legacy nella 2.5 per far si che funzioni anche nella 3, almeno ti rendono possibile di sviluppare estensioni multipiattaforma

[mau_develop]

..guarda mi sono letto un po' di roba ma devo ancora focalizzare i concetti...
dovrebbe essere cambiato anche l'mvc nel senso che ora il riferimento dovrebbe essere il controller e nn più la view... ma cosa voglia dire esattamente lo sto capendo a testate

M.

[simone83]

secondo me è un problema antico che c'era sulla 1.6 e me ne ero scordato... nn ricordo nemmeno bene il "meccanismo" che dava errore... cmq dovrebbe essere una cosa tipo questa che viene mal interpretata:

stavo facendo un componente admin per un cliente che necessita di gestire delle policy di visita al sito in base a un certo profilo
il componente si chiama policy, com_policy , le views sono policy e policys

per joomla, policy, è plurale! ... non andrai mai su policys con il default e nemmeno con policies

... non chiedermi perchè ... non ho voglia ... devo finire ma sono già alla fine io...

Mi sono inbattuto a caso in questa cosa, non so se ti interessa ancora, la pluralizzazione si trova nel controllerForm riga 113 dove tenta di indovinare qual'è la view della lista con quella serie di match, ma solo se non è stata settata la view_list nel cstruttore del controllerForm della tua classe

[mau_develop]

si grazie l'avevo vista ... il problema è che secondo me quel dato si perde da qualche parte col legacy.... o faccio qualche somarata senza pari... ma senza quella dichiarazione nel costruttore, qualsiasi sia il naming, si infila nel form.

Sono arrivato a delirare pensando vi sia qualche patch nel codice del fw per far funzionare i componenti core col legacy... ho duplicato il com_weblinks, ho cambiato il naming pippo/pippos ... e mi da lo stesso problema... o comunque ricado nello stesso errore...

... mistero, sono quelle cose che un giorno quando nn ti serviranno più, capirai....
adesso sto sbattendo la testa su un altra cosa da mal di testa ... l'aggiunta di gruppi di campi dinamicamente

[simone83]

A volte succede come quando ebbi la brillante idea di chiamare una view model e dopo col cavolo che funzionava il tutto. Interessante la cosa che stai facendo ci credo che sia da mal di testa 

[mau_develop]

in pratica devo fare una cosa simile a qs:
https://www.nemgtr.org/index.php?option=com_content&view=article&id=244:online-membership-application&catid=39
lo vedi in seconda pag quando selezioni i check box
spiega anche il js su joomla.org ma nn ho capito na cippa

usando jquery form va in conflitto qualcosa e funziona malissimo, causa un sacco di malfunzionamenti sul resto..
poi io con js sono una capra...

EDIT ..si però anche qs ha il trucco... infatti mi chiedevo il perchè scegliere prima quanti e poi compariva il fieldset.. perchè genera da subito il max dei fielset poi li nasconde
for(i=0;i<4;i++)
      for(j=1;j<=7;j++)
         document.getElementById('c'+(i+1)+'h'+j).style.display = 'none';

e non è proprio quello che volevo io... cmq ho capito che lo fa rsform

ARI-EDIT.... Joomla mi ha fottuto ancora... trovato l'inghippo... non caricavo Jquery ... ma che carica joomla?

vedevo questo tra gli headers e non mi ero fatto troppe domande
/media/jui/js/jquery.min.js" type="text/javascript"></script>

ma se non carico il latest da google non va na cippa, caricando jquery è uno spettacolo ... persino banale

[simone83]

Io lo farei in ajax dove tu invii al controller lo stato attuale della form e dopo ti generi i campi e li restituisci alla chiamata, però son sicuro che verrebbe una cosa molto lunga ma ti risparmieresti il rompimento di generare i campi in javascript

[mau_develop]

...allora, riprendo in mano sta cosa ... vediamo un po'..

ci sono varie strade percorribili, il risultato deve essere la definizione di Pippo in una serializzazione, ovvero Pippo è un campo ma è anche un gruppo di field che lo popolano.
I fields saranno parte del gruppo in quanto array... es: $pippo[titolo] , $pippo[forma] , $pippo[colore] che quindi andranno a creare l'array $pippo e di conseguenza la serie $pippo che popolerà il campo pippo del db.

...un po' confuso forse ma credo di essermi riuscito a far capire, forse ho sbagliato a scegliere il nome pippo... in realtà consideratelo l'oggetto pippo e non l'individuo pippo.

Il poblema è che in inserimento voglio poter creare una o tante definizioni di pippo, quindi sarei costretto a fare una serie di gruppi campi identici: $pippo[titolo][], $pippo[forma][] , $pippo[colore][] ... oppure posso aggiungerli dinamicamente all'occorrenza.

E questo è, riassumendo, lo stato attuale del ragionamento. Funzionare, funziona.. ma qual'è la strada più corretta anche se scomoda?

Come è adesso, prendo il field tipo textarea non visualizzando in realtà quel field ma prendendone la definizione nel template e trasformandolo nei miei campi sopra descritti.
...oppure...
posso creare un tipo di field custom es type="pippo_group" e creo i campi da restituire come input

la gestione dell'array sarebbe poi demandata al check in inserimento e in estrazione dal bind al form

con ajax e quindi passando dal controller forse sarebbe meglio iniettare elements...

...idee?

[simone83]

Io uso l'approccio della textarea nascosta e popolata dai n campi in json, penso sia quello l'approccio giusto, non pesno che generare in un unico field n campi sia corretto.

[mau_develop]

... sai il problema della pluralizzazione di cui parlavamo da qualche parte?... ho capito quando devo specificare $default_view

Succede perchè supponiamo che io costruisca un componente com_aziende con i rispettivi azienda e aziendas
Nel menù admin il collegamento sarà com_aziende... il problema è che nel suo controller automatizza la pluralizzazione:
il componente si chiama aziende e lui cerca quella vista.
Il get input nel mio main controller non usa il default perchè trova un valore: aziende

cioè se il mio componente si fosse chiamato com_aziendas non avrei avuto problemi di specificarlo

... risulta?

[simone83]

Certo xche la convenzione del plurale è solo per i nomi in inglese se ne sbattono dell'italiano che non definisce i plurali in quel modo

[mau_develop]

no è che mi aspettavo che la view non venisse valorizzata così da accettare il mio default nel controller principale, invece anche se non parte dalla get cliccando sul menù viene comunque valorizzata secondo il suo default da Jcontroller ... è questo che mi fa specie... cosa caspita mi serve allora quel default get input(view, 'pippo') ?

[mau_develop]

..simone... a che serve sta roba? ..

com_weblinks/views/weblink/tmpl/edit

alla riga 23 circa c'è qs <?php echo $this->form->getField('description')->save(); ?>

[simone83]

Quella riga ti crea un comando in javascript, diversa a seconda dell'editor, che ti sposta quello che scrivi nell'editor nella textarea nascosta del campo description, lascia perdere che lo esegue anche quando premi chiudi, senno gli toccava fare un elseif in piu 

[mau_develop]

mamma mia! ... vero... non l'avrei mai capito! grazie ... e si che ho il suo libro dove questo componente lo disseziona...

[simone83]

di nulla 

[mau_develop]

quindi la finestra dell'editor che vedo non è un field text abilmente trasformato da js .. è proprio un box a parte..

[simone83]

si è un iframe nel tinymce

[mau_develop]

...un'altra cosuccia simpatica... publish() (che si trova in weblinks/table e in altri componenti)

ma se io scrivo qualcosa col principio della riusabilità, perchè poi nel mio metodo faccio così?

Codice: [Seleziona]

// Update the publishing state for rows with the given primary keys.
        $this->_db->setQuery(
                'UPDATE '.$this->_db->quoteName($this->_tbl) .
                ' SET '.$this->_db->quoteName('state').' = '.(int) $state .
                ' WHERE ('.$where.')' .
                $checkin
            );

se quello "state" era un parametro mica vero che la potevi usare per 100 pulsanti di stato nella stessa tabella?

[simone83]

vero, cosinderando il fatto che qualche volta invece di state c'e published, non ci voleva molto a  fare quello che dici tu dichiarando nella classe Jtable ad esempio una variabile $_stateField = 'state' e magari uno nella sua classe che la estende se la imposta come vuole

[mau_develop]

qualche volta invece di state c'e published
-----------------------------------------------------------
..perchè hanno fatto un vero sforzo nell'aggiornare i componenti ... trovi anche campi non più usati....

[simone83]

penso che per il momento si stiano concentrando sulla plattform poi dopo aggiornranno i componenti, nell'ottica tanto che li aggiorno a fare funzionano uguale

[mau_develop]

"per il momento si stiano concentrando sulla plattform"
--------------------------------------
credo che si siano rotti le scatole da tempo dei componenti e da un bel po' il focus è la plattform ma non credo ci mettano mano... forse il senso di mantenere dei legacy è solo quello.
Se la 3.5 non ha sconvolgimenti di codice, tutti i componenti sono già 3.5 ready