Maris-S

Gaišs fons ir mazāk nogurdinošs. Uz tumšu skatoties acs zīlīte paplašinās uzņemot vairāk starojuma. Par papīra lapu gan nezinu. Man personīgi mājas lapas ar tumšu fonu ir nogurdinošas acīm, pie tam ļoti jūtami.

Jā, to varētu tā atrisināt, bet tad vēl paliek html dažādu tagu nosaukumu vai identifikatoru pārklāšanās. Piemēram, ir veikals, kuram kaut kur headerī ir login forma, ar input lauku nosaukumiem "email" un "password", tad vēl arī tiek atvērta kaut vai "Forgot password" sadaļa, kurā arī ir lauks input, ar nosaukumu "email". Sanāk kopējā html parādās divi input lauki ar vienādu nosaukumu. Varētu arī sanākt tā ka izsauktajos kontrolieros vairāki elementi pārklājas, ne tikai input lauku nosaukumi, bet arī tagu ID, kam ir jābūt unikāliem, kut vai: <div id="menu"></div> priekš augšējā un sānu menu. Protams šie ir primitīvi piemēri un šeit tam varētu salīdzinoši vienkārši izsekot līdzi. Arī MVC tas viss jāņem vērā, bet HMVC, iekļaujot kontrolierus vienu otrā, varētu sanākt jau ne tik vienkārši to visu atcerēties, īpaši ja lietojumu izstrādā komandā. Vienīgais kas nāk prātā ir izmantot, precīzākus nosaukumus un id, piemēram "top_menu", "left_menu", "login_email", "forgot_password_email" utt. Vai tomēr esmu vēl ko palaidis garām?

Īss un saprotams apraksts par dependency injection, ieskaitot dependency injection container. http://fabien.potencier.org/article/11/what-is-dependency-injection Iespējams kādu ieinteresēs.

Nē, CRUCIAL. :) Pie SMART viņš rāda apmēram to pašu ko jebkurš cietais, bet nebija nekas tāds, kas liecinātu par kādiem defektiem, kas varētu izraisīt tādas problēmas. Tagad nopirku Samsungu, redzēsim cik šis noturēsies. :)

Īstenībā ar SSD var būt dažādi brīnumi, kurus sarežģīti atklāt. Man pašam nesen nocepās SSD. Defekts bija interesants, strādāja kādu pus stundu un tad vienkārši nobruka, linuksis tajā brīdī pārmountēja root failu sistēmu uz read only, tā arī sapratu ka problēma ir ar SSD. Pēc restartēšanas viss ir tā pat, pastrādā kādu laiku un nobrūk. Es mēģināju skatīties SMART informāciju, bet arī tur neko jēdzīgu neuzrādīja. Paskaties sev to SMART, kaut ko iespējams arī varēs uzzināt.

Sveiki! Šajā forumā jau ir runāts ap un par tulkošanu php, izmantojot gettext. Arī pats dažreiz esmu piedalījies šajās diskusijās, bet līdz šim nesanāca atrisināt labi zināmo problēmu, ja primārai valodai viens un tas pats vārds varētu tikt tulkots dažādi. Piemēram angļu "name" varētu tikt tulkots uz latviešu valodu kā "vārds" un kā "nosaukums". Tā kā primārās valodas teksts veido unikālu identifikatoru, tie tiek iztulkoti visur vienādi. Zināmākais risinājums, kas tiek piedāvāts, lai atrisinātu šo problēmu, ir tādu kā mainīgo lietošana primārās valodas vietā. Šis risinājums tiešām atrisina problēmu, lai gan man personīgi viņš nepatīk, jo tiek zaudētas labākās gettext lokalizācijas iespējas. Izmantojot primārajā valodā atbilstošo tekstu, nevis identifikatorus, sistēma izvadīs primārās valodas tekstu, ja tas nebūs iztulkots, taču izmantojot identifikatorus, tiks izvadīts identifikators, kas nebūs tik smuki. Vēl viens trūkums ir ērtība pie tulkošanas. Izmantojot identifikatorus pie primārās valodas būs attēloti identifikatori, kas padarīs tulkošanu neērtu un laikietilpīgu. Izrādās tam ir risinājums, kas nav iekļauts php. Tā ir iespēja izmantot kontekstu, lai norādītu kādā kontekstā ir jātulko vārds. Vienkārši izsakoties tas nozīmē pielikt unikālu identifikatoru tur, kur tas ir nepieciešams, nemainot pašu primāro tekstu. Problēmas risinājumu var apskatīties šeit, pie apraksta konteksta izmantošanai: https://developer.mozilla.org/en-US/docs/gettext Arī php dokumentācijā, lietotāju komentāros: http://php.net/manual/en/book.gettext.php Iespējams kādam noderēs.

