Le cahier de dessin animé

cahierDessinAnime600x300

La réalité augmentée est pour moi sous exploitée depuis des années, j’avais déjà écrit un billet sur le sujet. J’ai découvert avec plaisir une initiative qui exploite cette technologie pour le bonheur de nos enfants.
Cette projet se nomme le cahier de dessin animé.

Le concept
cachierDessinAnimeDetail600x300
L’idée est simple: vous avez un cahier, comportant une dizaine de pages l’enfant le colorie avec crayons/feutres habituels.
Puis, un des parent le prend en photo avec l’application (iOS/Android gratuite) et son coloriage va s’animer sous ses yeux.

Magique, non ?

Ce projet fait l’objet d’un financement participatif sur KissKissBankBank, ils ont pour l’instant (à l’heure ou j’écrit) récolté 55% de la somme demandée (25 000 euros)

Vous souhaitez l’acheter ?
Vous pouvez pré-commander votre cahier pour 25 euros, et celui-ci vous sera livré sous le sapin.
Je pense que ça peut être une bonne idée de cadeau pour les fêtes ;)

Le site: http://www.kisskissbankbank.com/le-cahier-de-dessin-anime

Comment choisir son framework: formulaire modification – Symfony 2

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart:

Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : Symfony 2
Dans ce billet, nous allons essayer de comprendre comment s’organise un formulaire, l’enregistrement en base de données et éventuellement la vérification de certains champs.

Voilà la page que l’on va analyser ici:
siteWeb

Le controlleur
/src/Acme/BlogBundle/Controller/AdminPostController.php
tree-module-post

code-module-post

La vue
/src/Acme/BlogBundle/Resources/views/AdminPost/manage.html.twig
tree-view

code-view

Les controles
/src/Acme/BlogBundle/Form/PostType.php
tree-form

On a ici une classe par type de formulaire, où l’on a les différents controles effectuées.

code-form

Dans le controlleur, on voit l’utilisation de cette classe ici:
code-formCheck

