カスタム新規フォームは「列の制限」以外の制限がある？

SharePoint Designer 2010で列が80個あるフォームのレイアウトを変更しているのだが、新規フォーム（NewForm1.aspx）を新しく作って素の状態でエラーが出る。
オリジナルの新いいフォーム NewForm.aspxだとエラーが出ない。

この Web パーツを表示できません。この問題のトラブルシューティングを行うには、Microsoft SharePoint Foundation と互換性のある Microsoft SharePoint Designer などの HTML エディターでこの Web ページを開いてください。問題が解決しない場合は、Web サーバーの管理者に問い合わせてください。

関連付け ID:353a2e2e-b169-4097-b92d-0e3ebf61d68f

 

 入力フォームが多いから？と想定してNewForm1.aspxから<SharePoint:FormField を削除してみたら、61個以下ならエラーにならないことを確認した。

<SharePoint:FormFieldは列の種類によって自動的に表示をかえるので、その処理が原因かもしれないので、<asp:checkboxに書き換えてみたけど結果は変わらなかった。

入力フォームの内訳は

• 1行テキスト　29
• 選択肢　　　　9
• 数値　　　　　10
• 日付と時刻　2
• はい/いいえ　10
• ハイパーリンク　１

これ以上の入力フォームを作成するとエラーになる。

でも、この数は列の制限から見ればまだ余裕はある。

試しに、はい/いいえ　を上限である96個作成して新規フォームを作成するとエラー。
フォームを削っていくと、67個以上で同様のエラーになる。

この時の列の内訳は

• 1行テキスト　１　　（タイトル）
• はい/いいえ　96

とりあえず、状況から見てカスタム新規フォームは列の制限より少ない数でエラーになることが分かった。

今作ってるカスタムリストは81列必要だし、もう一つは項目が増えて100程度必要なんですけどね・・・

「列の制限」の計算表を作ってみた。

SharePointを利用するうえで列が多くなると制限を考慮する必要があるけど、種類と組み合わせによって上限が変化するのでちゃんと計算しないとダメなんだよね。

この制限を理解するため、簡単にチェック出来る計算表をExcelで作ってみた。

SharePoint2010列の制限-計算表.xlsx

ポイントは３つ

• SQL Serverのテーブルにデータを配置する際に、一定数上になると複数行になって制限が6行（変更は可能）
• リスト内の列の合計サイズが8,000バイトで、組み込み列用に256バイトが予約されているので、実質7744バイト。
• 列の種類によってサイズ、折り返しが発生する数が異なる。(詳しくはTechNet列の制限を参照)

この3つのポイントを元に計算すれば、実際に利用できる列（フィールド）の数がわかるってことですね。

たとえば・・・

• １行テキストは276個まで利用可能ですが、数値を5個追加すると1行テキストは274個までしか利用できません。これは行数の制限ではなくサイズの制限です。
• 数値は72個が上限で、日付と時刻を5個追加すると、数値の上限は64個になります。これは行数の制限です。

って書いてもピンとこないかもしれませんが、そういうことらしいです。

ただ、私も勉強不足なので、初期設定にあるタイトルや更新日や作成日、作成者などがどのようにカウントれているのかはよくわかってません。また、GUIDと管理されたメタデータについてもちょっと分からなかったので、存在を無視してます。

この辺は、いずれわかった時に補足したいと思います。

注意：この計算表を使って問題が発生しても責任はとれません。
また、修正・配布は自由にしてかまいません。
さらに、ブロックという単位は私が勝手に作ったり、間違った表現があるかもしれません。
もしかしたら、計算方法すら間違ってるかもしれません・・・検証はしてないので～

作業進捗

SharePointは100項目あるフォームの表示系はMultiViewでほぼ作りましたがレイアウト調整がまだできてません。手書きだと面倒ですね。一から手書きだと無駄な記述はしないけど、TDタグすべてにWidthを指定してくれているので、修正するのが面倒です。Designerに任せるとxsl:templateの構造を破壊してくれるので手動。

入力系はこれからって感じ。一つの項目がトリガーで殆どの項目が不要になるので、表示・非表示の制御をしたいけど、どうすればいいのかなぁ～って感じですね。
問題はこのフォームとセットの4GBファイルのアップロードについて、Visual Studioでワークフローでごにょごにょすればできると思うけど、Visual Studioでってところがさっぱりなので、こっちは進みそうな気がしません。
とりあえず、来月になれば時間が取れるはずなので、ごそごそやってみる予定。

 

リモートアシスタンスの接続サポートツールは、OS判別部とIP取得、招待ファイルのメール送信部はほぼ完成。あとは、招待ファイル作成時のパスワードを考えるのと、ファイルのチェック。メールの宛先選択の辺を考えれば完成。ついでにSharePoint上のリストに保存するようにしてなんか面白いことができないかなぁ～なんて思ってます。

 

