JeuWeb - Crée ton jeu par navigateur
Petit ensemble de classes - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Petit ensemble de classes (/showthread.php?tid=3217)

Pages : 1 2 3


RE: Petit ensemble de classes - Ekilio - 04-11-2008

Ben là l'idée c'est que tu n'as justement pas tout ça à développer ^^" Tu indiques simplement les champs, et tout est fait : traitement, génération, validation, le tout marche directement. Le tableau suffit pour tout générer, et dans certains cas (par exemple pour les admins) le tableau fait que quelques lignes.

Ca me permet justement de m'éviter de m'embeter avec toutes les étapes assez chiantes dont tu parlais.


RE: Petit ensemble de classes - Melimelo - 04-11-2008

j'avoue que verif et creation des formulaire c'est ce qui a de plus chiant au monde


RE: Petit ensemble de classes - Anthor - 04-11-2008

J'ai regardé quelques peu du boulot, et wahou y'a certaines choses choquante quand même Confused
Sinon c'est très mignon, et +1, les formulaires c'est certainement les parties les plus chiante à développer Sad


RE: Petit ensemble de classes - Ekilio - 04-11-2008

Anthor a écrit :J'ai regardé quelques peu du boulot, et wahou y'a certaines choses choquante quand même Confused

Lequelle ? Que je puisse les corriger et faire mine que c'était déjà prévu pour ma prochaine mise à jour de demain :ninga:


RE: Petit ensemble de classes - Anthor - 04-11-2008

Ha ben attend, j'étais au boulot, faut quand même que je fasse semblant de travailler Smile

Code PHP :
<?php 
// On démarre la bufferisation
ob_start();
Code PHP :
<?php 
$buffer
= ob_get_clean();
echo
$buffer;

C'est pas du tout cohérent, le premier est dans common et le deuxième dans l'index. C'est pas spécialement lisible, une fonction ouverte qui appelle une fermeture, les deux doivent être dans le même fichier.

Ou dans un fichier prepend et un postcon.

De plus je ne vois aucun intérêt à appeler la bufferisation dans un tel cas ou une variable revient au même et est plus léger.
Code PHP :
<?php 
$buffer
= '';

$buffer .= $moduleGeneral->vue();
$buffer .= $moduleGeneral->vue();

echo
$buffer;

Pourquoi ne pas avoir utilisé les exceptions pour la gestion d'erreur ?
Plutôt que de simple die ?

Pour la base de données :
Code PHP :
<?php 
// Pas de tests de validité du résultat, on le considère comme bon
return @mysql_num_rows($this->last);
Pas d'accord, tu ne peux pas le considérer bon si la requête n'est pas intégré à la méthode.
Code PHP :
<?php 
return (is_ressource($this->last))?mysql_num_rows($this->last):false;

Code PHP :
<?php 
public function update($val, $clef, $table)
{
// On prépare la requête de base
$sql = 'UPDATE ' . $table . ' SET ';

// On passe en revu les différentes clefs
foreach($val as $cl => $vl)
{
$sql .= '`' . $cl . '` = \'' . $vl . '\', ';
}

// On ajoute la fin
$sql = substr($sql, 0, strlen($sql) - 2);
$sql .= ' WHERE `' . $clef . '` = \'' . $val[$clef] . '\';';

// On l'execute
$this->exec($sql, 'Impossible de mettre à jour la table.');
}
C'est pas spécialement joli, ni intuitif, pourquoi ne pas faire quelque chose dans le genre ? Qui permet de toujours bien visualiser sa requête ?
Code PHP :
<?php 
// update("select name where user = '%s' and id = %u and visible = %u", "test", 5, 1);

public function update($requete, $arg1, $arg2)
{
$args = func_get_args();
$tmp = call_user_func_array("sprintf", array_merge($args))
return
$this->exec($tmp, 'Impossible de mettre à jour la table.');
}
C'est aussi applicable à query ^^ Qui en plus n'a pas à s'appeler query, puisque qu'elle fait la requête et le résultat sous forme de tableau Smile C'est plus un queryFetchAssoc dans ton cas.
Et il me semble avoir raté la méthode exec ?

Voilà ce n'est que mon avis, j'avais vu quelques autres trucs mais j'ai oublié Smile JE te les redonnerais si je retrouve.


RE: Petit ensemble de classes - Melimelo - 04-11-2008

