Trīs manis rakstītas klases

[coderpp]

Lieta tāda, ka zemāk ir ievietotas adreses uz 3 manis rakstītām klasēm. Ko sagaidu no Jums? Kritiku, ieteikumus, padomos kā nedarīt vai arī kā labāk darīt.

 

view.class.php

layout.class.php

form.helper.php

Edited July 28, 2010 by coderpp

[codez]

1)Es parasti controller-a un view-a klases apvienoju vienā, jo manā izpratnē ar view-u sazinās tikai un vienīgi controller-is un to dara lielākajā daļā gadījumu, tāpēc neredzu jēgu tos atdalīt.

 

2)Tāpat parasti izmantoju nevis maģiskās __get __set metodes, bet gan ArrayAccess implementāciju, tā rezultātā datus templeitam padodu $this['title']="Hello World", nevis $this->title="Hello World". Priekšrocība tam ir tāda, ka klases propertiji nejaucās ar templeitam padodamajiem datiem.

 

3)Ļoti bieži kopējais layout-s nav pliks layout-s, bet satur kādu mainīgu informāciju, tā var būt lietotāja jauno vēstuļu skaits, u.c., tāpēc es parasti daru tā, ka arī layout-am ir controller-is, kurš attiecīgi nodrošina datu apstrādi priekš pamat layout-a. Patiesībā man layout-s būtībā ar neko neatšķirās no parasta controller-a ar template-u, tikai atšķirība tā, ka parastam controller-im viņš ir norādīts kā parent-s, bet pats layout-a controller-is satur parametru, kurš norāda, ka viņš nav pa tiešo pieejam request-am.

Edited July 28, 2010 by codez

[101111]

Paskatījos formu helpera klasi. Pa lielam protams man nav kur piekasīties, vienīgi pietrūkst metodes, kas uzģenerē label tagu, jo es pats personīgi labeļus lietoju sakarā ar formām.

 

Vēl man neškiet labi, ka viss HTML kods tiek salīmēts kopā pa daļām un tad vienā brīdī izvadīts. Labāk būtu ka katrs metodes izsaukums izvadītu savu HTMLu.. Jo nu pagrūti ir tagad uztaisīt formu, saliekot input laukus sarakstā vai tabulā vai kā labāk katram patīk

Edited July 28, 2010 by 101111

[coderpp]

Paskatījos formu helpera klasi. Pa lielam protams man nav kur piekasīties, vienīgi pietrūkst metodes, kas uzģenerē label tagu, jo es pats personīgi labeļus lietoju sakarā ar formām.

 

Vēl man neškiet labi, ka viss HTML kods tiek salīmēts kopā pa daļām un tad vienā brīdī izvadīts. Labāk būtu ka katrs metodes izsaukums izvadītu savu HTMLu.. Jo nu pagrūti ir tagad uztaisīt formu, saliekot input laukus sarakstā vai tabulā vai kā labāk katram patīk

 

Par label piemirsu pārrakstot. :( Man jau bija šis klases kaut kā sarakstītas un vienkārši pārrakstu pielikot šo to klāt. Pats arī bieži lietotju label-us.

Ir iespējams izvadīt - echo $forma->input('vards');

 

Man kaut kā negribas apvienot.

 

1)Es parasti controller-a un view-a klases apvienoju vienā, jo manā izpratnē ar view-u sazinās tikai un vienīgi controller-is un to dara lielākajā daļā gadījumu, tāpēc neredzu jēgu tos atdalīt.

 

2)Tāpat parasti izmantoju nevis maģiskās __get __set metodes, bet gan ArrayAccess implementāciju, tā rezultātā datus templeitam padodu $this['title']="Hello World", nevis $this->title="Hello World". Priekšrocība tam ir tāda, ka klases propertiji nejaucās ar templeitam padodamajiem datiem.

 

3)Ļoti bieži kopējais layout-s nav pliks layout-s, bet satur kādu mainīgu informāciju, tā var būt lietotāja jauno vēstuļu skaits, u.c., tāpēc es parasti daru tā, ka arī layout-am ir controller-is, kurš attiecīgi nodrošina datu apstrādi priekš pamat layout-a. Patiesībā man layout-s būtībā ar neko neatšķirās no parasta controller-a ar template-u, tikai atšķirība tā, ka parastam controller-im viņš ir norādīts kā parent-s, bet pats layout-a controller-is satur parametru, kurš norāda, ka viņš nav pa tiešo pieejam request-am.

 

1) Man kaut kā negribas apvienot.

2) Nesapratu, kas tur īpaši var jaukties. Vai vēl kādi plusi tādai metodei?

