Web Developer

Uztaisi View'u UserProfileNewsView, kuru tu iekļausi citā savā "galvenajā" view'ā.

Šajā UserProfileNewsView tad arī izpildās attiecīgās lietas un atrādās. Tur arī tev rasies tas HTML fragments ar css un js.

Nejauc modeli ar moduli.

1) modelis varētu saturēt metodes, kas atgriež datus pēc padotiem parametriem. Controller padod parametrus, modelis atgriež datus, views paņem datus no modeļa. Nu viens modelis tev būs, piemēram, viena db tabula vai viena db procedūra.

2) Priekš kam tev katram modelim jāpiesaista noteikts view? Nevari no viena view izmantot vairākus modeļus, vai vienu modeli izmantot vairākos views?

Pamācības:

1) kāpēc tev jāsaista css (kas piederās pie views) ar modeļiem? Tas jau tavs pirmais "neatkarības principa" pārkāpums. CSS un JavaScript piederās pie views tāpēc tas IR Views.

2) sadali savu lapu vairākos views - galvenie un tad attiecīgie pēc pieprasījuma. Viņi neatkarīgi no modeļiem ņem datus sev. Kontroleris vienkārši ir inicializējis un padevis parametrus attiecīgajiem modeļiem. Kontroleris arī atvēris vajadzīgos views. Tāpēc tas ir kontroleris, ka tas visu kontrolē. Tāpēc Views ir Views, kas visu atrāda. JavaScript ir klienta puse, tātad, atrādāmā fīča - Views. Parametrus vari padot kā jau html-veidīgajam views. Modelis tikai satur datus.

1) html tev ir tieši atkarīgs no tā, ko ģenerējuši tavi neatkarīgie objekti - kā tu to html saliec kopā, tas ir views jautājums. HTMLā jeb Contentā tu saliec visu saģenerēto, ko tev vajag.

2) css ir pilnīgi kaut kas cits - tas ir tikai presentation - tas tev ir jāatdala pēc iespējas no visa html un jāliek atsevišķos failos, kur arī rediģēsi - un views liec norādes uz css failiem.

3) javascript liec neatkarīgi no html un css - to arī ir iespējams izdarīt. Protams, iet runa par lielo vairumu koda.

Tavi kontrolleri veic visas dispečera funkcijas un inicializē vajadzīgos views un modeļus pēc pieprasījuma.

Tālāk tavi views ņem no modeļiem datus un atrāda.

Visas daļas ir neatkarīgas viena otra pa lielam, tai pat laikā saistītas - tāpat arī OOP objekti mēs saistīties ar citiem objektiem, bet paši par sevi ir neatkarīgi.

codez - tu vēljoprojām neesi sapratis, ka css un javascript principā nav nekāds sakars ar tavu servera puses oop. Tie jebkurā gadījumā būs jāraksta atsevišķi, vai nu pie views vai kopējos failos. Un ja tev jālādē 30-60 ārēji faili, tad kaut kas nav kārtībā ar projekta organizāciju.

Ja tev sākotnējā ielāde ir paredzēta ilga, uztaisi tā gmailā - sākumā "loading" strīpa, pēc tam, kad tā aiziet, lieto mierīgi.

Un tev mierīgi var būt servera pusē OOP - tu tur vari veidot savu dizainu kā gribi (starp citu, kaut vai ar HTML helperiem) - css - dizains un javascript behaviour tev ir jāatdala pēc iespējas vairāk viens no otra, kā arī no html. CSS jātur atsevišķos failos vēlams.

1) CSS selectori arī ir principā viena no otras neatkarīgi. Nesaskatu šeit "neatkarības problēmas".

2) Tavā gadījumā tu vari katram modelim piesaistīt savu css fragmentu. Tas ir viens. Otrs ir tas, ka ja šie modeļi ir savā starpā neatkarīgi, tādā gadījumā arī css selektoriem jābūt neatkarīgiem, vai arī saistīti tikai ar core - un savu core css gabalu vari kā atsevišķu css failu inklūdot visos gadījumos. Ja css gabali atsevišķos modeļos ir neatkarīgi, tad nav svarīga secība, kādā tos samauc kopā, tāpat tev beigās jāģenerē kopā arī html, tāpat arī saģenerē kopā arī css, ja jau gribi būt tik advancēts.

