(http://planetwilson.blogspot.com/2011/07/sharepoint-2010-colour-calendar-post.html)
をちょこっと改造して、文字も変更できるようにしました。
jQueryなんかでinputタグに文字列を入力したり取得するとき、
inputタグを特定するためにnameやid属性を利用するのですが、
SharePointではnameやid属性はソースでは「ff1{$Pos}」ってかんじの
短い値なのですが、実際に表示されると
「ctl00$m$g_cafe866b_6e5b_416a_bf46_5bad614998d9$ff11$ctl00$ctl00$TextField」
みたいな感じで長~い文字列になってしまって、あれれ~~って感じになります。
でも、該当の<SharePoint:FormField>タグを<div id="hoge">で囲んで、
<div id="hoge">内の<input>を選択するようにすれば楽勝ですね。
jQueryでいえば $("#hoge input") で見事にinputタグを特定できます。
これを使えば、入力補助機能が簡単に作れたりしそうですね。
これに気が付くのにだいぶかかってしまいましたが・・・
初めは長いid値に$ff11って文字列があるので、これを部分一致で検索すれば~って着手したら、
ff1{$Pos}なら$ff11だけど、ff20{$Pos}の場合$ff20_1になったりと一桁と二桁だと動きが違う。
3ケタの場合は確認してないけど、この方法はだめだなってね。
たぶん<asp:>と<SharePoint:>のidとnameはシステム側で競合を防ぐ処理が動くんだろうね。
ドキュメントに沿って作業したのにエラーになるんです!!
Microsoft Volume Licensing Service Senterの[ライセンス]-[製品の一覧]を開き、「すべてのライセンス情報をダウンロード」で保存したCSVファイルをExcelで開いてXMLスプレッドシート2003形式で共有フォルダーに保存したらSystem Center Configuration Managerの資産インテリジェンス インポートウィザードを実行すれば入る予定。
だけどエラーになる。なぜ?って感じでいろいろ調べてみて思ったのが言語の問題?ってことで、ブラウザを英語設定に変えて見たらどうだろう?
ダメでした。
じゃぁ~って国外の情報に手を伸ばしてみると書いてありました。
XMLで保存したときに、「バージョン」列は内容によって型指定が文字列と数値にばらばらになるらしい。
で、さっき作ったXMLファイルを確認してみると、
<Cell><Data ss:Type="String">Office SharePoint Server</Data></Cell>
<Cell><Data ss:Type="Number">2010</Data></Cell>
ってNumberになっています。これをStringに編集して再チャレンジすると成功。
ちなみに、MVLS以外のライセンス情報のインポートでも日本語だとダメみたい。データフィールド名を英語にしたらさくっと入ってしまいました。
日本語で表示されているソフトウェアでヘルプも日本語(機械翻訳だけど)だと、そのまま指示に従ってうまくいくと思ってしまうけど、多言語対応ってだけで、内部は英語なんだよな~
こういうところって結構ワナだよね~
久々の大阪上陸。
前職では大阪が本社だったので回数券を個人で買っても十分使い切れるくらい大阪に行ってましたが、今は大阪は1営業所があるだけ、正直なところ用事がない場所。
久々の新大阪や大阪駅はなんか、工事中が多くてごちゃごちゃしてました。おまけに帰省ラッシュなのか、人も多いし・・・
さてと、今日のセミナーはSharePoint2010の見た目の改善についてとドキュメントライブラリ活用についての2点。標準設定だけで出来る範囲での改善や活用だったのですが、いやぁ~コンサルティングをされている方の説明は説得力がありました。
悪く言えば機能説明なんだけど、ちゃんと設定する理由があるので感心することばかり。早速自社のサイトにも取り入れてみよう!!って思っちゃいました。
Webパーツとドキュメントライブラリだけだったけど、サイト構成や魅力アップのヒントがたくさんありました。
やっぱり、こういうセミナーって参加しないと得られないことって多いですよね。最近はインターネットで検索すれば大概のことは解決できてしまうかもしれませんが、ノウハウってのはお金をかけないと手に入らないってことも忘れちゃだめですね。(今回は無料でしたが・・・)
再来週もセミナーがあるんですけど、今から楽しみです。
System Center Comfiguration Manager 2007 R3をWindows Server 2008 R2で構築する際に気を付けることは、Internet Information Servicesの設定を確実に行っておくこと。
WebDAVの設定がおかしいと、正常にインストールが終わったように見えても、いくつかの設定ができない場合があるみたいです。(今回の教訓)
BITSの設定でmdbを許可する例が書いてありますが、これが必要かどうかは未検証。
たぶん文書からは例と読めるので不要なのでは?と思ってますが・・・
一応エンタープライズCAを構築しているので、ネイティブモードにチャレンジしたけど、証明書の認識がうまくいかず断念。とりあえず混在モードで構築するのが楽ですね。
今回はSCCMを構築するのが目的ではなく、ForeFront Endpoint Protection 2010の構築が目的なので、配布とレポートが動けばいいんです。
で、今回SCCMでハマった原因はWebDAVの設定。
一応ちゃんと設定したんだけど、どっかがおかしかったみたいで、SCCMのセットアップが終わってみるとWebDAV設定が真っ白になってたのに気が付かず、SCCMの設定を弄りまくってたのが解決を遅くしてしまった。まぁ、おかげでその辺の設定の理解度も向上しましたがね。
今は待っているのはクライアントエージェントのプッシュインストール。XPはグループポリシーの設定で問題なくできるようになったけど、Windows7が微妙な感じ。
一応ファイルとプリンタの共有とWMIは許可しているんだけど、OKな端末とNGな端末がある。
たぶん他にも許可しないといけないのかもしれない・・・
来週は、この辺の調整だな~
ちなみに、共有フォルダを使ったインストールなんだけど、アクセス権がないよね。
これって、Windows 2008以降の仕様によるところだと思うんだけど、
ドキュメントに書かれていないですよね。
話は変わって、FEPの感想だけど、ウイルスバスターコーポレートエディションと比べると、使いずらいというか特化していない分弱いですね。
リアルタイムに制御ができないのでなんか心細いし、レポートもなんだかなか~って感じです。CoreCALに含まれるようになるので、ほぼ移行は確定だけど、管理者としては微妙ですね。
管理ノウハウがたまればそれなりに使えると思うけど、ちょっとなぁ~
この Web パーツを表示できません。この問題のトラブルシューティングを行うには、Microsoft SharePoint Foundation と互換性のある Microsoft SharePoint Designer などの HTML エディターでこの Web ページを開いてください。問題が解決しない場合は、Web サーバーの管理者に問い合わせてください。関連付け ID:353a2e2e-b169-4097-b92d-0e3ebf61d68f
入力フォームの内訳は
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項目のフォームを準備してるんだけど、項目設定めんどくさい。
しかも、チェックリストなので、項目名が文章になっているので、標準フォームだと改行の嵐。
じゃぁ、別名用意してdesignerで項目名入力すれば~ってやってるんだけど、スクロールが長くて嫌な感じ。
たぶん、利用者もこの項目数を見ただけで、入力する気が失せてしまうような気がします。
まぁ、今は紙ベースでやっているので、インタフェースさえうまくすれば大丈夫だと思うけど・・・
でね、とりあえず縦長なのは見た目も悪いし入力しづらいと思うので、タブでページわけをしようと調べてみたけど、WEBだとタブコントロールってないんだね。そういうページはよくあるので標準で出来ると思ったけど、ASP.NETコントロールにないっす。当然HTMLコントロールやSharePointコントロールにはあるわけないので、代わりになるものないかなぁ~って探してみるとありました。
一つはMultiViewコントロール。そしてWizardコントロール。
Wizardコントロールは、インストールウィザードのように「次へ」と「戻る」およびメニューが自動生成?なので便利そうな感じ。じゃぁ試してみるか~ってフィールドを挿入したら、レンダリングのループ・・・
ただのテキストボックスとかだとまともに動くけど、フィールドはだめらしい・・・たぶんバグ?
MultiViewコントロールはView切り替えボタンを作ったりする必要があるので、すべて手動なわけですが、こっちは素直に動いています。Viewのボタンでカレントボタンを無効化するとこら辺を自動化したいと思ってるけど、今は手書きで動作確認中。
これで、一画面の入力項目数は減らすことはできたけど、見えない項目が増えるので、入力忘れとかの原因になりそうだなぁ~って思った。
項目数が多いと画面設計も大変だなぁ~
Lotus Notes/Dominoからシステム変更するにあたって、絶対に避けられないデータ移行作業を大幅に楽にしてくれるのがこのSharePoint Converterです。
うちの場合、ほとんどがディスカッション掲示板をベースにしたテンプレートで利用していたので、ディスカッションへのコンバートになります。ってことで、コンバートを試しているのですが、まぁ、無難にコンバートしてくれます。
見た目の違いはあるものの、ほとんどの内容は維持されていて問題なし。
意外といいかもしれない。
しかも、SharePointのディスカッションのほうが、コミュニケーションをするためのディスカッションに近いため、「あぁ、この使い方はディスカッションじゃなかったんだなぁ~」って気付きがあったりします。これを見せると、リストに変更したりする話が自然と出てきそうだなぁ~
でね、まぁ、その辺はいいんですよ。ユーザとの対話の話だしね。
ただ、NotesユーザとActiveDirectoryユーザの変換がね、どうしたものかと悩み中。
定義ファイルは淡々とXMLファイルを作成すればいいんですよ。
Notes漢字アドレス帳からCSV出力して、Excelで加工、XML化の準備して、テキストエディタで置換をやりまくって、XMLを作成すればいいので、面倒だけど、淡々とできる作業。
問題は退職者の扱い。ADを構築した後の退職者は両方のアカウントをもっているので、何とかなるけど、AD構築前の退職者をどうしようかなぁ~とね。標準だとシステムアカウントになってしまうけど、文書によっては結構重要なのがあって、その人が書いたことを記録に残すのも必要だよなぁ~って思う。かといって、Notesユーザ名を表示するのもかっこ悪いし、やっぱりADユーザとして表示させたい。そうなると退職者のアカウントを作らなければならない。でもそれもやりたくない。
では、どうすればいいのか?
やっぱり、これもユーザとの話し合いで決めるのかなぁ~
今日のNotes/DominoからSharePointへの移行打ち合わせは・・・失敗。
まぁ、私も移行について話すのは初めてだったので当然な結果ですが
1年以上WSSを利用し、SharePoint2010も利用している部署の方だったので安心していたというのも原因ですね。
今回の打ち合わせでは一回目ということもあり、サイト構成、権限設定について説明し、Notes掲示板の権限をもとにサイト構成案の提案を行いました。その後、単純にコンバートするのではなく、リストにするものライブラリにするものを考えながら掲示板移行しましょうという話。
サイト構成、権限についてはスムーズに進みましたが、掲示板移行については・・・
Notes掲示板をSharePointのディスカッションに移行しましょ!!って話からてんかいすればよかったと思うのですが、初めからいいものにしましょう!!って欲張ったのが失敗ですね。この場合はどれがいいの?ってやり取りが永遠に続くことに・・・
今思えば、今日の相手はSharePointを利用しているといっても、カスタムリストだけで、ほかのテンプレートは使っていないんです。だから、各テンプレートに合った使い方って知らないんですよね。それなのに私は・・・
今日の反省をもとに考えたシナリオ
今日の相手には申し訳ないけど、いい勉強になりました。
疲れた・・・
いよいよ、移行の時がやってきました。
といっても、自部署は2年近く使っているのですが・・・2010を待っていたり、その他もろもろの体制というか根回しに時間がかかってしまったのが原因なんですけどね。
改めて、ノーツからの移行が難しいなぁ~と痛感しております。(まだ始まってませんが・・・)
製品が違うので、同じことは出来ないことは誰でも知ってるけど、提供する側のこだわりとして、変化を少なく、より使いやすいものへ。ノーツ以上の評価をもらいたいと思ってしまうのです。
それが、ユーザへの負担となることもわかっているのですが・・・
何が難しいかっていうと、一つの掲示板でSharePoint 1サイト分の機能を余裕で実現していることかな?権限設定も細かく設定できるし、ツリー構造の権限なんて考慮しなくてもいい自由度。ノーツの場合はそれが負担だったんだけど、これを移行しようとするとねぇ~。
掲示板をSharePointでどう表現するか?
一部署の掲示板が一つだったら、サイトという単位に展開して~ってとっても簡単だけど、複数掲示板がある場合、掲示板の数だけサイトを作ると使いにくいだろうし、今までと一緒の問題を抱えてしまう。かといって、一つのサイトに複数の目的を持ったリストが存在したときに分かり易さが維持できるのか?まとめる組み合わせ、サイトにする判断。権限・・・
考えれば考えるほど、考えなければならないことが増えてしまいます。
意外と標準テンプレートのディスカッションが一番難しいのかもしれない・・
SharePoint 2010勉強中の問題として、Designerでゴソゴソしているサイトが複数のサブサイトに分散しており、そろそろ整理整頓しないといけないよなぁ~なんて感じております。
とりあえず動作はするけど、参照フィールドはオリジナルの参照先を見てるし変更できない。フォームをDesignerで編集しようとするとデータソースがオリジナル設定を引き継いでいて、修正するまでデザインビューがエラーで表示出来ないのは困ったものです。
また、なんでデータソースの設定が間違っているのに正常動作しているのだろうか?もしかして、データソースはDesigner用の設定?
今週はトラブルとかなかったので、SharePoint Designer 2010べったりでした。
結果はHrsT個人の能力によるものですので、できる方はできると思います。
ビューのカスタマイズ
新規・編集フォーム
表示フォーム
リストテンプレート(ちょっと試しただけ)
って感じです。
フォームの表示系についてはどうとでもなりそうな感じです。
でも、本当にやりたいのは入力系の利便性向上。
こっちはなかなか難しそうです。
やっぱり難易度的に言ってもDominoのほうが低いです・・・
SharePoint Foundationをインストールしようとすると、Serverじゃないとだめよ!って怒られますが、ちょっと設定ファイルを編集するだけで可能になるみたいです。
ということで、先輩方のウェブページの手順を参考にごそごそ・・・
まず、DVDをHDDにコピーして・・・ってexeなんですが・・・
どうもSharepointFoundation.exeを実行すると、C:\Program Files(x86)\MSECache\SharePoint2010ってフォルダが作成されて、セットアッププログラムを起動するみたいです。(64bit専用アプリなのにx86を選ぶのも意味不明ですが・・・)
次にコピーしたファイルの\Files\Setup\config.xmlに追記って・・・
あぁ、同じファイルがある。とりあえず追記
では・・・
って作業を始めたんですが・・・
大変申し上げにくいのですが・・・
MSDNライブラリに書いてありました。(・_・;)
他の解説者がきれいに纏めていただいてたので本家を見なかったのが敗因でした。
基本的な部分で失敗してました。
そして、物理メモリーをちゃんと搭載していなかったので・・・ガリガリ言い出しました・・・
ん~~確認したいことだけ確認して消そう。
SharePoint Designer2010でカスタムリストのビューはカスタマイズしない方針で進めようと思っています。
ってのも、ビューをカスタマイズしようとするとわかると思うのですが、いくつかのテーマ用の設定が記述されており、引き継いだ人が苦労するのかなぁ~と思ったからです。
たぶん、ビューのカスタマイズ要望は非常に多いと思うのですが、ビューだけはやらない方がいいんじゃないかなぁ~と本能的に感じました。
まぁ、まだ理解度が低いという点もあるのだと思いますが、メニューで設定できる範囲やフィルターの設定程度に抑えておいた方が良いと思います。
いじる場合は、しっかりと仕様書を記録しておかないと、バージョンアップや再編集時に苦労しそうな予感。
最低限の記述しかないビューを作成できれば話は別だと思いますけどね~
SharePoint Designer 2010と格闘し始めてだいぶ経ちましたが、今日はちょっと進展がありました。リストビューでほかのカスタムリストの集計がうまくいかず断念していたのですが、フォームで別のカスタムリストの表示ができることを確認しました。
これができると、表現の幅が広がります。
私がやっているカスタマイズはDesignerを利用しているので、WYSIWYGでいろいろできるのですが、ほとんどソースをいじっています。
XPathはさすがに編集ツールを使っていますけど・・・。
で、最近感じていることはXMLの理解を深めるとカスタマイズの幅が広がるということ。
SharePoint Designerを極めるにはXMLは必須ですね。
あと、SharePointのタグやコマンド群なんだけど、こっちはリファレンスの読み方がいまいちわからないので、まだまだって感じですね。これが使えるようになればさらに自由度が高くなりそうです。
とりあえず、表示フォームについてはあともう少しで何とかなりそうな感じ。
問題は新規フォームと編集フォーム。そしてビューだ。
合わせてカスタムリストでディスカッションを作れるようにならないといけないなぁ~
これらができれば、Dominoの掲示板の過半数を同等機能を維持しつつ移行することが技術的に可能になります。
実際には、棚卸を合わせて行うので、そんなにカスタマイズをするつもりはないけどね
SharePointの勉強をしていて思ったこと。
開発環境に要求するスペックはSharePointが格段に高い。
DominoのXPagesは使ったことないのでわかりませんが、LotusScriptなどを使ったアプリ開発は多少低スペックでもストレスなくできましたが、SharePointDesignerだと快適に作業しようとすると今どきのパソコンが必要ですね。VisualStudioでの開発だとSharePointサーバを同居させないといけないのでより要求が高くなってしまいます。
職場のメインPCはLet'sNote CF-W5なのですが、SharePointDesignerがモッサリでつらいです。ちょっと触ったら、画面更新でちょっと待って・・・って感じです。
私の中での評価はまだまだDominoの勝ちですね。
最近、SharePointDesignerでいろいろ試しています。
とはいっても、まだ表示用のフォームを触ってるだけですが・・・
将来のDominoアプリ移行の際に向けた準備ですが、Domonoで簡単に表現できてたことがうまく実現できません。
製品が違うので仕方がない部分は理解していますが、今までチェックボックスで表現していたものを実現できないというのも、利用者にとっては大きな問題じゃないかなぁ~って思います。もちろん、チェックボックス表現より視認性に優れた良い案があればいいのですが、そういうのも特にないし・・・(表現できないのは技術的ではなくスキル的にです)
どうやったら同じ表現ができるのかなぁ~って日々頭を抱えています。
ある程度、表現できたら、それをSharePointらしいレイアウトに修正して、違和感を感じないようにしたいと思っています。
ただ、Dominoと違ってバージョンアップに対する不安感は非常に大きく、どこまで許されるのか?というのは分からないですね。Dominoならほぼ100%動作するのですが、そういう実績もないSharePointはどのくらい互換性があるのか?維持できるのかってまだ、わからない所が多いです。
そして、何よりドキュメントが全く・・・。DesignerでSharePointコントロールを設置しても、設定方法がわかりません。
いったい、どこに説明が書かれているのでしょうか?
新NISAが始まり、投資信託を始めて1年間 誰もが気になる「儲かるの?」1年の答えが出ました。 投資状況(12月31日時点) 配当金 1,044円 投資原本 356,608円 評価損益 +28,406円(+7.96%) 投資内容 投資信託 57.7%(+9.33...