3) Es daru tā, ka ir kontrolieris, kurā konstruktorā tiek izveidots kaut kāds defaultais layouts + norādu visur nepieciešamos css un js failus. Beigās destruktorā šo layoutu zīmēju. Šo kontrolieri nevar izsaukt pa tiešo. Piemēr sākumlapai taisu kontrolieri indexController kas ekstendo Controller klasi. Tajā veidoju tad tālāk funkcijas, defaultā index, kas parasti izvada tikai kaut kādus datus. Šajās funkcijās tad arī ielādējo skatus. Par to kā darboties ar tādiem datiem vēl neesmu aizdomājies. Kaut kā tā. Gan jau kaut kad, tās arī sarakstīšu, tad arī iemetīšu te lai var arī par tām padiskutēt.

[mefisto]

Izskatās, ka sākumā tu mēģināji apgūt MVC, bet kaut kādā brīdī pārdomāji.

Anyway.

 

Apvienot noteikti nevajag. Tas, ka codez nesaprot, kāda ir MVC komponenšu nozīme, nav īsti attaisnojums.

View parasti ir aplikācijas daļa, kas atbild par satura attēlošanas loģiku un piekārto vajadzīgos templeitus.

 

1 & 2. divas bezjēdzīgas klases, kas pilnīgi neko nedod.

 

3. Un tieši kāda ir jēga no 100-un-1'as funkcijas tur ?

 

Es tasītu tā , lai pielietojums būtu apmēram šāds :

use System\Base\Factory;
// stuff

$form = Factory::factory('login');
$form->add_field( 'password' ,  
                  array( 'name' => 'pass',
                         'label' => 'Your password',
                         'rules' => array( 'required' , 'strong' )
                   ));

Kur

namespace System\Base;
use System\Forms;
use System\Validators;

class Factory{
   public static function build_form( $type ){

       $type      = ucfirst ( $type ) . '' ;

       $class     = "Forms\\${type}_Form";
       $validator = "Validators\\${type}_Validator";

       return new $class( new $validator );

   }
}

 

 

... nenotestēju vai nav drukas kļūdas.

 

 

P.S. : silti iesaku palasīt par __autoload() un namespace

[coderpp]

Nemēģināju, joprojām to arī daru. Negribas mācīties citus/gatavos frameworkus. Doma izveidot, kaut ko minimālu uz kā varētu nedaudz vieglāk/ātrāk turpmāk veido mājas lapas.

 

Kāpēc nedod? Manām vajadzībām der.

 

Kāda jēga? Jēga tāda, ka lai izveidotu formas, man turpmāk nebūs jāraksta tie visi xhtml tagi. Manuprāt dzīve uzreiz vieglāka. :)

 

Nepatīk man namespace pieraksts, tos kaut kā negribu lietot. Par autoload esmu jau lasījis. Taij nelielajia daļai, kas man ir esmu izveidojis autoload klasi. Ārāk vai vēlāk tā nonāks arī šeit.

 

Man arī nepatīk statiskās funkcijas. Kāda jēga no viņām vai drīzāk kāds labums ka viņas lieto?

[mefisto]

Tas ko tu sauc par "View" ir vienkārši primitīvs templeits.

 

Kāda jēga ir uzrakstīt 4 funkcijas ( input , password, file un textarea ),

kas dara vienu un to pašu darbībum, tikai ar citādāk nosauktiem parametriem ?

Ja tu būtu vismaz pamēgināji iebraukt tajā koda fragmentā, ko es uzrakstīju, varbūt tu būtu to apjautis.

 

And again .. varbūt palasi par to, ka autoload un namespaces lipinās kopā, pirms gvelz.

 

http://en.wikipedia.org/wiki/Factory_method_pattern

[coderpp]

Man ar to primitīvo pietiek.

 

Nu ok, tās f-jas var apvienot. Bet tad būs papildus parametrs type. Nafig man tas vajadzīgs? Es taisu tā, lai ir ērtāk man to lietot.

 

Ko tu uzbāzies ar tiem namespace? Nu neintersē man viņi tagad.

 

Ko tad es gvelžu? Man autoload ir tikai un vinigi priekš klašu automātiskas ielādēšanas. Ar to pietiek. Vari lipināt kopā visu ko vēlies.

[codez]

2) Nesapratu, kas tur īpaši var jaukties. Vai vēl kādi plusi tādai metodei?

Gaumes jautājums, bet, ja nu tev gribās templeitā izmantot mainīgo $output?

 

 

 

Apvienot noteikti nevajag. Tas, ka codez nesaprot, kāda ir MVC komponenšu nozīme, nav īsti attaisnojums.

View parasti ir aplikācijas daļa, kas atbild par satura attēlošanas loģiku un piekārto vajadzīgos templeitus.

Kāda jēga taisīt lieku View klasi, lai nodrošinātu templeitu ielādi, kura tāpat katrā kontrolerī tiks izsaukta un kuras kods ir 15 rindiņas?

Lūk kā rezultātā izskatīsies metode Kohana fw, pēc kura tu tik ļoti kūsti.

public function action_index()
{
   $view = View::factory('pages/index');
   $view->$text="Hello World";
   $page = $view->render(); 
   $this->request->response = $page;
}

 

un kā izskatīsies, kad Kontrolera klasē ir integrēta iekšā View-a funkcionalitāte.

public function index(){
 $this['text']="Hello world"
}

Jūti atšķirību?

Noteikts kontroleris tāpat 99% gadījumu izmantos sev piesaistītu templeitu.

Bet, ja nu gadījumā vajag citu templeitu, vienkārši izsaucam kontrolera metodi $this->setTpl('cits_templetis.tpl');

 

 

Un vispār tev ir nepareiza izpratne par to, no kā sastāv MVC.

M - modelis - apstrādā datus un tā ir nevis Model vai Activerecord klase, bet gan klase, kura extendo šīs klases.

C - kontrolleris - tas pats, nevis Controller klase, bet gan Controller_Home, Controller_About, utt. klases, kuras ekstendo šo klasi

V - tieši tā pati analoģija, nevis View klase, bet gan templeits, kurš satur HTML (vai kādu citu) kodu ar ietvertiem mainīgajiem.

 

 

1 & 2. divas bezjēdzīgas klases, kas pilnīgi neko nedod.

Ja iedziļinātos kārtīgāk, tad redzētu, ka 1. klase ir tāda draft versija tavam tik iemīlotajam Kohana freimworkam.

http://github.com/kohana/core/blob/master/classes/kohana/view.php

 

 

P.S. : silti iesaku palasīt par __autoload() un namespace

Vai tomēr spl_autoload_register?

Un namespace tikai no PHP 5.3., kurš reālajā dzīvē bieži vien var nebūt pieejams.

Viens piemērs ir RackspaceCloud Sites - lielisks hostinga serviss, kuram nav analogu, uzliec lapu, maksā par patērēto CPU slodzi, automātiski skeilojās jauda līdz desmitiem procesoru ekvivalentam, bet PHP 5.2.

Tā ka namespace-us izmantot vēl ir pāragri.

 

Tas ko tu sauc par "View" ir vienkārši primitīvs templeits.

MVC sākotnēji neradās web-am. Kad šo paternu pārnes uz web-u, tad MVC V daļa arī ir primitīvs templeits.

Gribi sarežģīt, sarežģī, tavas problēmas.

Edited July 28, 2010 by codez

[101111]

Netaisi savi freimworku. Izmanto, piemēram, Code Igniter. Tāpat beigās kaut kas stipri līdzīgs CI tev sanāks, tikai ar lielāku varbūtību, ka tu būs kļūdas.

[codez]

Netaisi savi freimworku. Izmanto, piemēram, Code Igniter. Tāpat beigās kaut kas stipri līdzīgs CI tev sanāks, tikai ar lielāku varbūtību, ka tu būs kļūdas.

Katram ir savs viedoklis, bet es uzskatu, ka MVC FW ir jātaisa katram projektam savs, jo:

• MVC FW neaizņem vairāk par 5% no normāla projekta koda bāzes.
  
• MVC FW var realizēt ļoti dažādi un neviens no gatavajiem FW ne tuvu neatbildīs projekta specifikai.
  
• Lai pareizi izmantotu jau gatavus MVC FW, tev ir jāpārzin MVC paterna ideoloģija un nianšu "KNOW HOW", bet, ja tu tās pārzini, tad uzbūvēt MVC freimworku, kurš precīzi pielāgots projekta specifikācijai, ir dažu stundu, lielākais, dienu jautājums.
  
• Tāpat, lai nekļūdīgi izmantotu jau gatavu MVC FW, tev ļoti labi jāpārzin tā iekšējais kods, kuru sava FW gadījumā tu pārzināsi perfekti, jo pats to būvēji.
  
• Tāpat, izmantojot gatavus FW, bieži projekta optimizācijas dēļ, nāksies līst un pārtaisīt FW kodolu (kas jau noved pie tā, ka turpmāko BUGu, utt. izlabošana, ko nodrošina FW komūna, izpaliks), tad kāpēc to uzreiz neuztaisīt optimālu projekta vajadzībām.
  
• Gatavos freimworkus var izmantot mācību procesā, lai apgūtu labāko praksi, dažādu MVC daļu realizācijai, jo katrā freimworkā kādas daļas ir realizētas labāk kā citos, attiecībā pret tava konkrētā projekta vajadzībām. Respektīvi, neviens no kaut cik kvalitatīajiem MVC FW, parasti, ne tuvu neatbildīs tava projekta specifikācijai, galvenokārt, viņi būs daudz, daudz par smagu, dažiem populārajiem FW pat novērots, ka Hello World piemēri jau prasa 100-300ms ģenerācijas laiku.
  
• Un šeit es runāju tikai par MVC, pārējās bibliotēkas, piemerām, ORM, bilžu apstrādi, servisu API bibliotēkas labāk ņemt gatavas, ja pieejamas kvalitatīvas.
  

Edited July 29, 2010 by codez