CALENDAR
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30     
<<Back 2024年04月 Next>>
LOGIN
現在のモード: ゲストモード
USER ID:
PASSWORD:
NEW ENTRIES
RECENT COMMENTS
■ 奥脇という名前の由来
└ s.okuaki(02/27)
└ hide okuwaki(11/23)
■ ブログを引越しします。
└ okugaku(03/07)
└ yurika(03/05)
└ OFFICE DOYU (03/03)
RECENT TRACKBACK
■ 岸和田観光農園(いちご狩り)
└ 現役栄養士のお仕事日記(04/25)
■ やっと終わった
└ MY Favorite Things(03/19)
■ PDA版にのりかえ
└ 大阪でWEBサイトをプロデュースするということ(01/06)
CATEGORIES
ARCHIVES
LINK
PROFILE
■ 奥脇学(2088)
POWERED BY
script by Blogn+
skin by vivid*face
OTHER
■ RSS 1.0
■ 処理時間 3.633226秒
SEARCH
体重計

HTML_QuickFormとか
HTML_QuickFormとか使ってて思う。(勉強会のページも見てね!)
確かに一度使うと次も使いたくなる。実装が簡単だと思うから。
でも複数項目のバリデートなんかちょっと複雑な事をしようと思うと、ちょっと大変。
HTML_QuickFormも使い方を決めて、ある程度使用するときのパターン化を自分なりに確立してから出来る部分、出来ない部分の判断をするようにしている。
HTML_QuickFormもじっくり見るとかなりの事はできるようだが、機能をいっぱい使ってより高度に、複雑に作ってしまうと、単純、簡単にすぐできる!!ってところから外れてしまう感じがするので、現状では簡単部分を適用して、複雑な部分はベタという感じでつくることが多い。でも裏技的に、仕様自体をHTML_QuickFormにあわせるようにすれば、複雑な部分はほとんど無くなるのでHTML_QuickFormの機能をフルに使って組むことが出来る。
そもそも、顧客サービスのためには「仕様」として決められた物を確実に提供すること。が全てではなくて、「保守性」「工数削減」の意味からも、逆提案をどんどんしていって作りやすく、メンテしやすいものを提供する責務があると思う。しかし大概の開発者は、「顧客仕様絶対至上主義」を前提として考えている。
お客さんがシステムのプロなら問題ないが、通常そんなことはないので、ある程度こちらのプロとしての提案も必要ではないか?いやいや、それは私達の責務だと考えている。

| もろもろ::技術ぽい話 | 11:24 PM | comments (2) | trackback (x) |
よろしくねー。
| okugaku | EMAIL | URL | 2005/11/16 11:05 PM |

複数の項目のバリデートはaddFormRuleを使えばできるってことを確認しました!暇があればまとめて勉強会のページにUPします。
| ic | EMAIL | URL | 2005/11/16 11:01 PM |











<<NEXT  PAGETOP  BACK>>