note: si il y a une erreur, il n’y a pas de retour :(

L’enregistrement en base de données
Toujours dans le controlleur, et dans la même méthode, on enregistre via le code suivant:
code-formCheckSave

Retour au sommaire

Comment choisir son framework: formulaire modification – Zend framework 2

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart:

Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : Zend framework 2
Dans ce billet, nous allons essayer de comprendre comment s’organise un formulaire, l’enregistrement en base de données et éventuellement la vérification de certains champs.

Voilà la page que l’on va analyser ici:
siteWeb

Le controlleur
/module/Blog/src/Blog/Controller/PostController.php
tree-module-post

code-module-post-edit

La vue
/module/Blog/view/blog/post/edit.phtml
tree-view-edit

code-view-edit

Les controles
/module/Blog/src/Blog/Form/EditPostForm.php
tree-form

On a ici une classe par type de formulaire, où l’on a les différents controles effectuées.

code-form

Dans le controlleur, on voit l’utilisation de cette classe ici:
code-module-post-edit-form
note: si il y a une erreur, on affiche un flash message unique

L’enregistrement en base de données
Toujours dans le controlleur, et dans la même méthode, on enregistre via le code suivant:
code-module-post-edit-form-save

Retour au sommaire

Comment choisir son framework: formulaire modification – mkFramework

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart:

Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : MkFramework
Dans ce billet, nous allons essayer de comprendre comment s’organise un formulaire, l’enregistrement en base de données et éventuellement la vérification de certains champs.

Voilà la page que l’on va analyser ici:
siteWeb

Le controlleur
/module/privatePosts/main.php
tree-module-post

code-module-post

La vue
/module/privatePosts/view/edit.php
tree-module-post-view

code-module-post-view

Les controles
/model/model_posts.php
tree-model

On a ici nos controles dans la classe model du post, ils sont effectué à chaque enregistrement, qu’ils proviennent d’un formulaire web, d’un appel webservice ou autre.

code-getcheck-model

Dans le controlleur, on voit l’utilisation de cette classe ici:
code-controller-saveCheck
note: si il y a une erreur,
on retourne une liste de message qui sont passés à la vue
code-controller-callSave
pour être enfin affiché dans la vue
code-module-post-view-tMessage

L’enregistrement en base de données
Toujours dans le controlleur, on a dans l’action d’edition un appel à la méthode privée processSave()
Celle-ci vérifie la cohérence des données + le token: si il y a une erreur, elle retourne un tableau des erreurs, si tout se passe bien, elle enregistre puis redirige:
code-controller-saveAndRedirect
Note: si l’enregistrement se passe bien, on met à jour le cache des catégories et derniers posts.

Retour au sommaire

Comment choisir son framework: formulaire modification

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart:

Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet
Dans ce billet, nous allons essayer de comprendre comment s’organise un formulaire, l’enregistrement en base de données et éventuellement la vérification de certains champs.

Voilà la page que l’on va analyser ici:
siteWeb

Retrouvez un billet de détail sur les frameworks suivants:

Retour au menu principal

Comment choisir son framework: formulaire modification – Kohana

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart:

Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : Kohana
Dans ce billet, nous allons essayer de comprendre comment s’organise un formulaire, l’enregistrement en base de données et éventuellement la vérification de certains champs.

Voilà la page que l’on va analyser ici:
siteWeb

Le controlleur
/application/classes/Controller/Admin.php
tree-controller

code-controller

La vue
/application/views/admin/edit.php
tree-view

code-view

Les controles
/application/classes/Model/Post.php
tree-model

On a ici les règles de controles dans la classe model

code-model-check

Dans le controlleur, on voit l’utilisation de ces controles ici:
Il y a un try/catch qui catch les evenetuels erreurs d’enregistrement, controles compris
code-controller-processCheck

L’enregistrement en base de données
Toujours dans le controlleur, dans la méthode action_post_edit, on enregistre via le code suivant:
code-controller-processSave

Retour au sommaire

Comment choisir son framework: sommaire

Introduction
Depuis quelques années, nous avons vu se developper sur notre plateforme php de nombreux frameworks.
Le plus difficile aujourd’hui est de choisir parmi eux.
Jusque là, vous aviez à votre disposition un tableau comparatif: http://socialcompare.com…
Aujourd’hui grâce à l’initiative du site grafikart, vous avez une autre manière de comparer: le projet blogmvc.com (http://blogmvc.com)

Sommaire

Comment choisir son framework : view / layout – mkFramework

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : MkFramework
Dans ce billet, nous allons essayer de comprendre comment s’organise la création de page avec chaque framework:
Pour rappel, dans un site web, on à un template général, appelé « layout », qui contient notre bandeau/logo, nos menus de navigation ainsi qu’une partie dynamique: le contenu de notre site.
Nous allons voir ici, comment ont choisi le layout à utiliser (on peut en avoir plusieurs), puis comment on intègre la navigation, et comment on choisit quel template de vue utiliser pour l’affichage de notre contenu.

Voilà la page que nous allons étudier ici:
layoutViewSite

On peut voir 4 zones:

  • Le bandeau
  • La navigation des catégories
  • La navigation des derniers posts
  • Le contenu dynamique

layoutViewSite2

Le layout
Pour afficher la page d’accueil, on appelle la classe controller module_default:
/module/default/main.php
tree-module-default

controller
On voit ici que l’on instancie un objet layout « template1″, on voit également qu’il instancie deux modules, un pour les catégories et l’autre pour les derniers posts qu’il ajoute à l’emplacement « sidebar »
Voyons à quoi ce layout ressemble:
Pour information, il se situe ici:
/layout/template1.php
tree-layout-tpl1

layout

On retrouve ici le bandeau écrit directement dans le layout, un emplacement pour le contenu dynamique (qui contiendra le contenu) plus un autre pour la sidebar qui contiendra la navigation des catégories + celle des derniers posts

La/les vues
Lorsque l’on regarde l’action appelée pour afficher cette page d’accueil:
viewDefaultIndex
On voit que l’on assigne à l’emplacement « main » la vue retournée par le module posts.
Ce framework permet en effet d’appeler des modules « embedded », et de récupérer leur vues pour les imbriquer où bon nous semble.
Allons jetez un oeil à cette méthode _index() du module posts
tree-module-posts

postEmbeddedIndex
Ceci est un controller de module embarqué, on inclue pas uniquement une vue de ce module mais tout le module posts: ainsi si on clique sur le lien d’un post (de la liste), le module embarqué affichera naturellement le détail de celui-ci. (il est autonome)
Par défaut, on voit que le second argument est « list »: on affichera donc par défaut la liste des posts avec la méthode _list() du module en question.
Regardons à quoi celle-ci ressemble:
postEmbeddedList
Il instancie une vue post::lists, située ici :
/module/posts/view/list.php
tree-module-postViewList

postViewList

Revenons à la méthode before() qui permettait d’ajouter les catégories et les derniers posts.
Les modules categories et posts étant des modules « embedded », vous comprenez mieux maintenant l’inclusion des vues de ces modules à l’emplacement de la sidebar.
Voici le code de la méthode list du module embarqué categories, on voit ainsi comment est géré le cache du menu ;)
/module/categories/main.php
tree-module-categories

categoriesList

Retour au sommaire

Comment choisir son framework : view / layout – Kohana

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : MkFramework
Dans ce billet, nous allons essayer de comprendre comment s’organise la création de page avec chaque framework:
Pour rappel, dans un site web, on à un template général, appelé « layout », qui contient notre bandeau/logo, nos menus de navigation ainsi qu’une partie dynamique: le contenu de notre site.
Nous allons voir ici, comment ont choisi le layout à utiliser (on peut en avoir plusieurs), puis comment on intègre la navigation, et comment on choisit quel template de vue utiliser pour l’affichage de notre contenu.

Voilà la page que nous allons étudier ici:
layoutViewSite

On peut voir 4 zones:

  • Le bandeau
  • La navigation des catégories
  • La navigation des derniers posts
  • Le contenu dynamique

layoutViewSite2

Le layout
Pour afficher la page d’accueil, on appelle la classe controller:
/application/classes/Controller/Posts.php
tree-controller-post

controllerLayout
On voit ici, que la propriété publique « template » indique le nom du layout « layouts/blog »
Voyons à quoi il ressemble:
Pour information, il se situe ici:
/application/views/layouts/blog.php
tree-layout

layout
On retrouve ici le bandeau écrit directement dans le layout, et un emplacement pour le contenu dynamique qui contiendra le contenu + la navigation des catégories + celle des derniers posts

La/les vues
Lorsque l’on regarde l’action appelée pour afficher cette page d’accueil:
controllerAction
On voit que l’on assigne au contenu la vue blog/index

On note également que la classe étend Controller_Template, une classe située ici:
/application/classes/Controller/Template.php
tree-classTemplate

Dans laquelle une méthode before() initialise « en global » les tableaux contenant les catégories et les derniers posts:
before
On voit également comment est géré l’affichage du cache de ce menu qui change rarement.

Revenons à notre vue blog/index, cette vue est situé ici:
/application/views/blog/index.php
tree-view-blogIndex

vueBlogIndex
On remarque que celle-cifait appel à la vue blog/posts et blog/sidebar
Qui permettront d’afficher la liste des posts et les deux navigations: catégories et derniers posts

Retour au sommaire

Comment choisir son framework : view / layout – zend framework 2

Introduction
Dans un précédent billet, je vous ai présenté l’initiative de grafikart: http://blog.developpez.com/ducodeetdulibre/p12482/outilsweb/comment-choisir-son-framework-php
Sur les prochains billets, nous allons détailler, analyser et comparer la manière de faire de chaque framework.

But de ce billet : Zend Framework 2
Dans ce billet, nous allons essayer de comprendre comment s’organise la création de page avec chaque framework:
Pour rappel, dans un site web, on à un template général, appelé « layout », qui contient notre bandeau/logo, nos menus de navigation ainsi qu’une partie dynamique: le contenu de notre site.
Nous allons voir ici, comment ont choisi le layout à utiliser (on peut en avoir plusieurs), puis comment on intègre la navigation, et comment on choisit quel template de vue utiliser pour l’affichage de notre contenu.

Voilà la page que nous allons étudier ici:
layoutViewSite

On peut voir 4 zones:

  • Le bandeau
  • La navigation des catégories
  • La navigation des derniers posts
  • Le contenu dynamique

layoutViewSite2

Le layout
Pour afficher la page d’accueil, on appelle la classe controller PostController:
/module/Blog/src/Blog/Controller/PostController.php
tree-module-post

Il n’y a pas d’indication sur le layout à charger, par défaut c’est : layout.phtml
Pour le modifier:
codeSelectLayout
Revenons à notre layout par défaut, voyons à quoi il ressemble:
Pour information, il se situe ici:
/module/Blog/view/layout/layout.phtml
tree-layout

code-layout

On retrouve ici un appel partiel au layout « navbar », , un emplacement pour le contenu dynamique (qui contiendra le contenu) plus un autre appel partiel à « sidebar » qui contiendra la navigation des catégories + celle des derniers posts (+ une condition pour gérer le cache de ce menu)

Le layout partiellement chargé layout/navbar
tree-layout-navbar

Mais ce qui est plus intéressant c’est layout/sidebar (notre fameux menu des catégories et derniers posts)
tree-layout-sidebar

code-view-sidebar

Note: par défaut, ces menus sont vides car chargé à partir du layout principal avec tableau posts et categories à vide (simple array)
note 2: je ne sais pas comment on pourrait lui passer la vrai liste des posts et categories :(

La/les vues
Lorsque l’on regarde l’action appelée pour afficher cette page d’accueil:
code-controller-index

On suppose par convention qu’il appelle la vu du même nom
/module/Blog/view/blog/post/index.phtml
tree-view-iindex

code-view-index

Retour au sommaire