zend framework génerere les formulaires ?


RE: Petit ensemble de classes - Ekilio - 04-11-2008

Anthor a écrit :Ha ben attend, j'étais au boulot, faut quand même que je fasse semblant de travailler Smile

Code PHP :
<?php 
// On démarre la bufferisation
ob_start();
Code PHP :
<?php 
$buffer
= ob_get_clean();
echo
$buffer;

C'est pas du tout cohérent, le premier est dans common et le deuxième dans l'index. C'est pas spécialement lisible, une fonction ouverte qui appelle une fermeture, les deux doivent être dans le même fichier.

Ou dans un fichier prepend et un postcon.

De plus je ne vois aucun intérêt à appeler la bufferisation dans un tel cas ou une variable revient au même et est plus léger.
Code PHP :
<?php 
$buffer
= '';

$buffer .= $moduleGeneral->vue();
$buffer .= $moduleGeneral->vue();

echo
$buffer;

L'intêret ici de la bufferisation est simplement de pouvoir utiliser header et autres cookies n'importe où sans risques liés à un problème d'enregistrement et/ou d'encodage de fichiers... Ce n'est pas forcément essentiel, mais ça simplifie la vie je trouve. Sinon, pour le placement, je vais déplacer l'ouverture dans le fichier index.php.

Citation :Pourquoi ne pas avoir utilisé les exceptions pour la gestion d'erreur ?
Plutôt que de simple die ?

Parce que je n'ai jamais été à l'aise avec les exceptions et la façon de les utiliser en php.

Citation :Pour la base de données :
Code PHP :
<?php 
// Pas de tests de validité du résultat, on le considère comme bon
return @mysql_num_rows($this->last);
Pas d'accord, tu ne peux pas le considérer bon si la requête n'est pas intégré à la méthode.
Code PHP :
<?php 
return (is_ressource($this->last))?mysql_num_rows($this->last):false;

