[font="Tahoma"][rtl]
سلام دوستان
من داخل TbGridView چنین فیلتری دارم و نمی دونم چطور میتونم این رو داخل تابع search مدل بنویسم که داخل view اصلا چیزی مثل اسم فیلدهای دیتابیس رو نداشته باشم
[/rtl][/font]
array('name' => 'CREATOR',
'filter' => CHtml::listData(JTUser::model()->findAll(), 'USERID', 'USERNAME'),
'value' => 'JTUser::Model()->FindByPk($data->CREATOR)->USERNAME',
),
[font="Tahoma"] [rtl]
نمیدونم متوجه منظورت شدم یا نه، ولی اگر درست گرفته باشم، کاری که میتونی بکنی اینه که تمامی اعمال با دیتابیس رو ببری تحت یک سری متد در مدلت و یا یک کلاس مجزای دیگه، سپس یا مستقیم از اونها در view استفاده کنی و یا اینکه برگشتی اونها رو بریزی در یک متغییر و اون متغییر رو هنگام render پاس بدی به view برای مثال یک همچین چیزی:
در مدلت میتونی داشته باشی:[/rtl]
public function getAllUsernameArray() {
return CHtml::listData(JTUser::model()->findAll(), 'USERID', 'USERNAME')
}
public function getUsernameById($id) {
return JTUser::Model()->FindByPk($id)->USERNAME;
}
[rtl]بعد از اون در view فقط همچین چیزی داری:[/rtl]
'filter' => $this->getAllUsernameArray(),
'value' => '$this->getUsernameById($data->CREATOR)',
[rtl](البته کد رو تست نکردم شاید نیاز به اصلاح داشته باشه.)[/rtl]
[rtl]و یا اینکه در action اینطور بنویسی:[/rtl]
$allUsername = $this->getAllUsernameArray();
$this->render('view', array('allUsername'=>$allUsername));
[/font]
[font="Tahoma"]
[rtl]و سپس در view تنها با یک متغییر کار کنی وبدین صورت بنویسی:[/rtl]
'filter' => $allUsername,
[rtl]
امیدوارم تونسته باشم سرنخی داده باشم[/rtl]
[/font]
[rtl][font="Tahoma"]
سلام
ممنون از پاسختون
الان اینجا یه سوال برام ایجاد شد، وقتی شما تابع می نویسی عملا کد database چطوری میشه معمولا این دیتا رو با یه join میشه گرفت تابع مثل این میمونه که شما برای هر row یه query می خواید بزنید
واقعا اینجوریه یا خودش با توجه به توابع query درست می کنه؟
و بیشتر سوالم اینکه که چرا yii از MVC طبعیت درستی نمی کنه
حداقل تو ظاهر برام عجیبه که بیشتر view مستقلا از model داره data میگیره
اصلا mvc برا اینه که بتونی کدهاتو بصورت ماژول بنویسی یعنی که حالت plug and play داشته باشی من این وصل شدن model رو به view اصلا درک نمی کنم
خوب zend2 هم همین optimization رو انجام داده و توسعه سیستم رو سرعت داده ولی mvc رو نبرده زیر سوال بنظرم yii در عین اینکه توسعه رو خیلی ساده کرده ولی خیلی اوضاع رو بعضی جاها پیچیده می کنه
[/font][/rtl]
[right][rtl]
[font="Tahoma"]روش آقای نابی در کل درسته اما چندتا اشتباه توی کدهاشون هست که مطمئنم سهوی بوده. اولا اون دو تا تابع static باشن بهتره. ثانیا توی دو تکه کد بعدی به جای $this باید از اسم کلاس مدل استفاده کنید. این از این.
در مورد قسمت اول صحبتون بله با این کد به ازای هر ردیف یک query زده میشه اما چرا از همون اول نتیجه join شده رو به عنوان dataprovider به grid نمی فرستید؟ اینجوری در کل دو تا query بیشتر زده نمیشه یکی برای فیلتر یکی هم برای کل ردیفها
در مورد قسمت دوم صحبتتون من با شما کاملا موافقم نباید view و model به طور مستقیم به هم وصل باشند اما این تقصیر yii نیست بلکه برمیگرده به کدی که شما می نویسید. یعنی شما حتی میتونید داخل view کد sql بزنید اما فریم ورک به شما هیچ اروری نمیده اما این شما هستید که باید رعایت کنید. در مورد mvc هم حتی خود این الگو منتقدان زیادی داره و بعضیها معتقند همون 2 تا تابع هم نباید داخل model تعریف شن بلکه داخل مفهوم جدیدی به اسم ViewModel قرار بگیرن که در نهایت الگوی MVVM ابداع شد.
خلاصه اینکه yii شما رو مجبور به انجام کاری نمیکنه و فقط راه درست رو بهتون نشون میده[/font]
[/rtl]
[/right]
[rtl]
[font="Tahoma"]
سلام دوباره و ممنون از آقا فرید
با توجه به صحبت شما یه google کردم دیدم با تعریف rule های لازم و استفاده از with میشه در تابع compare تو مدل همون join که میگین تعریف کرد و هر فیلدی رو کشید بیرون
در کل جالب بود
تو سایت های مختلف جوری بود که من فکر می کردم value فقط تابع می گیره
ممنون
[/font]
[/rtl]
[font="Tahoma"] [rtl]
درسته کد فعلی، برای هر رکورد یک کوئری میزنه. این کد خودتون بود و من فقط سعی کردم اصلاحش کنم. برای اون منظور که خودش join بزنه باید کد جور دیگه ای اصلاح بشه که اون یه سوال دیگه میشه.
این به شیوه برنامه نویسی خود ما مربوط میشه، الان شما در همون پست قبلیم، روش دومی که نوشتم رو دوباره نگاه کن، همه اتفاقات داره در action میافته و در view شما فقط با یک متغییر سرکار دارید که این همون چیزیه که مد نظر شماست.
[/rtl] [/font]
[font="Tahoma"][rtl]
آره، همونطور هم که نوشتم کد رو تست نکردم و همینجوری نوشتم… البته درمورد static یا public بودن بستگی به مورد استفادش داره که خب جای بحثش اینجا نیست…
از این حرفت خیلی خوشم اومد و دست گذاشتی روی دل من! الان مدتهاست که روی یک pattern اصولی موندم. کلاً مبانی design pattern خیلی لایه ها رو معرفی کرده که خودم به نوعه بعضی شون مثلاً لایه های service و repository یا حتی جدا سازی bussiness model از view model ها رو تا حدودی رعایت میکنم که این باعث گستردگی کدهام شده به شکلی که احساس میکنم این استانداردها دست و پاگیر شده برام! ولی هنوز دو دول هستم که به همین سبک معماری پیش برم یا به سادگی و راحتیه همین لایه های فعلی yii که الان همه دارن ازش بهره میبرند برگردم و در همین چهار چوب جلو برم.
حالا ببینیم چی میشه 
نبی
[/rtl][/font]
[right][rtl]
[font=“Tahoma”]حس هامون مشترکه 
فکر کنم این برمیگرده به همون بحث افراط و تفریط که توی هیچ چیزی خوب نیست. توی چند تا از ویدیوهای آموزشی و کنفرانسها که موضوعشون design pattern بوده اول صحبت هاشون میگفتن که انتخاب یک الگوی مناسب تا حدود زیادی به سلیقه و تجربه اون فرد یا شرکت بستگی داره یکی با MVC راحتتره، یکی با MVVM، HMVC و …
البته MVC محبوبیت خاص خودش رو داره تا جاییکه چند سال پیش مایکروسافت هم یک پیاده سازی رسمی از اون بیرون داد که خیلی هم طرفدار داره
من هم مثل شما فعلا الگوی محبوبم MVC هست تا دیگه قسمت چی باشه [/font]
[/rtl]
[/right]
[rtl][font="Tahoma"]اتفاقاً همین بحث افراط و تفریط اشاره خوبی بود، دوستی وقتی داشت برای هر چیزش یک مدل و سرویس و … میساخت (مثلاً برای یک خط ساده یک کلاس میساخت و…) گفتم واقعاً لازمه همچین کاری که یک پروسه اضافه به برنامه تحمیل کنیم و وقت برنامه نویس رو هم هدر بده؟! گفت هر کاری یه هزینه ای داره و اگر میخوای کدت توسعه پذیری راحت تری داشته باشه که هر کسی روی لایه تخصص خودش متمرکز باشه مجبوری اینکارو بکنی و هزینشو پرداخت کنی!
موضوع اینه که برخی از این الگوها دارن به یک استاندارد تبدیل میشن و برخی ادعا میکنند چشم بسته باید اونها رو اجرا کرد. مثلاً استفاده از لایه repository ، تا این اطمینان رو بده که اگر فردا خواستید مثلاً بجای AR از روشهای دیگه استفاده کنید، نیازی اصلاح تمام کدها نباشه و تنها کدهای اون لایه رو اصلاح کنید. این درسته ولی واقعاً تمرکز بخشهایی که به کوئری و دیتابیس مربوط هست در یک لایه کار ساده ای نیست و در yii در برخی جاها واقعاً کد رو گسسته میکنه. مثلاً با همچین معماری من نمیدونم یک چیزی مثل CActiveDataProvider رو توی کدوم لایه باید استفاده کنم (یک موجودی که با اون همه پارامتر ورودی و خروجی، معلوم نیست آخرش چی چیه و تو چه لایه ای باید استفاده بشه) این نقطه ایه که آدم احساس میکنه در حین پیاده سازی و رعایت همه اصول، یک جونور بی شاخ و دم مثل CActiveDataProvider میاد و همه محاسبات رو بهم میریزه و آدم سر یک دو راهه قرار میگیره که من به کجا دارم میرم؟!!
این فقط یک مثال بود و در خیلی جاهای فریم ورک این احساس رو دارم.
ضمناً به قول یکی از دوستان، در این مبانی، MVC تنها یک لایه از design pattern به حساب میاد و سایر لایه ها نیز در کنار اون حتماً باید وجود داشته باشند.
[/font][/rtl]