Overload JTable check()

[mau_develop]

in realtà non so nemmeno se sia giusto chiamarlo overload piuttosto che override... cmq.

quando eseguo store() da frontend, la table usata nel model è quella del lato admin... normale.

in quella tabella non c'è nessun override, usa i parent di tutti i metodi e basta

Frontend dovrei fare l'override di check() perchè alcuni dati vanni forzati ad essere in un certo modo... ma solo nel frontend.

Ora... il modo banale è fare la sua tabella frontend e usare il check come più mi pare...

... e cercando di usare invece la stessa table come si potrebbe fare?

M.

[mau_develop]

..pastiglie... pastiglie... scatole di pastiglie...

prendiamo ad esempio due componenti admin: com_menues e com_messages...

nelle viste form, quindi menu e message quando deve fare il check dei dati, in uno li fa nel controller. nell'altro usa il check() di JTable...
... esiste un perchè?
io di istinto prediligerei il controller ma giustamente se c'è un check() sarà più corretto usare quello.

M.

[simone83]

mi sbilancio xche non lo sto provando direttamente ma se vuoi usare il check della jtable nel frontend puoi controllare come fanno i plugin se sei nel frontend o nell'aministrazione con

$app = JFactory::getApplication();

     
if ($app->isAdmin()) {
            return true;
}

il tuo quesito e giusto il check nel controller serve  avalidare la form e che i dati siano conformi alle specifiche dell'xml invece il check nella tabella ha un'altro significato e lo devi usare per validare altre regole ad esempio che ne so controllare che una data sia maggiore di un'altra come fa il com content oppure altre operazioni del db, certo lo puoi fare anche nel controller questi controlli ma e solo un metodo di programmazione e son sicuro che ne sai piu di me. 

[mau_develop]

[/b]il tuo quesito e giusto il check nel controller serve  avalidare la form e che i dati siano conformi alle specifiche dell'xml invece il check nella tabella ha un'altro significato e lo devi usare per validare altre regole ad esempio che ne so controllare che una data sia maggiore di un'altra come fa il com content oppure altre operazioni del db, certo lo puoi fare anche nel controller questi controlli ma e solo un metodo di programmazione e son sicuro che ne sai piu di me. 

ti ringrazio,
più che altro mi serviva un confronto per vedere se sto andando per campi o meno.
Mi ero accorto della finezza di checquindi diciamo che è la "porta" decare la validità nel controller e demandare al check() di JTable controlli minoritari solo che mi sono fatto qs ragionamento:
- E' più corretto il controller perchè è l'entry point della task, i dati vengono dal form direttamente, se lo fai nella Table quei dati sono già diventati proprietà di oggetto.
- Si, ma se io faccio un form è perchè quei campi finiscono nel db; che senso ha fare un check di validità di una data nel controller per poi, chessò, vedere nel check() di JTable se è una data futura anzichè passata.... lo faccio direttamente li.
Però c'è un problema.... che in realtà bisognerebbe poi passare i dati al model  comunque sviluppare degli override del crud...

Mi sono infilato quì perchè sto sviluppando un ticket system con la prerogativa di integrarsi completamente al core, ovvero non fare nulla che lui già fa e non aggiungere nulla che lui già possiede... es. gli users si gestiscono dagli users di joomla, hanno una loro visualizzazione dedicata ma non una tabella del db...

M.

[simone83]

il punto è che tu puoi inserire i dati anche senza utilizzare una form istanziando un oggetto JTable e facendoci un bind con un oggetto creato a "mano".

 

E' più corretto il controller perchè è l'entry point della task, i dati vengono dal form direttamente, se lo fai nella Table quei dati sono già diventati proprietà di oggetto.

Anche qua secondo me son modi di vedere lo sviluppo, perche la cosa che tu magari vedi negativa, "i dati sono gia diventati proprieta dell'oggetto", rende piu facile la loro modifica.

Comunque spulciando le classi gia create vedi che il check delle tabelle viene piu che altro utilizzato non per validare ma per correggere eventuali errori ed uniformarli, certo tu mi puoi dire perche non lo fai nel bind ecc.

[mau_develop]

il punto è che tu puoi inserire i dati anche senza utilizzare una form istanziando un oggetto JTable e facendoci un bind con un oggetto creato a "mano".
-----------------------------------
a ecco.. giusto... mi sono incaponito sul mio problema che qs non lo avevo pensato... si, così ha già più logica.

Il fatto di non volerlo far diventare proprietà di oggetto è semplicemente per non incorrere in vulnerabilità non volute che potrebbero essere nel framework, creando già un "oggetto pulito" che possa anche sovrascrivere i dati per il return in caso di fallimento, ripresentandoli puliti ed anche quì quindi evitare problemi del fw....poi magari sbaglio di troppa paranoia ... o di poca cultura informatica

M.

[simone83]

La paranoia è lecita, anche io tendo a mettere migliaia di controlli per evitare rotture forse xche non sono ferrato su questi aspetti e non conosco le infinite tecniche per bucare siti, e non avrei idea di come fare il magheggio che dici tu.

[mau_develop]

 e non avrei idea di come fare il magheggio che dici tu
--------------------------------------------------------------------------
nemmeno io... se l'avessi avrei trovato un problema..

quello che intendevo dire è che io non posso sapere (...anche se dovrei) cosa fanno di quel dato, dovrei verificare come diventa oggetto.
Ti faccio un esempio assurdo... ma non so fino a che punto:
se io lascio "entrare" una stringa sporca dal controller e me la ritrovo come $this nella table qualcosa nel fw è successo, magari tene accorci perchè sovrascrivi il metodo ma magari non avendone necessità... lasci fare ai parent...
da qualche parte il mio pippo della request è diventato $this->pippo quindi.... se sviluppando il core faccio qualcosa di "balordo" per distrazione, ovvero prendo quel dato e lo uso per altro, chessò per infilarlo in una sessione... in un cookie etc... io scrivendo ilmio componente difficilmente me ne accorgo ma alla fine riesco ad avere una stringa "sporca" scritta da qualche parte.... poi mi verrà la fantasia di come usarla... una cosa alla volta

... ma è un discorso un po' fantasioso, più per spiegarti la provenienza delle mie paranoie che per spiegarti la sicurezza informatica

M.

[simone83]

Si hai ragione, esempio giusto, allora sempre rimanendo nell'oggetto table dovresti effettuare un controllo a livello bind dove l'oggetto non è stato ancora popolato.

[mau_develop]

poi joomla è bello anche a me viene spesso da suggerire: "... basta che guardi nel tal componente come fa joomla"

infatti dopo tutto ciò che ci siamo detti, nel contact vedi questo:

Codice: [Seleziona]


/**
* Overloaded check function
*
* @return boolean
* @see JTable::check
* @since 1.5
*/
function check()
{
$this->default_con = intval($this->default_con);

if (JFilterInput::checkAttribute(array ('href', $this->webpage))) {
$this->setError(JText::_('COM_CONTACT_WARNING_PROVIDE_VALID_URL'));
return false;
}


M.