Jā, ir cits variants - liec visu css vienā vai dažos ārējos failos un js tāpat. Nekam pārāk ilgi nevajadzētu lādēties pat lielā portālā - ar nosacījumu, ka css un html ir taisījis savas nozares profesionālis, tāpat arī Javascript (kas ir nedaudz savādāks gan).

Vajag taisīt normāli css, nerakstot neko lieku un rakstot visu pēc iespējas īsāk un optimālāk + vēl ir arī mehāniskas iespējas optimizēt css failus. Ja uzraksta draņķīgus css failus, tad nafig. Jebkurā gadījumā - css attiecās tieši uz dizaina templeitiem un ar tiem objektiem tam sakars minimāls - css jārediģē atsevišķi. Objekti var būt neatkarīgi savā sistēmā no ārējiem apstākļiem. Views-templeiti arī neatkarīgi. css arī neatkarīgi.

Vai arī, kas tev liedz veidot folderi:

views/news/ - kurā tad ievietosi gan news.tpl, gan news.css un citas huiņas, ko tev vajag? OOP pēc actioniem sapratīs automātiski, kāds galvenais templeit fails no views ir jāizmanto, vai tas būtu news.tpl vai news_description.tpl

Nejauc css un JavaScript ar OOP.

OOP servera sistēmu tu veido atsevišķi, javascript un css rediģē atsevišķi - tie ir dizainam tieši piederīgi. Protams, tam visam ir saskaņas ar oop - ar nosaukumu palīdzību kaut vai.

codez - tu esi āmurs vai izliecies? CSS klases vari veidot automātiski kā tev patīk! CSS visu atsevišķi jādefinē atsevišķā css external failā. Kas vēl speciāls ir nepieciešams?

codez - sākumā jāiemācās web aplikācijas taisīt, nevis

...

Katram modelim ir savs HTML izvads, kur beigās visu modeļu HTML izvads tiek apvienots vienā lapsa HTML izvadā.

Katra modeļa HTMLam ir savs CSS fragments.

Kā darīs?

1)visu modeļu CSS un JS failus inklūdos konkrētajā lapsa izvadā? Īsti neder, jo var nākties pat inklūdot vairāk kā 30 js, css failus.

...

Ja nemāk css taisīt un optimizēt, tā nav OOP problēma. Tāpat arī, ja nemāk JS rakstīt un optimizēt pareizi.

Nav ko inklūdot visu laiku - ir jāprot uztaisīt pamats - klienta puses aplikācija - html+css+javascript. Kā jau teikts, tas ir tikai vizuālais interfeiss, kuram veiksmīgi jāsavienojas ar servera puses OOP.

PHP vispār to OOP jāizmanto minimāli "performances dēļ". Jo tik lēnu valodu kā php starp populārajiem opensource maz atradīsi...

Bet tas, ka web aplikāciju gadījumā neiespējami pilnībā realizēt OOP, tam es nepiekrītu.

Protams, templeiti un css nav OOP, bet tas ir tikai vizuālais API, kuru tu taisi pats. Visu apstrādi un reālās darbības veic OOP. Šabloni ir tikai šabloni dizainam, xml - konfigam, datu glabāšanai un pārnešanai utt.

bubu:

par tavu jautājumu - šobrīd nav laika analizēt sīkāk. Izteicos vispārīgi. Sīkāk konkrēti nemācēšu pateikt, tur tiešām ir jāpapēta.

Man php daudz kā trūkst - galvenais jau, tai php trūkst kārtības un noteikumu - tāds advancēts qbasic vien ir. Tā jau nu vien būs, ka php pamatā šķiet, bijis paredzēts bērniem.

Šeit nu pilnībā piekrītu v3rb0. OOP ir domāšanas veids, kuru labāk mācīties uzreiz valodās, kuras pilnībā balstās uz OOP un kurās ir izstrādātas augsta līmeņa OOP konstrukcijas (nezināju kā lai savādāk nosauc).

Varētu autors pateikt arī tās lapas adresi, lai cilvēki var paspēlēties un palauzt :)

Šitādas sources esmu gatavs zagt par katru cenu - tik "ģeniāla" source, ka smiekli nāk! :D