Sauf que je le considérais comme bon parce que je me fiais au programmeur. Il faut savoir que la classe de base de données a été créée avant toutes les autres (sauf la classe d'erreur), et que je l'ai juste reprise pour cet ensemble. Donc je supposais que la fonction ne serait jamais appellée si elle n'était pas supposée l'être vu que je savais dans quel cas elle devait l'être.

J'appliquerais la modification demain.

Citation :
Code PHP :
<?php 
public function update($val, $clef, $table)
{
// On prépare la requête de base
$sql = 'UPDATE ' . $table . ' SET ';

// On passe en revu les différentes clefs
foreach($val as $cl => $vl)
{
$sql .= '`' . $cl . '` = \'' . $vl . '\', ';
}

// On ajoute la fin
$sql = substr($sql, 0, strlen($sql) - 2);
$sql .= ' WHERE `' . $clef . '` = \'' . $val[$clef] . '\';';

// On l'execute
$this->exec($sql, 'Impossible de mettre à jour la table.');
}
C'est pas spécialement joli, ni intuitif, pourquoi ne pas faire quelque chose dans le genre ? Qui permet de toujours bien visualiser sa requête ?
Code PHP :
<?php 
// update("select name where user = '%s' and id = %u and visible = %u", "test", 5, 1);

public function update($requete, $arg1, $arg2)
{
$args = func_get_args();
$tmp = call_user_func_array("sprintf", array_merge($args))
return
$this->exec($tmp, 'Impossible de mettre à jour la table.');
}

Parce que ce n'est pas le but de cette fonction ^^ Cette fonction sert justement à éviter de taper toute la requête, c'est juste une mise à jour. Par exemple, si vous modifiez les valeurs d'un objet, il suffit de les récupérer dans un tableau, de modifier les clefs de ce tableau et de faire un update() sur ce tableau :

Code PHP :
<?php 
$objet
= $db->query('SELECT * FROM objets WHERE id = 1');
$objet[0]['truc'] = 2;
$objet[0]['truc2'] = 32;
$db->update('objets', $objet[0], 'id');

Ca n'a pas du tout pour but d'être utilisé pour executer toute sorte de requête, pour ça, il y a la fonction query().

Citation :C'est aussi applicable à query ^^ Qui en plus n'a pas à s'appeler query, puisque qu'elle fait la requête et le résultat sous forme de tableau Smile C'est plus un queryFetchAssoc dans ton cas.

Bah, je demande juste la requête entière, c'est plus simple je trouve que de s'embeter à demander des arguements : la requête est formatée ailleurs, la fonction l'execute simplement.

Citation :Et il me semble avoir raté la méthode exec ?

Elle n'existe plus depuis le passage de ma classe database dans cet ensemble de classes, j'ai juste oublié de la remplacer à certains endroits ^^" C'est mis à jour dans la version que je posterais demain, mais pas dans la version que j'avais sur ma clef.

Citation :Voilà ce n'est que mon avis, j'avais vu quelques autres trucs mais j'ai oublié Smile JE te les redonnerais si je retrouve.

Et merci beaucoup pour cet avis Smile

oxman a écrit :Sans mechancete aucune, en gros tu refais Zend Framework ?

Je n'ai pas cette prétention ^^ Je me contente de faire une ensemble de classes qui me conviennent. Le Zend Framework contient trop de choses à mon goût, et certaines sont trop complexes pour l'usage que j'en fait : de mon point de vue, parfois, c'est comme sortir un tank pour tuer une mouche... Je préfère utiliser mon chat, il fait ça beaucoup mieux (private joke).

Après, bah... Si ça peut aider quelqu'un, tant mieux ^^ Mais ça n'a pas la complexité et les possibilités du Zend Framework.


RE: Petit ensemble de classes - Melimelo - 05-11-2008

Pour la classe utilisateur, pourquoi définir 3 type d'utilisateur ?

Pourquoi ne pas en laisser une infinité via un système de droit plustôt ?


Et aussi pourquoi pas une gestion des dates et fuseaux horaires ?

Y a un système multi-langue ?


RE: Petit ensemble de classes - Ekilio - 06-11-2008

Salut,

Bon, finalement la mise à jour attendra ce soir, hier j'était trop creuvé ^^"

Pour te répondre Melimelo :

- La classe utilisateur peut être étendue (et est faite pour ça), donc on peut dans la pratique mettre une infinité ; les deux types spéciaux de base sont juste une base pour proposer une gestion pour les gens qui ne veulent pas s'embeter à en créer une.

- Gestion des dates et fuseaux horaires, je vais y réfléchir Smile

- Il y a un système multi-langue, ça passe par la classe "langue" Smile Elle est documenté au début de la description des classes, juste après la classe configuration ; en gros elle utilise des fichiers de langue, et la gestion est automatique via le système des vues. Voici comment l'utiliser par exemple pour afficher "Bonjour" dans deux langues différentes, selon l'utilisateur, pour un module nommé "exemple" et dans l'action "test" :

(1) Tu créés dans ton dossier langues un dossier "fr" et un dossier "en".
(2) Dans le dossier "fr", tu met un fichier nommé "exemple.php" avec ceci :

Code PHP :
<?php
$langueC
= array(
'L_BONJOUR' => 'Bonjour'
);
?>

(3) Dans le dossier "en", tu met un fichier nommé "exemple.php" avec ceci :

Code PHP :
<?php
$langueC
= array(
'L_BONJOUR' => 'Hello'
);
?>

(4) Tu créé ton module exemple et son action test normalement, comme ceci :

Code PHP :
<?php

class exemple extends module
{
protected
$nomModule = 'exemple';

public function
test()
{
$this->nomVue = 'test';
}
}

?>

(5) Tu créé normalement ta vue, en lui associant la clef voulue :

Code PHP :
<?php 
<b>{L_BONJOUR}</b>

(6) C'est fini ! La langue par défaut est définie par le paramètre "defautLangue" de la configuration "global", mais si tu définies une clef "langue" dans la liste des variables de l'utilisateur (ce qui se fait automatiquement si tu créé un champs de ce nom dans la table "utilisateurs", par défaut), alors la langue utilisée sera celle dont le code est défini dans ce champs

Enfin, ça c'est la théorie, en pratique il y a une petite erreur de ma part qui empeche ça de fonctionner, il faut juste décaler le session_start... C'est fait sur les fichiers mis à jours, mais je dois trier ceux qui sont pour mon boulot et ceux que je met ici, et j'était trop creuvé pour le faire hier, et là je vais partir au boulot ^^" J'essayerais de le faire dans la journée, ou ce soir.


RE: Petit ensemble de classes - Melimelo - 06-11-2008

ok

Une gestion de la cache aussi ?

j'ai vraiment hâte de l'essayer, car il est pas trop lourd ton framework Big Grin