Kavacky, paturpinot piemēru, pieņemsim ka mājas lapa kā tāda ir taisīta tā, lai labajā pusē vienmēr ir jaunākās ziņas, gan tad kad ir atvērta kāda preču sadaļa, gan tad kad atvērts lietotāja profils utt. Tagad tiek atvērta parastā sadaļa ar preču sarakstu un tiek izsaukts kontrolieris: ShopController::SowProductsAction(); kas attēlo produktus, preču saraksts tiek nolasīts no datubāzes un piešķirts skata mainīgajam: $this->view->item_list Pašā skatā tas attēlojas, piemēram ar: echo($this->item_list); Tagad pieņemsim ka tiek izmantots HMVC un lai labajā pusē attēlotu jaunākās ziņas tiek izsaukts: Common::ShowNews(); kas neko nezina par ShopController, iegūst jaunākās ziņas un piešķir savam skata mainīgajam: $this->view->item_list un ziņu skatā attēlo to mainīgo: echo($this->item_list); kas ir tāds pats kā preču sarakstam. Kā jau teicu es iespējams kļūdos, jo neesmu pētījis kā īsti HMVC atrisina šo problēmu, iespējams ka tur ir savi risinājumu un iespējams ka tie ir labi risinājumi. To būs jāpapēta nākotnē. Līdzīgas problēmas ir arī MVC, ja vienkārši kontrolierim _init() metodē iekļauj common.php, bet šajā gadījumā tas ir tikai viens fails un vienmēr sākumā, bet ja tiek izmantots HMVC, tad kontrolieri var tikt iekļauti viens otrā jebkādā secībā un jau nav tik vienkārši izsekot visam tam līdzi.

Nu pirmais kas ienāk prātā ir jādomā par mainīgo nosaukumiem, lai tie nepārklātos. Bet es varētu šeit arī kļūdīties, neesmu pētījis kādas ir pieejas, lai to atrisinātu. Nu un arī pieradums. Pašreizējam projektiņam nav laika pētīt un pārtaisīt uz HMVC, bet nākotnē būs jāpaskatās. :)

daGrevi, tieši tā. Runa iet tieši par to ko atgriež kontrolieris, tam ir jābūt kontrolierī, nevis kaut kur citur. Piemēram, datus, kas tiek iegūti no datubāzes un padoti tālāk skatam. Tur arī sanāk ka bieži dažādiem kontrolieriem ir kādi pilnīgi vienādi dati un darbības, piemēram kontrolieriem user, shop, news, utt., visiem ir jādabū no datubāzes kāda pilnīgi vienāda informācija. Piemēram, ir pieprasījums: mana_lapa.lv/lv/news/show/ziņas-virsraksts Te var redzēt ka tiks izsaukts NewsController::ShowAction() un jā, viennozīmīgi viņam ir jāizpilda sava darbība, jāatgriež ziņa "ziņas-virsraksts", bet tā pat izsauktajam kontrolierim ir jādabū no datubāzes papildus informācija: valodas, visi menu, visādi jaunākie produkti kaut kur sānā, vai akciju preces, ja tas ir veikals, vai vēl visāda informācija. Ar tādas informācijas attēlošanu protams nodarbojas skats, bet ar datu, kuri tiek iegūti caur modeli no datubāzes, nosūtīšanu uz skatu nodarbojas kontrolieris un šeit tiek izsaukts tieši NewsController. Protams to varētu atrisināt ar HMVC mazliet savādāk, bet to es negribu izmantot, tur savi trūkumi ir arī.

Simpsons, Tu laikam manis sarakstīto izlasīji neuzmanīgi. :) Domāju diskusiju pēc manis norādītās saites arī neizpētīji. Pie tam populārākais nenozīmē labākais. Es arī nejautāju par popularitāti. Kam Singletons domāts es arī labi zinu un arī lasījis par to esmu. Kā jau teicu vairāk iet runa par kvalitāti un vai ir vērts viņu izmantot. Saitē norādītajā diskusijā var redzēt, ka programmētāju vidū tādas izteikti labas atzinības Singletonam nav un tur ir arī savi pamatojumi tam. Par to arī iet runa, nevis par to, kas tas ir un cik viņš ir populārs. Jebkurā gadījumā paldies par atbildēm. Ērts tas Singleton ir, bet būs laikam pagaidām jāatturas no viņa. Jāpiekrīt arī Codez, ka php varētu izmantot dažus globālos mainīgos, jo tā pat daži jau tur ir.

Paldies par atbildēm! daGrevis, te doma ir ne tikai par vizuālo attēlošanu, tie menu ir tikai piemēri. Būtībā vairāk iet runa par pašiem kontrolieriem un to darbību, tas kā viņi dabū datus, piemēram menu no datubāzes, vai arī ieraksta datubāzē, vai veic kādas vispār ar db nesaistītas darbības. Vēl varētu būt arī darbības kā rezultātam nevajadzētu attēloties skatā, tā uz ātro, kaut vai apmeklējuma counteris.

