[RISOLTO] metodo publish()

[steganoga]

[EDIT] risposta al quesito senza che leggiate un tedioso botta e risposta

Come giustamente diceva Marco tutto è gestito correttamente da Joomla ma...

Joomla si aspetta di trovare un field del database che si chiama "published" e non "state". Per motivi che solo loro sanno, chi ha scritto le estensioni del core (quelle presenti da sempre) ha trovato alchimie per continuare ad usare il field state e sfruttare ugualmente le funzionalità del grid senza appunto costruirsi un elemento che avrebbero dovuto gestire.

Per facilitare le cose mi pare di aver capito che published supportava solo lo stato published e unpublished, utile al core (una estensione non la archivi) ma ai contenuti poco, così sono partiti i mixaggi di soluzioni

il modo corretto è di dimenticare lo "state" e di usare "published" e normalmente il grid

[/ END EDIT]

ho notato che il metodo publish fa questa query:

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
                        );

quindi immagino non ci siano successive "azioni" sul database e verificando mi sembra sia proprio così.

Ma io sto modificando una parte importante del mio contenuto, il suo stato... e perchè non aggiorna chi e quando ha fatto questa cosa?

Siccome le estensioni all'interno del core sono tutti cloni credo che questa cosa si rifletta un po' su tutto.

sbaglio qualcosa?

[mmleoni]

eh? publish de che?

[steganoga]

JTable

quel bottoncino che clicchi e pubblichi e clicchi e spubblichi

[mmleoni]

sicuro? joomla usa i metodi di jdatabasequery per le queries in jtable e non concatenazioni di testo.

quindi, quel metodo publish, dove si trova?

[steganoga]

vero, sono stato un po' frettoloso, in realtà è solo in com_weblinks candidato alla rimozione e in un paio di com_.. commerciali che ho installato.

sta nell'estensione di JTable, adesso verifico se e cosa serve visto che dalla documentazione sembra una classe della 1.0

[EDIT] Capito.
Tentavo di capire dall'estensione sbagliata.

riassumendo il publish unpublish etc è gestito da JGrid, però se voglio un mio publish posso farlo
non capisco perchè in quel componente è fatto nella table
e non capisco quanto detto sopra, perchè visto che è un azione di edit non aggiorni la modifica.
Non credo che quel metodo publish abbia un parent.

[steganoga]

comunque anche com_banners lo fa nell' estensione di JTable e credo di averne capito il senso...

Credo che ognuno abbia fatto un po a fatti suoi così nel com_contact trovi sia lo stato che un campo published ... e uno si chiede ma chissà perchè?
perchè se non ti fai un elemento grid custom, quello che usa il content fa questo
SET published = 0 WHERE (checked_out = 0 OR checked_out =
e ovviamente se non hai il campo ti da errore probabilmente perchè necessita un associazione e la gestione delle azioni

o sbaglio ancora?

[mmleoni]

secondo me si tratta di vecchio codice rimasto lì in componenti che non hanno più alcuna utilità...

se verifichi i metodi publish nei controller e nei model (JxxxAdmin) ti accorgerai che per quello che fanno quei due componenti non vi è alcun motivo di un override del codice: è sufficiente che nella tabella tu metta i fields richiesti dal framework ed il tutto è gestito da joomla, con i diversi livelli di publish (pubblish, unpublish, trash, archive) e i corretti livelli di autorizzazione.

jhtml('grid.publish[ed]') semplifica solo il lavoro dei checkboxes e l'azione la metti con le funzioni di menù, ma tutto è poi gestito da controller>model>table.

ne conosco un altro che parte sempre da com_weblinks, non sono ancora riuscito a fargli capire che non è un'idea geniale... :lol:


ciao 

[steganoga]

ne conosco un altro che parte sempre da com_weblinks, non sono ancora riuscito a fargli capire che non è un'idea geniale... :lol:

lo conosco anch'io è uno che ha la propensione al masochismo perchè dal dolore impara sempre qualcosa

consiglia al tipo di non partire nemmeno dal com_banners perchè è la stessa cosa

E' bello leggere le notizie che si trovano a mangiare la pizza gli sviluppatori, magari si potrebbero portare con loro i "tirapiedi" che scrivono poi il cms così che almeno ciò che fanno sia didattico e non diseducativo; altrimenti la piantino di rilasciare il cms e ci si adatterà a partire dal framework.

..dimenticavo, grazie per la pazienza e prometto che il prox parto dal tuo builder

invece a tutti quelli che hanno letto questo post e ora hanno il mal di testa riaasumo qual'è il problema/non problema:

com_weblinks ha la pretesa di gestire uno stato in aggiunta che non riuscirebbe a gestire se non facendo un elemento grid completamente nuovo e completamente da gestire nell'mvc sia codice che grafica (html)
Si vede che non ne aveva voglia e ha smanacciato la table inserendo la sua modifica che si sovrappone alla normale gestione dello stato