コンテンツタイプvs WebフォームvsフォームAPI vsカスタムフォームvs？
私は現在、新しいDrupal 7サイトです。これは、データ収集およびレポートサイトとして使用されます。多くの調査/試行錯誤などの後、これをもたらすことにしました。このフォーラムへの質問、そしてそれが「一般的すぎる」として捨てられないことを心から望んでいます。
約25のフィールドで構成されるコンテンツタイプを作成しましたが、ユーザーにそのコンテンツを入力させるための最良のアプローチは何でしょうか。そのままでは（[ディスプレイの管理]を使用しても）、フォーム自体はまだユーザーに実際に表示したいものとは似ていません。また、フック_フォーム_アルターフレーバーの1つを使用してフォームを変更するのは少し気が狂っているように見えます。私もWebformモジュールで少し時間を費やしましたが、それは問題ありませんが、フォームを意図したとおりに表示/動作させるために実行する必要があるかなりのカスタマイズがまだあります。一般的に、そのモジュールのレビューを混合してください（誰にとっても不快ではありません！）。データを収集するための基本的なフォームを思い付くために、Form APIを使用する場合も同じです。
私の最新のアプローチは、単純にマークアップタイプを使用してフォーム自体を作成することです（基本的に、単純にhtml/css/javascriptを作成し、コンテンツタイプをバックグラウンドで入力/更新します。開発者の観点から、このアプローチは非常に、非常に簡単です-ロケットサイエンスはありません-メンテナンスは簡単ですが、Drupalの使い方を知っている皆さんからのお便りをお待ちしています。
前もって感謝します！ cmmsites
私はDrupalをまったく同じ目的で使用しています。基本的に、私がしていることは Field Group モジュールを使用して特定の項目をDIVタグでラップし、 CSSスタイルを使用して、フォームを適切にレイアウトできます。
Drupalは、適切に名前が付けられたクラスを持つ、非常に構造化されたコンテナー要素のセットを提供します。したがって、CSSの機能を活用してレイアウトを操作することは、最初に考えるべきことです。
私はWebformモジュールをいじりましたが、それはかなり可能ですが、情報を収集するためにDrupalの標準コンテンツタイプシステムをそのまま使用するのが最も適していることがわかりました。 Views と Rules モジュールを使用して、モジュール化された膨張が少なくて済む重要な情報を示すレポートページを生成するDrupalインストール。
ですから、ビュー、フィールドグループ、ルールモジュールを必ず読んで、説明した機能があなたの要求に合うかどうかを確認してください。
フォーム要素のみを移動する場合は、ディスプレイスーツを確認する必要があります。
コードを何も記述せずに、要素を好きなように配置できます。 
ノードは必要ないので、フォームAPIとエンティティで試してみましょう。ドルーパルの未来だと思います。
フォームAPIが慣習にハッキングされていることは事実ですが、ノードフォームを使用するフォームAPIを使用すると簡単です。
また、フォームAPIを使用する場合は、drupalと言います。そうでなければ、将来の開発者向けのコードを用意するのは難しいでしょう。
オスカー
私は過去数ヶ月にわたって広範囲にわたってウェブフォームを扱ってきました。私はWebformモジュールを使用していますが、それは実際にはやり過ぎですが、フォームが何であるかによって異なります。条件付きフィールド、検証ルールなどがたくさんあるため複雑です。
エンティティフォームを確認してみてください drupal entityforms
そして、いくつかの興味深い読み物 http://stidwill.com/content/web-forms-dead-long-live-entity-forms
この質問が古いことは知っていますが、ここに私が思うことがあります。データをどのように使用するかは、フォームを作成する方法の重要な決定事項です。
Webformは調査用に作成され、うまく機能します。フォームを一覧表示して有効化/無効化したり、必要に応じて変更したりするのは簡単です。各Webフォームには、その提出物へのリンクがあります。
コンテンツタイプ（ノード/エンティティ/何でも）を使用すると、権限の影響が異なり、後でアクションをより柔軟に実行できます。 5つ星モジュールまたはフラグモジュールをコンテンツタイプで使用できますが、Webフォーム送信では使用できません。
フォームapiを使用してカスタムフォームを作成することは、長期的に取得するためにデータベースに保存せずに、自分で情報を処理する場合に適しています。ノードとWebフォームの両方がすでに行っていることだけを実行するために、別個のフォーム、検証、および送信ハンドラーを定義するという問題は経験しません。しかし、あなたはすでにこれに時間を費やしているようです。これは、常に羽状突起の皮をむく方法が複数あることを証明するためのものです。
Webフォームとカスタムコンテンツタイプの両方で、マークアップフィールドを使用できます https://www.drupal.org/project/markup どちらも、小さな自動化タスク（または大規模な自動化、開発者のスキルに応じて）必要に応じて、どちらにも統計または概要ページを作成するためのビュー統合があります。 （ https://www.drupal.org/project/webform_mysql_views ）
したがって、質問が本当に「カスタムフォームの表示に最も簡単なのはどの方法ですか？」その答えはカスタムコンテンツタイプです。フィールドグループ、フィールドコレクション（必要になることはほとんどありませんが、扱いが面倒ですが、必要なときに非常に役立ちます）、および上記のマークアップフィールドはほとんどのことを行います。提供されたモジュールでは垂直タブ内のタブが不可能な場合、フィールドグループとjsを使用してラジオボタンのセットをタブに変換しました。私が作成したプロジェクトには、フォームに80以上のフィールドがあり、繰り返しが多い場合がありました。このモジュールをそこで使用するために作成したのは、6つのフィールドスタイルしか必要とせず、フォームオルタでフィールド名を使用したり、コピー置換エラーが発生したりするのにうんざりしていたからです。 https://www.drupal.org/sandbox/developerweeks/1964036