Sveiki! Pameklēju pa internetu dažādas atsauksmes un diskusijas par Singleton modeli. No vienas puses tas ir ērts, bet no otras puses ir negatīvas atsauksmes. Piemēram šajā diskusijā: http://stackoverflow.com/questions/4595964/who-needs-singletons lielākā piekrišana ir tieši viedoklim, ka Singleton labāk neizmantot (atbilde no Gordon). Tā nav vienīgā diskusija kur tiek izcelti Singleton trūkumi, īpaši uz php un bieži vien tādiem komentāriem ir diezgan liels atbalsts, kas liek secināt ka daudziem programmētājiem viņš nepatīk. Gribēju pajautāt ko Jūs domājat par Singleton un vai bieži izmantojat? Codez, zinu ka Tu izmanto viņus, vai ir sanākušas kādas problēmas darbojoties ar Singleton modeli? Paldies!

Labdien! Gribēju pakonsultēties par labākām pieejām, kā iekļaut kopējo skriptu dažādos kontrolieros? Kopējais skripts varētu izvadīt tādus datus kā dažādus menu, piemēram augšējo un sānu menu, valodas utt. Kā un kur pareizāk un ērtāk būtu iekļaut šo kopējo skriptu? Rakstīt katram kontrolierim, piemēram Controller::_init() metodē to visu būs kopēšana, vēl iespēja būtu iekļaut kādu common.php tai pašā Controller::init() metodē, piemēram: class UserController extends controller { function _init() { require_once('path/to/common.php); } function ProfileAction() { ..... } } Viss tas strādā, bet sanāk ne visai smuki pašā common.php failā, jo ārpus objekta parādās, piemēram: $this->view->languages = $page->get_languages(); $this->view->main_menu = $page->get_menu(); Kādas būtu labākās pieejas, lai visu to savienotu kopā? Paldies!

Nē, pārāk daudz nav, kad izslēdz webmin. :) Vispār minimāli. Rakstīju webminam sourgeforge forumā, bet viņi neatbildēja. Kaut kas vai nu pašam webminam, vai arī python. Tā kā webmin nav bieži vajadzīgs, tad arī var ieslēgt caur ssh kad viņu vajag. Par tām vērtībām es arī īsti nesaprotu, sīku aprakstu tā arī neatradu. Ko tie burtiņi beigās nozīmē tā arī nesapratu, piemēram 700.0m, vai arī 86u, vai arī vērtība vispār bez burta. Neesi kaut kur redzējis aprakstu?

Paldies par valodu salīdzināšanu. Jā, delphi būs mazāk bibliotēku, ko arī pieminēju kā lielāko mīnusu šai valodai. Taču tas man neliek domāt ka tā valoda ir pielīdzināma tikai mācību valodām un nelietojama. Ja viņa būtu nelietojama, tad viņu arī neviens nelietotu. Nu labais, nav nepieciešamība atbrīvot atmiņu! :) Tā ir laba pieeja, saveidojam kaudzi objektu un atstājam atmiņā, ir taču garbage collector! :) Nu nezinu, laikam moderniem programmētājiem ar modernām valodām tas liekās normāli. Pareizi, priekš kam veidot kvalitatīvu programmas darbību, ja var to nedarīt? Tikai kāpēc tad memory leaks vienmēr tiek uzskatīts par bugu, kurus vienmēr labo? Ir taču garbage collectors. Problēma ir tur, ka lielākai daļai programmēšanas valodu nav rīku, lai tādus bugus vismaz mēģinātu izķert izstrādes gaitā, nevis tāpēc ka modernajās valodās to nevajag darīt. Protams ka FastMM varēs atrast memory leaks tikai Tavā programmā. Viņš arī paredzēts, lai tos atrastu delphi kodā. Viss ir ļoti pareizi, FastMM atrod memory leaks un parāda kur kodā tas notiek. Kā Tu iedomājies to izdarīt ar dll, kur nemaz nav programmas izejas kods? Tas kas notiek dll ir dll ražotāja atbildība. Es nesaku ka programmētājam nav nepieciešams pārliecināties par izmantojamo dll kvalitāti, protams tas ir jādara, bet primāri par to kvalitāti ir jārūpējas tam, kas to dll ir programmējis un viņam būtu jārūpējas par tādu kļūdu atrašanu savā programmā, ko ražotājs arī parasti dara. Kā viņi to dara tai pašā C es nezinu, bet parasti jēdzīgi ražotāji labo bugus savos produktos, tai skaitā memory leaks. Vai es tomēr kaut ko ne tā saku? Kā jau teicu lazarus/delphi būtu mana personīgā izvēle, īpaši veidojot lietojumprogrammatūru, nevis to, ka šīs būs vienīgās pareizās valodas.