Ci parametru padošana no kontroliera modelim

[CrossUp]

Sveiki, neesmu prasījis plašākai publikai palīdzību programmēšanā tāpēc problēma, iespējams, nebūs skaidri noformulēta.

Ideja manam projektam ir izveidot CMS priekš portfolio tipa lapām, cenšos maksimāli daudz rakstīt kodu pats. Esmu saskāries ar problēmu pie $multi_upload_path parametra izveidošanas. Lapai ir kontrolieris, kurš uzrāda (sūta uz view) ievietotos projektus, kas radīti projektu modelī. Dati par katru projektu tiek iegūti balstoties uz projekta ID. Projekta datus var labot brīdī, kad kontrolierim tiek padots attiecīgā projekta ID un labošanai ir attiecīgā poga. Tāda pati poga ir bilžu augšupielādēšanai (Pielikums nr1). Bilžu augšupielādēšanai man ideja ir tāda:

• kaut kur atrodas direktorija images, brīdī, kad tiek uzspiesta augšupielādēšanas poga tiek izveidota mape (balstoties uz projekta ID, tad no DB tiek paņemts nosaukums) ar attiecīgā projekta nosaukumu un iekš tās mapes thumbs mape. Dzēšana arī ir uzrakstīta secīga un loģiska.
• brīdī, kad lietotājs izvēlējies bildes, kuras augšupielādēs, tās automātiski izvēlas to mapi, uz kuru attiecās projekts

Problēma rodas brīdī, kad vajag no kontroliera padot ID uz upload modeli līdzīgi kā edit funkcijai padod ID, kura atrodas iekš project kontroliera.

 

Šādu pieeju esmu izvēlējies, jo nepieciešams pilnveidot programmēšanas zināšanas.

 

Ja ir nepieciešams kods tad to var dabūt, bet lai jums kļūtu kaut kas skaidrs būs daudz koda jāparāda, jo man tur ir LU mācīta "kārtība", kura man patīk.

[reiniger]

Controlier
$this->tavs_models->update_kaut_kas($id);

