Formulaire et framework web

Le problème exposé dans ce sujet a été résolu.

Bonsoir,

Je travaille sur un petit projet basé sur le framework Laravel. Je suis en train d’écrire les divers forumailres du site. Or, je viens de réaliser qu’il y a trois manières d’écrire les forumaires :

  1. HTML pur
  2. Template dans le HTML
  3. Classe

Il est important de savoir que les deux dernières méthodes utilisent des bibliothèques externes.

Méthode 1 : HTML pur

<form method="POST" action="#">
  <input type="text" name="username" id="username" />
  <input type="password" name="password" id="password" />
  <button type="submit">Connexion</button>
</form>

Méthode 2 : template dans le HTML

{!! Form::open(['url' => '#']) !!}
  {{ Form::text('username') }}
  {{ Form::text('password') }}
  {{ Form::submit('Connexion') }}
{!! Form::close() !!}

Méthode 3 : classe

Formulaire

class LoginForm extends Form
{
    public function buildForm()
    {
        $this->add('username', 'text')
             ->add('password', 'password')
             ->add('submit', 'submit', ['label' => 'Connexion']);
    }
}

Contrôleur

class AuthController extends BaseController {

    public function create(FormBuilder $formBuilder)
    {
        $form = $formBuilder->create('App\Forms\LoginForm', [
            'method' => 'POST',
            'url' => route('#')
        ]);

        return view('login', compact('form'));
    }
}

Vue

{!! form($form) !!}

Premièrement, je souhaiterai savoir quels sont les avantages de chaque méthode. Secondement, savoir ce qu’il en est pour les framework en général. Je crois que Django utilise la méthode 2 et Symfony la méthode 3.

Merci d’avance !

Salut !

Alors je vais dire ce que je vois comme avantages et inconvénients de chacune des méthodes.

  1. C’est du HTML, donc on ne réapprend rien et on a un contrôle total. Les styles ? C’est pas un problème. Les types ? On peut tout utiliser sans restriction lié au framework. Cependant, il peut être plus difficile de gérer les données envoyées par un formulaire complexe : faire correspondre les champs du formulaire avec des structures de données n’est pas toujours aisé.
  2. On garde une relative souplesse en définissant le début du formulaire ainsi que chaque champ, avec les propriétés qui sont dans la vue. C’est aussi un peu plus concis que le HTML qui, comme le XML, est parfois considéré comme verbeux. C’est cependant aussi sensible que la solution pure HTML quand on doit faire la liaison entre les champs et une structure de données, c’est une autre "syntaxe" à apprendre. Du moment qu’on décide d’utiliser des outils, on pourrait être limité par ce qu’ils permettent de faire — je pense notamment au type de champ week qui fonctionne sur certains navigateurs, mais que Symfony ne fournit pas parce que ce n’est justement pas supporté par la majorité d’entre eux, et à certains styles par défaut qui sont parfois appliqués.
  3. Le gros avantage est que le formulaire est structuré avec ces méthodes, la liaison avec des objets peut être automatisée — et on n’a même plus vraiment à s’en soucier. Par contre, c’est un peu plus restrictif, dans la mesure où tous les types de champs ne sont pas forcément supportés (cf. le point précédent), et pour ce qui est d’ajouter du style d’une manière ou d’une autre, c’est parfois plus difficile — une fois encore, Symfony ne permet pas facilement de faire des cases à cocher ou des boutons radio sur une seule ligne avec Bootstrap.

Il y a un dernier point qui n’est certes pas à l’ordre du jour vu l’âge de HTML et l’absence relative de relève, c’est le fait que les solutions 2 et 3 sont prévues pour un langage et peuvent être adaptées à un autre. Pour la première, il faudrait refaire l’entier du formulaire.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte