Jump to content
php.lv forumi

MVC Pagination?


ezis

Recommended Posts

hei, kā tiek realizēta vienkārša pagination iespēja iekš mvc? Iekš C es iegūstu datus no M un tad tur pat apstrādāju ar pagination vai arī tā visa gudrība ir iekš M? Vai arī nav īsti nozīmes kā realizē? Piemēram, ja pirmais variants, tad tas nebūs lēnāk, jo tiek iegūta kaudze ar datiem? Tādu acij tīkamu piemēru es neatradu. :/ Nebalstos uz nevienu gatavu ietvaru, mācību nolūkos taisu savu.

Paļdis!

Link to comment
Share on other sites

Tas, vai tas viss notiek kontrolerī vai modelī... ātrumu nemaina.

 

Es to realizēju kontrolerī.

 

Labojums:

 

Kontroleris:

 

public function action_foobar() {

   $pagination = Pagination::factory(array(
       'total_count' => $model->get_count(),
   ));

   $this->response->body = View::factory('foobar')->set('pagination', $pagination->render());

}

 

Modelis:

 

public function get_count() {

   return DB::select(DB::expr('COUNT(`id`) AS `count`'))->from('whatever')->execute()->get('count');

}

 

Skats:

 

echo $pagination;

 

Labojums #2:

 

Par to ātrumu. Vienīgais, modeli vēl ir jāizsauc... bet kontrolerī Tu jau esi. Bet, jebkurā gadījumā, ātruma ieguvums ir tik neliels, ka nav. :)

 

Labojums #3:

 

Lūk tā to ir realizējusi Kohana. Īsti neesmu drošs, vai attiecīgais koda gabals - Pagination::factory() - ir jāizsauc kontrolerī vai modelī. Lieku kontrolerī un neviens nebļauj! :D

 

Es Tavā vietā izveidotu ko līdzīgu tam, ko Kohana ir izveidojusi. Modeli 'pagination', kuru Tu vari izsaukt jebkurā vietā, padot šamam konfigurāciju (ja nepieciešams) un tad, pēc, piemēram, 'render()' metodes izsaukšanas, tiek sagatavots jau gatavs lapošanas HTML. Konfigurācijā vari padod skatu, kurš būs kā izskats 'pagination', 'limit', 'offset' utml. lietas. :)

Link to comment
Share on other sites

Intereseanti kā gan godājamais moderātors pie šāda secinājuma nonāca, es tiešām gribētu zināt kur viņš šadu informāciju izlasīja.

Cik zinu ka Martins Fovlers tādas muļķības rakstījis nav?

 

Parasti gan MVC elementu uzdevumi ir šādi :

Model
- domeina biznesa logika

View
- presentācijas loģika

Controller
- Model un View stāvoklā maiņa

Tātad, tieši kāds kur ietilpst jēdzieni "lapa" un "elementu skaits lapā" ?

"Lapa" ir tomēr, IMHO, koncepts kas iederās prezentācijas loģikā.

 

Protams šis viss sadalījums ir pieejams tikai tad, ja Model nav aizstāds vienkārši ar nespējīgu ORM un View nav kļuvis par sinonīmu templeitam.

 

P.S. Visi php fremewokr'i, kuru aprakstos is svinīgi paziņots, ka viņi realizē MVC arhitektūru, melo. .

Klasiskais smalltalk MVC nav web'ā realizējams ( un nē, MVC nav "stiepjams" jēdziens, sasaiste starp struktūrām ir ļoti precīzi definēta),

jo Model un View is savā starpā saistīti caur Observer patternu. Tā vietā web'ā tiek pielietoti citi arhitektūras patterni:

 

atšķiras no klasiskā MVC ar to, ka datu plūsma starp M un V ir apgriezta.

View izsauc metodes uz Model un pats pieprasa datus.

M un V savstarpēji komonicē caur VM. ViewModel funkcionē kā saskarne caur kuru View pieprasa datus no Model

un atbild par reālās informācijas konvertēšanu formā, kas saprotama View.

M un V savāstarpā nekomunicē, Presenter structūra veic pieprasījumus Model objektam,

noformē datus un padod tos View. ( visizplatītākais starp php frameworkiem )

 

P.P.S HMVC arhitektūrai patiesībā ir ļoti limitēts sakars ar MVC. Šī arhitektūra ir daudz ciešāk saistīta ar PAC principiem.

Link to comment
Share on other sites

ohoo. Nezināju, ka MVC ir tik strikti noteiktas prasības. Domāju, ka MVC skaitās tad, ja dati, ļoģika un prezentācija ir nodalīti viens no otra un tas arī viss.

Mana bēda.

Nevaru izvērtēt pie kā pieskaitīt manu veidojumu. Jo ir līdzīga iespēja kā HMVC. Es iekš C varu izsaukt citus C un iegūt atgrieztos rezultātus. Iekš V es nevaru izsaukt M un nevaru izsaukt C. V tikai iegūst padotos datus un saliek iekš html tur, kur tas nepieciešams.

 

"Lapa" ir tomēr, IMHO, koncepts kas iederās prezentācijas loģikā.

Jā, bet tomēr līdz lapai jānonāk kaut kā, tātad caur C? C izdomā kurus ierakstus attēlos un tad V tiek saņemts attēlojamais saturs un tālāk attēlo?

 