Models 
function update_kaut_kas($id){
...

Ja pareizi sapratu, ko vēlies panākt.

[CrossUp]

Controlier
$this->tavs_models->update_kaut_kas($id);

Models 
function update_kaut_kas($id){
...

Ja pareizi sapratu, ko vēlies panākt.

 

Ja tava ideja ir uz to pusi, kas man vajadzīgs. Man bija vajadzīgs, lai no kontroliera padod mainīgo uz modeļa 1 funkciju un to rezultātu padod citai funkcijai un problēma bija:

//Controller
$this->mans_modelis->mana_funkcija1($id);
//mainīgais $id ir redzams tikai šajā kontrolierī un pirmajā modeļa funkcijā

$this->mans_modelis->mana_funkcija2();
//rezultāts ir null


//model
function mana_funkcija1($app){
//piemeram
return $app*$app;
}

function mana_funkcija2(){
//piemeram
return mana_funkcija1($app) * 3;
}

Vakar vakarā izdomāju radikāli citādu pieeju, ja tā izdosies iepostošu rezultātu.

Edited March 27, 2014 by CrossUp

[jurchiks]

Un no kurienes tad `mana_funkcija2()` raus to `$app` variabli, kuru viņa padod tālāk?

Vai nu uzseto to variabli kaut kādā reģistrā, vai padod kā parametru arī `mana_funkcija2()`.

Edited March 27, 2014 by jurchiks

[CrossUp]

Re kur redzams tiešs kods, kuru pārtaisīju:

public function project_picture_proccess($id = NULL){

        $this->load->model('upload_m');

        $this->data['project'] = $this->project_m->get($id);

        //ielade atlasito saturu
        $this->data['subview'] = 'admin/project/picture_proccess';

        $this->load->view('admin/_layout_main', $this->data);
                
        if ($id) {
            //izveido vai atver direktoriju tik lidz ieiet projektā
            $this->project_m->search_and_create_dir($id);
             //atlasa DB esošos datus
            $this->data['project_images'] = $this->project_m->get_images($id);
            
            //izveido $path mainīgo bilžu augšupielādei
            $path = $this->upload_m->set_upload_path($id);
//kad pārbauda rezultātu ar var_dump($path); viss ir ok
            
            $upload_config = array(
                'upload_path' => $path,
                'allowed_types' => 'jpg|gif|jpeg|png|bmp',
                'max_size' => '0',
                'overwrite' => FALSE
            );
//Pārdbaudot ar var_dump($upload_config); viss ir kā vajag        
        }else echo "Nav projekta, kam pievienot bildes";
        
        
//ārpus tā "if'a" arī gan path , gan $upload config ir redzami
            var_dump($path);
           
            var_dump($upload_config);
        
        if($this->input->post('upload')){

//Parādās null kā $upload_config vērtība
            var_dump($upload_config);
            
            $this->load->library('upload');        
            //upload funkcija

            $this->upload->initialize($upload_config);
            if($this->upload->do_multi_upload('userfile')){
            
                var_dump($this->upload->get_multi_upload_data());
                //return;
            }else{
                echo "Ir bijusi kļūda ar failu augšupielādi.";
            }
            
            $this->data['error'] = array('error' => '');
            $this->data['project'] = $this->project_m->get($id);
            $this->data['unsorted_img'] = $this->upload_m->get_unsorted();

            //ielade atlasito saturu
            $this->load->view('admin/_layout_main', $this->data);
        }
    }
    

Kāds var lūdzu paskaidrot kāpēc iekš "upload" pogas pārbaudes neredz $upload_config mainīgo (mēģināju ar global atslēgas vārdu un arī nekā) ? Un ja ir iespēja, tad pateikt, kur es varētu risinājumu pameklēt un ar kādiem atslēgas vārdiem.

[jurchiks]

Viss, ko es redzu, ir tas, ka tu definē $upload_config iekš IFa, bet mēģini tam piekļūt ārpus tā. Shitty coding practice, kuru PHP diemžēl ļauj izmantot.

Edited March 27, 2014 by jurchiks

[CrossUp]

Viss, ko es redzu, ir tas, ka tu definē $upload_config iekš IFa, bet mēģini tam piekļūt ārpus tā. Shitty coding practice, kuru PHP diemžēl ļauj izmantot.

Es saprotu, ka noteikti ir labāki paņēmieni kā to izdarīt, bet es mācos un visu vēl nezinu. Vai tev ir ieteikumi kā to izdarīt efektīvāk ? Lūdzu padalies.

[jurchiks]

Vispār tev to `$upload_config` vajadzētu definēt iekš `if($this->input->post('upload'))`, jo tikai tur tu to izmanto.

`$path` definē pirms `if ($id)` kā tukšu stringu, iekš tā IFa uzseto tam vērtību, un visam vajadzētu būt OK.

Edited March 28, 2014 by jurchiks

[e-remit]

Spriežot pēc koda komentāriem, $upload_config ir globāls mainīgais, kurš tiek pārrakstīts funkcijā $this->input->post('upload'). Te ari parādās globālo mainīgo ļaunums, kad mainīgie "mistiski" tiek modificēti.

[jurchiks]

Stipri šaubos. Variablis nekur funkcijā netiek definēts kā `global $upload_config`, bet ja tajā $this->input->post() funkcijā tas tiek globalizēts, tad tas ir vienkārši fucked up.

Vpročem zināma problēma, mans kolēģis arī ļoti mīl izmantot globālos variabļus :/

[gurkjis]

OOP gadījumā global variabļa analoģija ir - statisks lauks konkrētai klasei. 

 

Kas tad īsti izmainās ? Globālā pieejamība tiek saglabāta, tikai OOP variantā ir ļoti konkrēta, hierarhiska, sakārtota kokveida struktūra, kur kas glabājas. Namespace -> Class -> static variable.

Tieši tas pats ir ar funkcijām. globālās funkcijas = OOP gadījumā statiskās metodes klasei.

 

Parastajā gadījumā tas global var sliktums ir tajā, ka nav īsti kārtības, kur kas glabājas - ir viens global namespace ar čupu mainigajiem no visas aplikācijas, kas arī pie lielākām sistēmām rada haosu. Iesviežot konkrētā klasē, mums ir zināms konkrēts konteksts, kas pilda grupēšanas funkciju, kā rezultātā ir vieglāk atrast un sakārtot lietas sistēmā.

 

Namespaces un klases ir tā kā mapītes priekš koda organizēšanas, bet protams, ļoti noderīga fīča ir vairāku objektu instanču veidošana, bet ne jau vienmēr tas ir vajadzīgs - var iztikt ar singletonu, kur nav nepieciešamības pēc multiple instances. 

 

Kompleksu lietu kaudzi vienmēr var izdalīt loģiskā hierarhijā, tā pat ir ļoti veselīga prakse.

 

Ja ļoti gribas, hierarhisku koda organizāciju var izspiest arī bez OOP, bet nu ... tā būtu hakošana, nevis pareizo rīku izmantošana.

Edited March 28, 2014 by gurkjis

[jurchiks]

Ko tu ar to centies pateikt, un kā tas ir saistīts ar tēmu?

Edited March 29, 2014 by jurchiks

[gurkjis]

Nu es aizdomājos par tēmu globālie variabļi (ne-OOP) vs OOP pieeja un izklāstīju, kā to redzu. Tas ir - globālie variabļi ir pieejami analoģiski OOP praksē, kad lietojam singletonus, bet tie nav slikti dēļ tā,ka ir globāli pieejami, bet gan tāpēc, ka tiek sagāzti vienā čupā. Varbūt kādam var noderēt šāda info. Citādi ir buzz par to, ka ir globals ir slikti, a kāpēc tieši, tas var arī uzreiz nebūt skaidrs....

 

Ar to es arī apgalvoju, ka DAŽI globālie variabļi nav nekas slikts, piemēram, ja turi DB handleri.... Nekas reāli slikts nenotiks, ja Tev tagad nelielā sistēmā būs globāls DB handleris..  Tādas radīsies, kad sistēma paliktu liela, sastāvot no daudziem moduļiem, kas katrs kaut ko gāzīs iekš global namespace.

Edited March 30, 2014 by gurkjis

[jurchiks]

Nezinu kā tu to db handleri turi, bet es tam piekļūstu ar DbHandler::getInstance(), un es to nu nekādīgi nevaru asociēt ar parastiem globāliem variabļiem.

 

IMHO, globāls = kaut kas, kas atrodas global namespace jau pašā sākumā, piemēram, funkcijas un variabļi, kas nav definēti kādā klasē, bet gan bootloaderī. Statiskas klašu funkcijas, kurām pieeja rodas tikai tad, kad autoloaderis iegruzī to klasi, IMHO nav globālas. Viņām var piekļūt globāli, bet viņas nemētājas global namespace.

Edited March 30, 2014 by jurchiks

[Kavacky]

Pilnīgi pie vienas vietas, kur kas tiek glabāts. Svarīgs ir pats princips. Tev pa lielam ir vienalga, kā arī tu nemaz nezini, ja nepārlasi pēc katra update PHP C sourci, kā tas tiek apakšā realizēts un glabāts. Rezultāts ir svarīgs, un tas beigās ir viens - globāli pieejams kaut kas.