ビューで編集したらダメ

SharePoint Designerでフォームをカスタマイズしていた時に気が付いたけど、ビューで編集すると一発でコードが壊れる条件があった。

今やっているのは、チェックシートを記録するためのカスタムリストの表示フォームで、項目数が多いので、ASP.NETコントロールのMultiViewを利用して1画面の表示項目を制限しているんだけど、全体表示もほしいよなぁ～ってことで

グループA
グループB
グループC
グループA,B,C

って感じに分割している。
この場合、<xsl:template>で分割して記述することで重複を防ぐことができる。

<asp:MultiView>
  <asp:View>
    <xsl:call-template name="A"/>
  </asp:View>
  <asp:View>
    <xsl:call-template name="B"/>
  </asp:View>
  <asp:View>
    <xsl:call-template name="C"/>
  </asp:View>
  <asp:View>
    <xsl:call-template name="A"/>
    <xsl:call-template name="B"/>
    <xsl:call-template name="C"/>
  </asp:View>
</asp:MultiView>

こんな感じで作ったフォームをビューで文字を編集したりすると一発でコードを書き換えてくれます。意図しない方向で・・・

このフォームを作っているときから、数回書き換えられてしまってやり直したんだけど、その時はマウスでなんかしちゃったかなぁ～なんて思ってたんだけど、そうじゃなかったんだね～

Designerとかってかなり複雑な処理をこなしているから糞ソフトが～～って思わないけど、ビューで編集したければコードを手書きするのは最低限にした方がいいってことですね。

絶望感・・・

 昨日からSharePoint Foundationの開発環境を構築しており、やっと構築が完了したぞ～って感じです。ハードはPowerEdge R710上に用意した仮想インスタンスのWidnows7です。別にサーバでもよかったけど、ライセンス的にクライアントOSにしてます。（4インスタンスまでライセンスに含まれる。）

開発ツールはもちろんSharePoint DesignerとVisual Studio。
なぜかDomino Designerも入ってるけど・・・

SharePoint Designerは日ごろよく使っているので問題なし。
CPUリソースは2つしか割り当ててないけど超快適。
社内向けサーバよりリソースが割り当てられているいい環境です。
あの超モッサリだったデザインビューがかなりスムーズに入力できるようになりました。とはいっても、最近いじってるフォームはデザイン画面で編集するとぐフォームが壊れてしまうので、コード画面で手入力ですけどね。

問題はVisual Studio 2010。

家ではExpress版を使っているので、ソフト自体は情報量が増えただけで何とかなる。ただ、SharePoint関連の画面を開いた瞬間昔味わった絶望感を味わうことになった。

そう、初めてSharePoint Designer2007を触ったときのあの、「触ったらだめだ」って感じ・・・。

へたに触ると壊すこと間違いなしって感じですね。
まぁ、やりたいことはワークフローである機能を付けるだけなので問題ないけど、なんでもできそうな分よくわからない所が多いなぁ～って感じですね。

ん～～でも、これを使いこなせればいろいろやりたいことが実現できるよなぁ～って思いますよ。使いこなせればの話だけどね・・・

90項目のフォーム

先週から90項目のフォームを準備してるんだけど、項目設定めんどくさい。
しかも、チェックリストなので、項目名が文章になっているので、標準フォームだと改行の嵐。
じゃぁ、別名用意してdesignerで項目名入力すれば～ってやってるんだけど、スクロールが長くて嫌な感じ。

たぶん、利用者もこの項目数を見ただけで、入力する気が失せてしまうような気がします。
まぁ、今は紙ベースでやっているので、インタフェースさえうまくすれば大丈夫だと思うけど・・・

でね、とりあえず縦長なのは見た目も悪いし入力しづらいと思うので、タブでページわけをしようと調べてみたけど、WEBだとタブコントロールってないんだね。そういうページはよくあるので標準で出来ると思ったけど、ASP.NETコントロールにないっす。当然HTMLコントロールやSharePointコントロールにはあるわけないので、代わりになるものないかなぁ～って探してみるとありました。

一つはMultiViewコントロール。そしてWizardコントロール。

Wizardコントロールは、インストールウィザードのように「次へ」と「戻る」およびメニューが自動生成？なので便利そうな感じ。じゃぁ試してみるか～ってフィールドを挿入したら、レンダリングのループ・・・
ただのテキストボックスとかだとまともに動くけど、フィールドはだめらしい・・・たぶんバグ？

MultiViewコントロールはView切り替えボタンを作ったりする必要があるので、すべて手動なわけですが、こっちは素直に動いています。Viewのボタンでカレントボタンを無効化するとこら辺を自動化したいと思ってるけど、今は手書きで動作確認中。

これで、一画面の入力項目数は減らすことはできたけど、見えない項目が増えるので、入力忘れとかの原因になりそうだなぁ～って思った。

項目数が多いと画面設計も大変だなぁ～