developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#330 closed enhancement (fixed)

les _aftercreate et _afterupdate devraient avoir la jResponse en paramètre

Reported by: bastnic Owned by: bastnic
Priority: low Milestone: Jelix 1.0 RC1
Component: jelix:controllers Version: 1.0 beta 3.1
Severity: trivial Keywords:
Cc: Blocked By:
Blocking: Documentation needed:
Hosting Provider: Php version:

Description

Cela permettrait (entre autre) de pouvoir surcharger la destination après un create. Par exemple, je ne souhaite pas du tout passer en view.

Attachments (1)

patch-330.diff (3.0 KB) - added by bastnic 13 years ago.

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by bastnic

comment:1 Changed 13 years ago by bastnic

  • Milestone set to Jelix 1.0

+ ajout des paramètres aux méthodes _aftercreate, _afterupdate, _delete + déplacement des définitions des réponses $rep avant les appels aux fonctions "_after"

=> essai en situation concrète : fonctionnel.

comment:2 Changed 13 years ago by laurentj

J'aimerais un cas concret d'utilisation, une justification plus précise. Parce que si tu ne veux pas réutiliser les actions de ce contrôleur, pourquoi alors ne pas faire ton propre contrôleur ?

À force de patchs comme celui-là, j'ai peur que jControllerDaoCrud devienne une usine à gaz, et donc s'éloigne de son but originel : avoir un contrôleur simple pour faire des choses simples.

comment:3 Changed 13 years ago by bastnic

Très simple : je me moque complet du mode view. Quand je suis sur la liste, je clique un élément je veux tomber sur edit. Quand je valide l'édition je veux être en mode list.

Le patch n'est pas énorme : juste quelques lignes déplacées. Et ce n'est qu'une proposition.

Je peux surcharger jControllerDaoCrud, mais là pour si peu de lignes changées, je suis obligé de surcharger complètement les méthodes asvecreate, saveupdate et delete là où mes autres modifications se contentent de jouer avec les _after et _create.

Si ce patch n'est pas intégré, ça va m'obliger à faire une surcharge lourde qui m'obligera à constamment vérifier la compatibilité.

Mais de toute manière, tu es notre dieu jelixien, tu fais ce que tu veux.

comment:4 follow-up: Changed 13 years ago by laurentj

Quand je suis sur la liste, je clique un élément je veux tomber sur edit

Tu n'as qu'à surcharger le template, en y mettant les bons liens

Quand je valide l'édition je veux être en mode list.

Puisque tu veux une cinématique différente, peut-être faudrait-il faire un autre controleur.

Le patch n'est pas énorme, certes, mais le code de jControllerDaoCrud est déjà assez complexe comme ça à mon sens. Et si actuellement il semble complexe, c'est justement parce qu'il y a déjà eu plein de petits patchs comme ça, qui ont ajouté des paramètres et possibilités supplémentaires. Bref, c'est en train de devenir une usine à gaz, et en train de devenir plus complexe à utiliser que de faire soit même un contrôleur.

Alors je me demande si il ne faudrait pas proposer plutôt plusieurs controleurs différents, simples, qui ont chacun une cinématique ou une caractéristique spécifique, plutôt qu'un gros contrôleur qui fait tout avec plein de paramètres partout.

Si ce patch n'est pas intégré, ça va m'obliger à faire une surcharge lourde qui m'obligera à constamment vérifier la compatibilité.

D'où ma proposition de faire ton propre contrôleur. Il fera, d'une part, ce que tu veux, et d'autre part, son code sera plus simple que jControllerDaoCrud (donc plus simple à maintenir et à faire évoluer), puisqu'il n'aura pas 50 paramétres possibles. Et si tu penses qu'il est suffisement générique pour être réutilisable tout en proposant une manière différente de faire les choses que jControllerDaoCrud, on pourrait alors l'intégrer à coté de jControllerDaoCrud (un jControllerDaoCrud2 quoi..)

Enfin faut voir quoi...

Une autre chose qui me chiffonne aussi, c'est que ton patch impose un nouveau changement d'api avec ce paramètre supplémentaire.

comment:5 in reply to: ↑ 4 Changed 13 years ago by bastnic

D'où ma proposition de faire ton propre contrôleur. Il fera, d'une part, ce que tu veux, et d'autre part, son code sera plus simple que jControllerDaoCrud (donc plus simple à maintenir et à faire évoluer), puisqu'il n'aura pas 50 paramétres possibles. Et si tu penses qu'il est suffisement générique pour être réutilisable tout en proposant une manière différente de faire les choses que jControllerDaoCrud, on pourrait alors l'intégrer à coté de jControllerDaoCrud (un jControllerDaoCrud2 quoi..)

Pourquoi pas ? J'avoue que j'apprécie l'idée de me baser sur un controleur directement supporté par jelix. Il est forcément plus tester donc forcément plus sur.

Une autre chose qui me chiffonne aussi, c'est que ton patch impose un nouveau changement d'api avec ce paramètre supplémentaire.

Oui c'est un problème en effet, mais il s'agit juste d'un paramètre optionnel en plus, pas un changement révolutionnaire ;).

Dans tous les cas c'est toi qui voit. Moi dans ma branche jelix pour l'instant c'est mon propre jcontrollerdaocrud, je verrais par la suite si je peux te fournir un jControllerDaoCrudAvanced :p.

comment:6 Changed 13 years ago by laurentj

  • Component changed from jelix to jelix:controllers

comment:7 Changed 13 years ago by laurentj

  • Resolution set to fixed
  • Status changed from new to closed

Finalement, j'ai intégré le patch dans le trunk ;-) Merci pour le patch.

comment:8 Changed 13 years ago by bastnic

Merci Laurent.

Note: See TracTickets for help on using tickets.