Reprise du message précédent :

public function save() {
    if (Validate::isNull($this->id)) {
        parent::save();
 
        $advertiserId = date('Ymd') . $this->id . '-' . self::ACTOR_ADVERTISER;
        $prepare = $this->_db->prepare('UPDATE '.$this->_schema.'.'.$this->_name.'
                                            SET advertiser_id = ?
                                            WHERE '.$this->getTableName().'.'.$this->_primary.' = ?');
        $this->bind(1, 'advertiser_id', $advertiserId, $prepare);
        $this->bind(2, $this->_primary, $this->id, $prepare);
        $prepare->execute();
        $this->advertiser_id = $advertiserId;
    } else {
        parent::save();
    }
}

 
En gros, c'est le $this->advertiser_id qui change en fonction de la classe.

le parent se charge de la sauvegarde, et la classe fille de son code spécifique

perso , je ne factoriserai pas plus que ce que tu as fait ( mais je ferai peut etre une fonction updateAdvertiserId() )

Euh, le parent::save(); en double il a une raison ?

 
ouais enfin si t'as exactement la même opération spécifique dans chaque classe fille il y a un soucis de conception à la base amha.

public function save() {
    if (Validate::isNull($this->id)) {
        parent::save();
        [...]
    } else {
        parent::save();
    }
}

humm....wat?

[edit]

ce 'est pas la même , si j'ai bien compris, a chaque fois il mets a jour un champ différent en base de données avec des valeurs spécifique

 
Genre il s'appelle majolieclasse_id partout?
Si oui, un simple "id" dans la classe mère et basta.

Eheh, j'étais sûr que vous alliez tiquer pour le parent::save()
Je ne peux pas le faire avant la condition car le save s'occupe de setter l'id, donc il ne rentrera jamais dans la condition sinon.

$prepare = $this->_db->prepare('UPDATE '.$this->_schema.'.'.$this->_name.'
                                            SET advertiser_id = ?
                                            WHERE '.$this->getTableName().'.'.$this->_primary.' = ?');
        $this->bind(1, 'advertiser_id', $advertiserId, $prepare);
        $this->bind(2, $this->_primary, $this->id, $prepare);
        $prepare->execute();

ça me semble bizarre
tu fasi this->_db->prepare  mais this->bind
tu ne peux pas avoir , dans une classe , deux requêtes en parallèle ?

 
Non, car c'est un pseudo orm, donc $var == var en bdd.

$prepare = $this->_db->prepare('UPDATE '.$this->_schema.'.'.$this->_name.'
                                            SET advertiser_id = ?
                                            WHERE '.$this->getTableName().'.'.$this->_primary.' = ?');
        $this->bind(1, 'advertiser_id', $advertiserId, $prepare);
        $this->bind(2, $this->_primary, $this->id, $prepare);
        $prepare->execute();

 
C'est un peu le merdier à ce niveau là, c'est pas de moi, j'y touche pas

parent:save();
if(validate...))
{
  //ton code spécifique
}

 
Bah non, parce que l'id ne sera plus null vu que save va le setter.

C'est un peu le merdier ton histoire...
Tu as donc le nom de la variable qui change (en tant que membre et dans la requête) et c'est tout?

Si oui, tu fais une fonction, implémentée dans toutes les filles uniquement, qui te retourne le nom de cette variable et c'est gagné, non?

Mais t'es con ou t'es con ou alors tu es con ?

ton parent:save(), il est dans le if et dans le else,

et faire

c'est pareil que

Arrête l'informatique...

 
Relis avec le doigt. Après le save() la condition sera toujours fausse. D'où sa construction...inhabituelle.

lui non plus

 
Non, en fait c'est toi qui est con ou tu ne sais pas lire

Stoi arrête l'informatique gros mauvais PHP c'est pas haskell, parent:save() peut avoir des effets de bord, donc inverser l'ordre de 2 opérations consécutives n'est pas nécessairement anodin

En l'occurrence, ici, si parent:save set $this->Id — ce qui semble être le cas — ben t'as ton test qui sera plus jamais exécuté puisqu'il dépend de la nullité de $this->Id.

Donc le cas correct pour une extraction de parent:save serait

$newObject = Validate::isNull($this->id);
parent:save()
if($newObject) {
   ...
}

Ou alors modifier la signature de save() pour qu'il renvoie true ou false selon qu'il crée un nouvel objet ou pas

if(parent:save()) {
   ...
}

auquel cas je renommerais save() en createOrSave()

3e possibilité, save() prend un bloc pour une création et un bloc pour une édition:

super.save(IfCreated: (() => /* stuff */))

mais c'est PHP alors...

$newObject = Validate::isNull($this->id);
parent:save()
if($newObject) {
   ...
}

if(parent:save()) {
   ...
}

super.save(IfCreated: (() => /* stuff */))

J'avais pas vu qu'il faisait des traitements dans son if, c'est tout aussi illisible

non plus

GatsuG

Non.

Non. La bonne solution c'est celle que 0x90 suggère (la seconde), tu mémorises les coordonées de tes images en mémoire, et ensuite tu fais un test de collision sur la position de ton curseur.

Vaut mieux tout bien lire avant d'insulter les gens

Parce que si les coordonnées correspondaient au centre des pixels, alors quand tu fais un fill (d'un rectangle avec coordonnées entières), les bords du rectangle seraient flous. Il faut choisir entre avoir les stroke et les fill de flou, ils ont préféré les stroke (C'est aussi le cas dans cairo (du coup postscript aussi probablement), opengl et qt.

Si _vraiment_ tu préfères avoir tes coordonnées au centre, tu translate au tout début de (0.5, 0.5) et wala.

alors là, ça sent l'explication intelligente et pleine de sens, mais je comprend pas (.. pourquoi les bords du rectangles seraient flous .. )

Bah pasqu'ils vont de bord à bord, et là le bord se retrouve en plein milieu d'un pixel, donc un average est fait et tu te retrouves avec le bord de ton rectangle à 50% d'alpha (donc flou) je présume.

CSS 3 + HTML 5 + SVG + Firefox 4 =

En fait on est dans le monde du vectoriel, pas du bitmap, c'est fini les rectangles 0,0 -> 10, 10
 
imagine comment il trace une ligne de pixels : il va parcourir un chemin (la génératrice) avec un pinceau. il va mettre le milieu du pinceau sur la génératrice (par défaut, je crois qu'il y a une feinte pour le décaler, pour faire des ombres portées par exemple).
 
donc si tu mets la génératrice sur une frontière entre 2 pixels, la peinture va aller sur les 2 pixels à droite et à gauche de la génératrice. Si tu mets la génératrice au milieu d'un pixel et que tu as un pinceau d'un pixel de large, la peinture va rester sur une ligne de pixels.

Explication claire, merci

Première fois que je vois l'embed html5 en action

transform: rotate(10deg);
 
 A new evil is born

ça va vite faire oublier le <blink> remarque  

Hier j'ia découvert qu'un site récent de chez nous utilise encore <marquee>

 
Voilà le coin d'un rectangle de coordonnées (0, 0) → (10, 10), dans un repère où (0,0) corresponds au centre du pixel.

En noir le rectangle vectoriel, en vert celui rasterisé.
L'antialiasing calcule pour chaque pixel le pourcentage de surface couverte, du coup pour les bords le pixel est couvert à 50% par le rectangle vectoriel, et pour les coin à seulement 25%. Et voilà, t'as un remplissage de rectangle flou

moi chuis encore dans le monde de l'ATARI 520STE (appeau à Harko) du coup ça m'échappe un peu. Bon je comprend le principe, maintenant, mais je pige pas pourquoi on a un repère en *pixels* si c'est pour faire du vectoriel, antialiasing, et fineauder sur un bord-ou-centre de pixels. L'unité ne semble pas adaptée..

Cool ça tuera flash, mais je suis inquiet de ce que les webdesigners vont nous pondre comme interface de remplacement. Y'a plein de sites que je ne consulte que par mon aggrégateur rss tellement ils font mal aux yeux ou font ramer la machine (flash, gif anim, js, etc).
 
Les sites minimalistes et légers sont encore ceux que je préfère et de loin.

Y'a du monde qui bosse dans un environnement Java ici, ou bien ?
(si oui j'ai des questions )