Bet tā vispār risinājums ir (par drošību tur absolūti nedomāju, jo man tas nerūp, ka tavu lapu kāds nograus):

<?php
$klanaid=$_REQUEST['id'];
$klans = "SELECT id, i_username, i_image_1, i_clan FROM `users_data` WHERE `i_clan` = '$klanaid' ";
$usersres=mysql_query($klans);
while($users=mysql_fetch_object($usersres))
{
  $uimg=!empty($users->i_image_1)?' style="background-image: url(\'/uimg/'.$users->i_image_1.'\');"':'';
echo'
<td>
   <a class="image" href="/'.$lx.'/users/'.$users->id.'.html"'.$uimg.'> </a>
   <a href="/'.$lx.'/users/'.$users->id.'.html"><b>'.$users->i_username.'</b></a><br />
   <b>Klans: '.$users->i_clan.'</b>
  </td>
';
}
?>

Man šķiet, tu runā par Smarty. Nav grūti apgūstama sistēma, bet neredzu būtisku labumu to izmantot. Manuprāt visas šīs tēzes, kas ir aprakstīti tur kā smarty "plusi", ir mierīgi izdarāmas, vienkārši rakstot php iekš html:

One of Smartys primary design goals is to facilitate the separation of application code from presentation.

Šo var mierīgi izdarīt bez template enginas.

Errors in the templates are confined to the Smartys error handling routines, making them as simple and intuitive as possible for the designer.

Šis ir jautājums drīzāk par projekta error reportingu un tā līmeni, nevis "template engini".

Designers can't break application code. They can mess with the templates all they want, but the code stays intact. The code will be tighter, more secure and easier to maintain.

With presentation on its own layer, designers can modify or completely redesign it from scratch, all without intervention from the programmer.

Programmers aren't messing with templates. They can go about maintaining the application code, changing the way content is acquired, making new business rules, etc. without disturbing the presentation layer.

Visi šie ir vienkārši stulbi "plusi". Pirmkārt, nav ko ņemt darbā tik tupus "dizainerus", kas ir gatavi salauzt php kodu un taisīt sabotāžu jūsu uzņēmumam. Otrkārt, pat ja "dizaineris" nejēdz php, viņam tikpat labi kā smarty engines vietā, var iemācīt tās atļautās php komandas un konstrukcijas, ko viņš drīkst izmantot template failos.

Īsāk sakot, manuprāt, Smarty balstās uz krietni novecojušiem pieņēmumiem un paņēmieniem. Arī performance mūsdienās ir svarīga, sevišķi php, ja pareizi sataisīts, ātrāks būs pliks php+html kods, nekā tāds Smarty.

PHP OOP vari izmantot, vari neizmantot arī, tur var programmēt dažādi... Bet, piemēram, Java viss notiek tikai OOP un pie tam, ļoti augstā līmenī. Tāpēc, uzskatu, ka labāk būtu mācīties kādu Java vai C-veidīgo valodu, lai iemācītos OOP, jo OOP tomēr labāk iemācīsies, ja mācīsies to valodā, kura balstās tikai uz OOP. PHP OOP izskatās vairāk pēc fīčas - tak labi zināms, ka php versijās <5 to OOP nemaz tik plaši neizmantoja.

Ja jau cilvēks grib iemācīties OOP, tad labāk viņam to darīt ar visiem teorētiskajiem pamatiem. Lai pēc tam var viegli pāriet uz citu OOP.

PHP ir tāda surogātvaloda ar visu OOP...

Kopš viņi sadaļā Darbs -> Programmētājs -> Vajadzīgi taisīja tādus trikus, ka neviens tur nevarēja ielikt sludinājumu un karājās viens pats SIA Internet darba piedāvājums, tad es tur vairs neskatos.

Tas "dēlis" ir smirdējis gandrīz vienmēr.

Sākumā izlasi grāmatu par OOP teoriju. Vai arī mācies reizē OOP ar Java vai C# (.NET), piemēram. Neiesaku mācīties OOP no php. Labāk neklausies codez - šķiet, šis no sevis ir iedomājies ģēniju un cenšas citiem ieteikt sliktākos variantus, lai šo "ģēniju" kāds neizdomātu izkonkurēt - par šādu iespējamu scenāriju, palasot viņa ziņojumus, nebrīnos, ja godīgi...

