101111

if (isset($array[$_GET['id']])) { $something = $array[$_GET['id']]; print_r($something); } Minu, ka varētu būt šādi

ja ir pieeja pie datora, kuru lieto skype konta īpašnieks, var nolasīt skype sarunu vēsturi

Lai apskatītos kā izskatās lapa uz vecām IE versijām izmantoju šo softu: http://www.my-debugbar.com/wiki/IETester/HomePage

Piekrītu, man arī izskatās, ka cilvēks vēl visas bērnu slimības nav izslimojis :)

Vairumu no uzdevumiem risina 1-2 kursā universitātēs Grūtākais būtu sakarīgā angļu valodā apskaidrot intervētājam savu risinājumu.

Tas vairāk bija domāts konkrētā freimworka kontektā. Es neredzu nevienu iemeslu kapēc tādu, būtu kādam jāizmanto, ja ir pieejami jau gadiem ilgi attīstīti freimworki, kuri ir izmantoti neskaitāmos projektos. Tas, ka pašam sanāks stabilāka, ātrdarbīgāka vai drošāka sistēma - muļķības. Bet, protams, piekrītu, ka vienmēr var saplānot labāku arhitektūru, izejot no konkrēta projekta vajadzībām. Pašmācībai, sava ietvara izveide nāks par labu.

Es arī uzskatu, ka tā ir pilnīgi bezjēdzīga nodarbe, ja nu vienīgi paspēlēties ar MVC patternu, lai gūtu jaunu pieredzi. Mēģināt taisīt kaut ko ideālu nav vērts - tāpat visi plaši izmantotie freimworki būs visos iespējamos veidos labāki.

Kas ir rekursīvā saite?