btw, mana iespēja iekš C iegūt saturu no citiem C, tas būtu V uzdevums vai tomēr C?

 

Man iekš galvenā Controller ir izveidota šāda funkcija! Tā es iegūstu jau gatavu daļu no aplikācijas. Tad tikai es rezultātu pārsūtu uz attiecīgo vietu iekš view. Šāds piegājiens ir aplams?

function getAppContent($app, $ctrl, $act, $params = null){
$d = new easyApp_Dispatch($this->registry);
$d->setApp($app);
$d->setController($ctrl);
$d->setAction($act);
$d->setParams($params);
# lets run ;)
$d->runModel();
ob_start();
$d->runController();
$d->runAction();
return ob_get_clean();
 }

Edited by ezis
Link to comment
Share on other sites

wintermute grib lēkt augstāk par savu pēcpusi.

Ir, ir tas MVC, ko lielākā daļa lieto un sauc webā par MVC. Vienkārši wintermute grib runāt par kautkādu smaltalk MVC, bet mēs runājam par web aplikāciju MVC patternu. Viņš vienkārši domā, ka, ja viena lieta nosaukta par MVC, tad citas lietas tā nedrīkst saukt. Bet diemžēl viņam nepieder īpašumtiesības uz šo nosaukumu un, ja mēs WEB izstrādātāji gribēsim savu paternu, kurš sadalīts 3 daļās saukt par MVC, tad tā arī sauksim, jo tas vislabāk raksturo tā uzbūvi. Un laiks arī saprast, ka ja web-a kontekstā tiek lietots MVC, tad tas ir MVC patterns web kontekstā, nevis smalktalk kontekstā.

Savukārt, MVVM un MVP patterni webā prakstiski ir realizējami tikai klienta pusē javascriptā un nekādi neviens no lielajiem servera puses PHP frameworkiem nav, ne MVVM, ne MVP.

 

Un HMVC ir tiešs sakars ar MVC, H - hirearhāls, kas nozīmē, ka jebkurš kontroleris var izsaukt citu kontroleri, tādā veidā veidojot hirearhālu struktūru, tas, ka līdzīgs (bet tomēr niansēs atšķirīgs) paterns citā softa izstrādes nozarē saucas PAC, nenozīmē, ka mums webistiem arī viņš tā jāsauc. Mums daudz labāk der HMVC, jo tas precīzāk rakstuto patterna ideju.

Edited by codez
Link to comment
Share on other sites

Nu ja. Tu kā "WEB izstrādātājs" visu ko izperē sauc par MVC, jo ir taču tik kruti lietot MVC un visiem ir noteikt jālieto MVC.

Bez MVC jau nu iztikt nekādi nevar.

 

Tai pat laikā izskatās, ka tev nav ne mazākās nojausmas, kā tiek veidotas aplikācijas pēc nedaudz atšķirīgiem argitektūras principiem.

Drošvien par MVVM vispār pirmo reizi padzirdēji lasot par backbone.js frameworku.

FYI, server-side web framework'i, kuru reklamējas piesaucot MVC, lieto MVP un praktiski tikai ekskluzīvi šo pattern.

CodeIgniter, CakePHP, Yii, Ruby on Rails, you name it.

Link to comment
Share on other sites

Mjā, kā tad.

 

no wiki:

"Model-view-presenter is a derivative of the model-view-controller software pattern, also used mostly for building user interfaces."

 

Tu nemaz nevari servera pusē uztaisīt UI, kādā veidā tu iztēlojies servera pusē lietot MVP patternu.

 

"Additionally, the View is responsible for handling the UI events (like mouseDown, keyDown, etc), which used to be the Controller's job."

 

Kā tu iztēlojies servera pusē mouseDown un keyDown eventus? Servera Admins spaida pogas? nesmīdini. WEBā šo paternu var realizēt tikai klienta pusē, bet nekādi ne servera pusē.

 

 

 

Un atkārtoju tev vēlreiz. Nejauc MVC klientu puses aplikāciju patternu ar MVC serveru puses aplikāciju patternu, tās ir dažādas lietas. Lai gan pamatkoncepcijas ir līdzīgas, taču daudzais nianšu atšķirību klāsts, padara tās pietiekami atšķirīgas, lai nejauktu kopā.

MVC pamatā ir trīs nodalītas daļas un tas ir kopīgs kā klienta puses MVC, tā servera puses MVC patternā, taču, piemēram, klientu puses patternā VieWiem ir daudz plašāka funkcionalitāte, jo tie veido UI, kamēr servera puses MVC patternā view-am ir tikai un vienīgi jāuzģenerē HTML, XML, json. Līdz ar to lielākajā daļā gadījumu servera puses MVC pilnu view-a funkcionalitāti pildīs arī līdz templeitam vienkāršots views, jo pilnībā nodrošinās visu prezentācijas loģiku, kas nepieciešama servera puses MVC aplikācijai. Vēlreiz atkārtoju, nejaukt klienta puses MVC, ar servera puses MVC.

Edited by codez
Link to comment
Share on other sites

Wintermute, slikta diena? Ko cepies? Es cenšos palīdzēt autoram kā varu. :)

 

Labāk pastāsti, kā, MVC arhitektūrā (Smalltalk interpretācijā), var implementēt 'pagination'? Atbildēt uz ezis jautājumu?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...