Saku - OOP labāk mācies tīri teorētiskā līmenī - tur tāpat visi piemēri būs aprakstīti ar valodām "C un paveidi" vai ar Java.

Nu par Ukrainu veltīgi tu tā... tirgus viņiem lielāks nekā mums

- зарплата $500 - $2000

500$ būs aptuveni tie paši 250 Ls , ko te piedāvā šī vietējā "interesantā" firma.

Par ukriem - tu tiešām neko nezini par ukriem, ja ceri, ka tas, ka rakstīts, ka iespējama alga līdz 2000$, nozīmē, ka saņemsi tos 2000$? Priecājies, ka vispār samaksās un labi, ja tos pašus 500$.

Roze - kā var nebūt cepiens, ja ieraugu šitādus sludinājumus? Vai arī te kāda Ukraina ir?

Paldies, marcis, ka pateici par šiem!

P.S.

Mr.Key - esi nu gudrs - izlasot šo citātu:

Jaunam perspektīvam projektam steidzīgi vajadzīgs kvalificēts programists,kurš varetu palīdzet izveidot nopietnu, interesantu interneta mājaslapu uz bartera noteikumiem (izvietot savu reklāmu un informaciju presē,internetā un koncertos).Ja sadarbība būs veiksmīga un abpusēji izdevīga,nākotnē iespējams iegūt pastāvīgi apmaksātu darbu

... tak viss ir skaidrs... Nu cilvēkiem nav naudas, grib par velti, lai viņiem realizē visādas biznesa idejas. Nu, kā jau Leiputrijā. Man kauns, ka ir idioti, kas parakstās uz visādiem šitādiem "projektiem" un par sviestmaizi līdz realizēt tiem "aitu cirpējiem" viņa biznesa projektus, kuri kā zināms, tāpat lielākoties mēdz izgāzties.

Gints Plivna, es tomēr gribētu oponēt. Tas, ka kavējas termiņi programmēšanas nozarē ir pilnīgi normāli, jo tie tiek prognozēti diezgan optimistiski, nepieļaujot nekādas būtiskas aizķeršanās. Bet taisot pietiekami sarežģītus projektus, aizķeršanās mēdz būt, pie tam kārtīgs programmētājs iemācās, ko jaunu katru dienu (atšķirībā no zobārsta) - tāpēc arī programmētājs var iztikt varbūt bez akadēmiskas izglītības, jo tāpat katru dienu kaut kas jauns būs jāmācās un lielais vairums ir apgūstams pašmācības ceļā, jo atkal koks ar diviem galiem - programmētāju diez vai var izmācīt, par programmētāju ir pašam jāiemācās - tā es uzskatu.

Programmē un nedod rezultātu? Nu kā, ja tu programmē, rezultāts ir - kaut vai kļūdains! Ja neprogrammē, rezultāta nav.

Ja rezultāts ir kļūdains, tad tas jālabo, kamēr salabo un tad ir arī galarezultāts.

Ko nozīmē - dot rezultātu vai nedot rezultātu? Rezultātu var dot vienmēr, jautājums ir - kādu. Bet vai firma, kas algo tos par 250 Ls ļauj viņiem laist luni? Šaubos!? Domāju, ka viņus izkalpina vēl vairāk nekā programmerus citās firmās, kurās maksā šiem 500 Ls.

Es teiktu, ka te ir kā krievi saka - "naglosķ"! Izmantojot to, ka mūsu "profesionālie" mēdiji visu laiku biedē visus ar "krīzi" un "briesmīgo" ekonomisko situāciju (kura nav pozitīva nenoliedzu, bet kāpēc cenas veikalos tikai ceļas vēl vairāk?) Vārds "krīze" tiek izmantots plaša mēroga cilvēku šantāžai. Apkopēja divās firmās strādājot (katrā ikdienu pa 3-4 stundām maksimums) mierīgi nopelna vairāk nekā 250 Ls uz rokas. Tad cik tālu vēl jāiet un cik zemu jākrīt, lai būtu muļķi, kas strādātu par 250 Ls uz rokas par programmētāju - vienalga, kāda līmeņa, bet cilvēks ir iemācījies programmēt un var dot rezultātus!