Vari palūrēt kā ir realizēti formu komponenti lielos un labi pārdomātos freimworkos (http://framework.zen...quickstart.html vai http://symfony.com/d...book/forms.html). Priekš vienkārša projekta ar dažām formām varbūt labāk būtu arī neķēpāties ar formu bibliotēkām, jo to izveide var sanākt visai kompleksa.

Nepareizi http://stackoverflow...1732454#1732454 EDIT: savlaik esmu veiksmīgi veicis līzīgus uzdevumus izmantojot phpQuery: http://code.google.com/p/phpquery/

Ja jāatbild uz jautājumu, tad, jā, izmantojot refleksiju to laikam izdarīt var: http://www.php.net/manual/en/reflectionproperty.setaccessible.php $refObject = new ReflectionObject( $thisj ); $refProperty = $refObject->getProperty( $classVar ); $refProperty->setAccessible( false); Bet vai tā rīkoties ir pareizi konkrētajā situācijā, tas varētu būt cits jautājums (nezinu priekš kam tas viss ir vajadzīgs).

Komentāros inconv dokumentācijā var atrast norādi Tas ka tu mēģināji uzstādīt lokāli ar setlocale ir viena lieta. Bet vai no tā ir bijusi jēga (respektīvi, tava OS to atbalsta) ir cita lieta. Pārbaudi ko atgriež setlocale $locale = setlocale(LC_ALL, 'lv_LV'); var_dump($locale);

Intereses pēc, vari pastāstīt par to kaut ko vairāk? (Tāpat jau šis topiks ir pārvērties par bezjēdzīgu sviestu) Ļoti konstruktīvi!

Priekš kam tas vajadzīgs? Izklausās pēc slikta dizaina. Var jau tikpat labi Izmantot globālus mainīgos.

Šajā gadījumā callback funkcijai vajadzētu izmainīt value vērtību (ja salīdzināšana ifā ir veiksmīga), bet visticamāk tajā alertā tiks izvadīta sākotnējā vērtība, jo post pieprasījuma atbilde neatnāks pietiekami ātri (kā zināms callback kods izpildās asinhroni).

Kaut vai tas pats CodeIgniter der? Attiecīgais skriptu repozitorijs : http://getsparks.org/

Varbūt ir vērts uzmest aci phpQuery: http://code.google.com/p/phpquery/ Varēsi selektēt elementus ar tādu pašu API kā jQuery .

Pats nesen pamēģināju padarboties ar mpdf bibliotēku: http://www.mpdf1.com/mpdf/ Nesaskāros ar problēmām, kas saistītas ar kodējumu, latviešu tekstus normāli attēloja uzgenerētajā pdf-ā. Vienīgais, ka īsti neatradu sakarīgu dokumentāciju bibliotēkai, bet cik saprotu tā ir veidota balstoties uz fpdf, tapēc tai ir tāds pats interfeiss.

Būtu jādomā šādi: ir kaut kāds interfeiss kuru implementē katrs plugins. Piemēram interfeiss varētu saturēt metodes getTitle(), kas agriež plugina nosaukumu un run(), kas veic plugina paredzēto loģiku. Par pluginu saraksta sakolekcionēšanu, pluginu instancēšanu un tamlīdzīgiem darbiem būtu jābūt atbildīgai citai klasei - pluginu menedžerim, kurš zinot kāds ir plugina interfeiss varētu darboties ar pluginiem. Piemēram zinot ka plugina nosaukumu var izdabūt ar metodi getTitle(), pluginu menedžeris varētu cikloties cauri visām pluginu instancēm un katrai izsaukt šo metodi, galu galā iegūstot sarakstu ar pluginu nosaukumiem. Tavā iedotajā kodā, klase "core" aptuveni atbilst pluginu menedzerim, bet pašiem pluginiem nevajadzētu būt nekādā veidā saistītiem ar to.

Es nesaprotu kapēc tāds naids komentāros par šo sludinājumu. 500 Ls/mēnesī netto - pilnīgi normāla alga vidusmēra koderim. Ekspertiem - protams ka nē.

Neiesaku vispār pašam nodarboties ar MVC freimworka izveidi, bet gan pētīt/izmantot kādu gatavu. Augstākminētajam kodam, līdz sakarīgas arhitektūras freimworkam vēl tāls ceļš ejams. Skaties gatavus variantus, tas ar ko pašlaik nodarbojies ir nelietderīgi izniekots laiks.

Code Igniter freimworkā pieejamais risinājums /** * Prep URL * * Simply adds the http:// part if no scheme is included * * @access public * @param string the URL * @return string */ if ( ! function_exists('prep_url')) { function prep_url($str = '') { if ($str == 'http://' OR $str == '') { return ''; } $url = parse_url($str); if ( ! $url OR ! isset($url['scheme'])) { $str = 'http://'.$str; } return $str; } }

Tam tik tiešām nav nekāda sakara arī šī topika problēmu.

Pats arī savlaik esmu risinājis šādu problēmu. Manējais risinājums bija saistīts ar CI Router klases labošanu, tas bija ātrākais (iespējams vienīgais) variants, kā sasniegt man vajadzīgo rezultātu (kas ir līdzīgs tevis izvirzītajām prasībām). Cits risinājums varētu būt pre-controller hook, kurā ielasa informāciju no datu bāzes, lai dinamiski mainītu routēšanu. Pagūglējot, tādus risinājumus var atrast.

Iespējams, ka te varētu palīdzēt tāda JS bibliotēka kas saucas Knockout. Šeit tā tiek demosntrēta 20 min garā prezentācijā: http://channel9.msdn...MIX/MIX11/FRM08 .Es paskatījos - man izskatās diezgan iespaidīgi, es noteikti kaut ko tādu izvēlētos šāda tipa webu izstrādē. Principā šī bibliotēka realizē MVVM (Model View ViewModel) arhitektūru. Kaut kas līdzīgs MVC arhitektūrai, tikai radusies WPF pasaulē, kur ir tāda lieta kas saucas binding. Ar JS arī ko tādu var realizēt, tapēc arī MVVM arhitektūru var izmantot JS programmēšanā. Par bindingu šajā gadījumā varētu saukt tādu parādību, kad, piemēram, templeits piesaistās datu objektam, un kad objektā mainās dati, automātiski tas atspoguļojas templeitā un otrādi. Galvenie MVVM principi: View - Prezentācijas slānis. Šajā gadījumā HTML kods. Model - Datu slānis. Droši vien klases katrai datu entītijai, gluži kā MVC. (šajā prezentācijā šī daļa netika nekur īpaši pieminēta, citur literatūru neesu skatījies - saku ko zinu no pieredzes realizējot šo arhitektūru WPF aplikācijā) ViewModel - Sasaista View un Model. Te tiek realizēta kaut kāda loģika, kas gluži nepiederās pie paša Model. ViewModel propertiji ar binding palīdzību tiek piesastīti View. Ieguvumi no tā visa ir tādi, ka ir tīrs HTML kods. Dotajā piemērā tiek parādīta arī templeitu izmantošana netriviāliem gadījumiem. Ar bindingu pilnībā tiek atrisināta problēma 3.2. Tātad nekādu evnet handleru, viss pats no sevis updeitojas. Nojaušu arī, ka šī bibliotēka palīdzēs eleganti atrisināt 3.1. Praksē gan pats neesu ar šo JS risinājumu strādājis, gribējās tikai par patterniem parunāt.