Pirmā no Envato interneta vietnēm ir ThemeForest.net. Tajā atrodamas Joomla, WordPress, kā arī parastas html/css dizaina tēmas. WordPress un Joomla tēmu cena svārstās vidēji ap 17-37$, bet dizainu, kas nav pielāgoti nevienam CMS (Site template) cena vidēji ir ap 7-22$. Šeit ir viena no retajām vietām, kurā iespējams atrast gatavus dizainus administrācijas paneļu veidosanai (backend). Iespējams iegādāties arī tikai PSD formāta dizainus. Ir pat atsevišķa sadaļa izveidota Magento interneta veikalu platformas tēmām.

activeden.net – visdažādākie flash komponenti, sākot ar video un audio atskaņotājiem un beidzot ar flash spēlēm un mājas lapu šaboniem  sākot no 1$.

3docean.net – 3D modeļi, tekstūras u.c. materiāli, kas noderēs tiem, kas nodarbojas ar 3D leitām

audiojungle.net -nopērkami audio gabali, kas var noderēt gan spēļu veidotājiem, gan veidojot video prezentācijas

codecanyon.net – PHP, JavaScript, ASP.NET un Java skripti

graphicriver.net -pieejamas vektorgrafikas bildes, tekstūras, dizaina šabloni kredītkartēm, flaijeriem u.c.

videohive.net – dažādi video faili

Šīs visas interneta vietnes piedāvā ne tikai iegādāties failus, bet arī kļūt par to autoru un pelnīt no katra pirkuma, piemēram, izveidojot oriģinālu WordPress dizaina tēmu dizaineris var nopelnīt 40%-70% no katra pirkuma (atkarībā no apgrozījuma), ja konkrētais produkts tiek tirgots tikai kādā no šīm lapām. Ja tiek tirgots arī vēl kaut kur citur, tad par katru pārdoto vienību autora atlīdzība ir 25%. Tādejādi tiek panākts, ka tirgotie faili šajās lapās lielākoties ir unikāli un atrodami tikai šajās interneta vietnēs. Ja mēnesī ir nopelnīts mazāk par 500$, tad nopelnīto naudu var izmaksāt uz MoneyBookers vai PayPal. Savukārt savācot vairāk par 500$ mēnesī izmaksa tiek veikta ar čeku vai wire transfer pārskaitījumu.

Problēmas

Daudzi uzskata, ka adreses http://www.mansdomens.lv, http://mansdomens.lv, http://www.mansdomens.lv/index.php, http://mansdomens.lv/index.php ir ekvivalentas, bet tehniski tā tas nav. No SEO viedokļa, ir ļoti ieteicams, saitēm uz savu mājas lapu izmantot tikai vienu noteiktu variantu (ar vai bez www). Galvenie iemesli tam ir divi. Pirmkārt, eksistē meklēšanas dzinēji, kas http://www.mansdomens.lv un http://mansdomens.lv varētu uztvert par dublējošu saturu un sodīt par to lapu. Cik zināms tas neattiecas uz Google un tā kā Latvijā lielākoties visi meklēšanai izmanto tieši Googles meklētāju, tad tas vēl mūsu lapai, ja tā orientēta Latvijas tirgum, nenodara pārlieku lielu ļaunumu. Otrkārt, kas ir pats būtiskākais, šāda dublēšanās var pazemināt mājas lapas pagerank vērtību. Ja uz http://mansdomens.lv ir 50 saites un uz http://www.mansdomens.lv būs 100 saites, tas nenozīmē, ka uz mūsu mājas lapu pavisam kopā ir 150 saites. Līdz ar to http://mansdomens.lv un http://www.mansdomens.lv pagerank vērtības var atšķirties, bet, kas ir pats būtiskākais, augstāku pagerank mēs varētu iegūt, ja būtu jau sākotnēji izmantojuši vai nu vienu, vai otru url adresi.

Risinājumi

Vispirms būtu jāizvēlas lietot adreses ar vai bez www un pēc tam pie šīs izvēles arī jāpieturas. Ieteicamākais ir otrs variants, jo tas ir tas, ko cilvēki visbiežāk lieto. Kad esam izvēlējušies, tad vajadzētu tehniski realizēt, lai automātiski lietotājs nokļūtu vajadzīgajā lapā, pat ja viņš pārlūkā ieraksta pretējo adresi. Visvienkāršākais veids kā to izdarīt ir ar .htaccess failu palīdzību, vienīgi ir jāņem vērā, ka, lai strādātu šī metode, apache web serverim ir jābūt uzinstalētam mod_rewrite modulim. Ja vēlamies, lai ierakstot http://mansdomens.lv lietotājiem vienmēr atvērtos http://www.mansdomens.lv, tad .htaccess faila saturam ir jābūt šādam:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

Šinī gadījumā pat, ja lietotājs ierakstīts adresi bez www uz kādu no domēna apakšlapām, piemēram, http://mansdomens.lv/raksts-par-seo, tad tāpat tiks automātiski atvērta adrese http://www.mansdomens.lv/raksts-par-seo

Vēl viena alternatīva, kā to izdarīt ir index.php failā iekopēt sekojošas koda rindiņas:

<?php
 if (substr($_SERVER['HTTP_HOST'],0,3) != 'www')
 {
 header('HTTP/1.1 301 Moved Permanently');
 header('Location: http://www.'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']);
 }
 ?>

Ja konkrētās mājas lapas visi pieprasījumi neiet caur index.php failu, tad šis kods ir jāiekļauj visos failos caur kuriem iet pieprasījumi. Šo metodi nevarēs pielietot, ja mūsu mājas lapa sastāv no html failiem, tāpēc ieteicamākā metode būtu tieši .htaccess failu izmantošana.

Ja ir vēlme visas adreses pārveidot formā bez www, tad .htaccess failā būs jāieraksta:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Ja .htaccess failā ir vēl kādas rindiņas, kas sākas ar RewriteCond un RewriteRule, tad būtu ieteicams iepriekš minētā piemēra saturu izvietot faila sākumā nevis beigās.

Vēl viens iemesls, kāpēc būtu nepieciešams veikt iepriekš minētās darbības, ir tas, ka atstājot abas adreses (ar un bez www), iegūtie Google Analytics dati nebūs precīzi, piemēram, lietotājs, kas vispirms apskata http://www.mansdomens.lv un pēc tam atver http://mansdomens.lv, tiks uzskatīts kā jauns lietotājs.

Situācijas uzlabošanai būtu arī ļoti ieteicams piereģistrēt Google Webmaster Tools abas url adreses (www.mansdomens.lv un mansdomens.lv). Pēc tam šajā Google rīkā, kad esam iegājuši domēna www.mansdomens.lv profilā, ir jāatver Site Configurations -> Settings un pie Preferred domain jānorāda vajadzīgo (ar vai bez www). Ieguvums no tā būs visai ievērojams – ja būsim norādījuši Display URLs as www.mansdomens.lv,  tad visas saites uz mājas lapu, ko Google atradīs formā http://mansdomens.lv, tiks uztvertas, kā saites uz http://www.mansdomens.lv, nevis http://mansdomens.lv. Papildus tam arī Google meklēšanas rezultātos, tiks uzrādīts izvēlētais variants.

Šis ir viens no vienkāršākajiem SEO paņēmieniem, ko būtu pa spēkam veikt arī neprogrammētājiem. Arī turpmāk turpināšu dalīties informācijā, ko savā ikdienas darbā (kas nav tieši saistīts ar SEO) uzzinu par SEO principiem un paņēmieniem.

/public_html

Publiski pieejamais kods (css, bildes, javascript faili u.tml.)

/private

Php faili, kuros atrodas kods, kas veic pašas aplikācijas pieprasījumu apstrādi un izpildi, datu atlasīšanu no datu bāzes u.tml.

/public_html/index.php

Lielākoties PHP MVC ietvaros tiek lietots Frontend pattern arhitektūra, t.i. kad visi pieprasījumi tiek apstrādāti centralizēti. Tā arī šeit ir realizēts, tas, ka katrs pieprasījums izsauc index.php failu, no kura tālāk jau tiek izsaukta attiecīgās ietvara klases un metodes, kas veic pieprasījuma apstrādi un atbilstošās Controller klases un metodes atrašanu.

$c = new Framework_Bootstrap();
$c->route();

Bez augstāk esošā koda, vēl arī index.php failā tiek definēti ceļi uz aplikācijas komponentēm.

/public_html/.htaccess

Lai varētu nodrošināt to, ka katrs pieprasījums tiek veikts caur index.php failu, .htaccess failā  ir jāieraksta sekojošais:

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css|swn|html|xml|txt|swf)$ index.php

/private/library

Atrodas ietvara klašu faili, kā arī 3rd party klašu bibliotēkas, piemēram, bilžu apstrādes klase, PDF ģenerēšanas klašu bibliotēka u.c.

/private/config/db.php

Datu bāzes konfigurācijas fails.

<?php
define('DB_HOST', 'localhost');
define('DB_USER', 'user');
define('DB_PSW', 'psw');
define('DB_NAME', 'databasename');
?>

/private/app/models

Atrodas klases, kas veic darbības ar datu bāzi (Model slānis). Katrai datu bāzes tabulai parasti tiek izveidota viena atsevišķa Model klase, piemēram, šinī gadījumā tas ir Product.php.

<?php
class Product extends Framework_Db
{
private $_table = 'product';
private $_pk = 'productId';

function getAll(){
$query  = "SELECT * FROM $this->_table";
return $this->selectAll($query);
}

function insert($productName){
$data = array(
'productName' => $productName
);
return parent::insert($this->_table, $data);
}
}
?>

Kā redzams piemērā iepriekšējo datu bāzes vaicājumu

SELECT * FROM product

esam pārvietojuši atsevišķā Model klases metodē, kas pēc tam dos iespēju to izsaukt pēc vajadzības, nepārrakstot vairākkārtīgi pašu datu bāzes vaicājumu. Tāpat arī šeit tiek likti visi pārējie datu bāzes vaicājumi, kas attiecas uz datu bāzes tabulu product, piemēram, metode insert($productName). Klase Product tiek paplašināta ar ietvara klasi Framework_Db, kas nodrošinās sql vaicājumu sagatavošanu un datu atgriešanu no datu bāzes.

/private/app/backend

Satura pārvaldības sistēma (CMS), kas ir atsevišķi atdalīta no lapas apmeklētājiem publiski pieejamās daļas, piemēram, atrodas subdomēnā cms.mansdomens.lv. Šāda pieeja ļauj izstrādāt no lapas apmeklētājiem publiski pieejamās lapas satura, atdalītu sistēmu, bet tomēr atļaujot kopīgi izmantot Model klases, piemēram, datu ievietošana tabulā product, var būt nepieciešama, gan lapas lietotājiem, gan lapas administratoram, kas rediģē aplikācijas datu bāzi speciāli izveidotā cms sistēmā.

/private/app/frontend

Publiski pieejamā sadaļa. Tā kā zem frontend un backend esošā failu struktūra ir līdzīga, tad tālāk apskatīsim tikai frontend sadaļu.

/private/app/frontend/layouts

Atrodas view slāņa layout faili, kuri kalpo kā pamata html šablons, kurā noteiktās vietās tiek pievienots mainīgais lapas saturs.

/private/app/frontend/layouts/index.phtml

</pre>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Paraugs</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
</head>
<body>
 <?=$this->layout['center']?>
</body>
</html>

<?=$this->layout['center']?> vietā tiek ievietots konkrētā piepasījuma view fails, kuru apskatīsim vēlāk.

/private/app/frontend/modules

Tā kā tiek veidota modulāra aplikācija, tad tiek veidoti moduļi, kas katrs sevī var saturēt vairākas Controller un View komponentes.

/private/app/frontend/modules/product/controllers

Product moduļa Controller slānis.

/private/app/frontend/modules/product/controllers/PrintController.php

Product moduļa Controller klase.

<?php
class Product_PrintController extends Framework_Controller {
 function indexAction(){
 require_once PATH_TO_MODELS.'Product.php';
 $o_product = new Product();
 $this->view['product'] = $o_product->getAll();
 $this->layout['center'] = $this->render('index');
 $this->layout();
 }
}
?>

Web aplikācijas adrese, lai izsauktu product moduļa PrintController klases indexAction() metodi, būs mansdomens.lv/product/print vai mansdomens.lv/product/print/index.

Kā redzams PrintController klases indexAction() metodē, tad tiek izsaukta Model slāņa Product klases metode getAll(), kas atgriež masīvā visu produktu sarakstu un šis masīvs tiek noglabāts mainīgajā $this->view['product'], kura vērtībām pēc tam varēs piekļūt view slāņa failos.

Metode $this->render(‘index’); ģenerē attiecīgā Controller, attiecīgās Action metodes view failu (/private/app/frontend/modules/product/views/print/index.phtml).

$this->layout(); izsauc /private/app/frontend/layouts/index.phtml failu, kurā tiek ierakstīts $this->layout['center'] esošā view faila vērtība, līdz ar to iegūstot gatavu html lapu, kas ir redzama lietotājam.

/private/app/frontend/modules/product/views/print/index.phtml

Product moduļa View slāņa fails. Šeit tiek likts html izejas kods, kas tiek iekļauts layouts html failos.

<table>
<tr>
<th>produkts</th>
<?
foreach($this->view['product'] as $row) {?>
 <tr><td><?=$row['productName']?></td></tr>
<? }?>
</tr>
</table>

Šīs ir tikai viens no veidiem, kā varētu realizēt Model View Controller arhitektūru. Lai iegūtu labāku priekšstatu par šo tik izplatīto arhitektūru, iesaku pašiem praktiski pamēģināt vairākus piemērus, lai izprasto šo tēmu labāk:

• http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
• http://www.yiiframework.com/doc/guide/basics.mvc
• http://framework.zend.com/docs/quickstart

Yii Framework ir jauns PHP ietvars, kuru izveidojis Prado framework izstrādes komandas bijušais dalībnieks Qiang Xue. Pirmā alfa versija tika izdota 2008. gada oktobrī un ieguvu lielu web izstrādātāju kopienas ieinteresētību, jo Yii ietvars pārspēja konkurējošos ietvarus ātrdarbībā, neskatoties uz to, ka piedāvāja līdzvērtīgas iespējas. Yii ietvarā JavaScript atbalstam tiek izmantota JQuery bibliotēka, tas ir ērtā veidā paplašināms ar 3rd party klasēm, kā arī ar Yii Framework palīdzību ir iespēja ģenerēt aplikācijas kodu – ir nepieciešams tikai izveidot datu bāzi un no komandrindas izsaukt koda ģenerēšanas funkcijas, kas izveido būtisku daļu no aplikācijas funkcionalitātes. Yii Framework ir ietekmējies no vairākiem citiem populāriem ietvariem:

• Prado - šis ietvars ir galvenais ideju avots Yii Framework realizētajai arhitektūrai. Yii no Prado ir paņēmis komponentu bāzēto (component-based) un notikumu vadīto (event-driven) programmēšanas paradigmu, datu bāzes abstrakcijas slāni, modulāro aplikācijas arhitektūru, internacionalizāciju, lokalizāciju un daudzas citas īpašības.
• Ruby on Rails – Yii ir mantojis aplikācijas konfigurācijas paražas, kā arī active record dizaina šablonu.
• Symfony – no šī ietvara Yii ir īstenots filtru dizains un spraudņu (plug-in) arhitektūra
• Joomla – modulārais dizains un ziņojumu tulkošanas shēma

Kā jau minēju, Yii piedāvā visai ievērojamu ātrdarbības pārākumu pār konkurējošiem PHP MVC ietvariem.  Tas ir panākts tādā veidā, ka Yii Framework arhitektūrā klašu faili netiek iekļauti līdz brīdim, kamēr klase tiek lietota pirmo reizi, kā arī objekti netiek veidoti līdz brīdim, kamēr nenotiek vēršanās pie tiem. Citos ietvaros būtisks ātrdarbības zudums rodas dēļ tā, ka katrā pieprasījumā tiek iekļauta arī tā funkcionalitātē, kas nav vienmēr nepieciešama, piemēram, datu bāzes konekcijas, sesiju atbalsts utt. Kā redzams zemāk esošaja attēlā, Yii ietvara ātrdarbības būtisks uzlabojums ir panākams, izmantojot APC paplašinājumu.

Vēl no Yii Framework iespējām ir jāpiemin dizaina tēmu atbalsts, kas ļauj nomainīt aplikācijas izskatu vienā mirklī. Tāpat ir realizēta slāņota kešošanas shēma (layered caching scheme), kas nodrošina datu, lapu, fragmentu un dinamiska satura kešošanu. Kešinga uzglabāšanas vide var tikt viegli mainīta bez aplikācijas koda izmaiņām. Yii Framework izstrādātāji ir padomājuši arī par aplikāciju drošību, ieviešot dažādus aizsardzības mehānismus, piemēram, aizsardzību pret cross site scripting (XSS), cross-site request forgery (CSRF) u.c. izplatītākajām web aplikāciju ievainojamībām. Vēl ir jāpiemin tas, ka Yii ir atbalsts lietotāju veidotiem Yii ietvara paplašinājumiem, kas, līdzīgā veidā kā WordPress spraudņu (plugin) mehānisms, padara praktiski neierobežotu ietvara iespēju klāstu.

Vairāk par Yii Framework iespējām var atrast šeit.

Biežāk dzirdētais arguments ietvaru neizmantošanai ir tas, ka tie patērē liekus resursus, bet no otras puses ir jāpadomā tas, cik daudz no mūsu veidotajām aplikācijām ir tādas, kurām sagaidāmais apmeklējums ir tik milzīgs, ka ietvara darbībai esošie resursu patēriņš radīs nepieciešamību veikt tādus ieguldījumus serveru resursos, kurus nevarēsim atļauties. Manuprāt web aplikāciju izstrādātājiem lielākoties sanāk veidot aplikācijas, kur primārais ir tas, cik ātri un viegli mēs varam to realizēt, nevis panākt maksimāli iespējamā ātrdarbība un, ja tas ir tā, tad kāpēc gan neizmantot ietvarus, kas būtiski samazina rutīnas darbu, kā arī radina programmētājus pie labās programmēšanas prakses, piemēram, atdalot html izvadu no datu bāzes un biznesa loģikas slāņa, tādā veidā samazinot koda dublēšanos, kas nākotnē atvieglos projekta tālāku attīstību un iespēju arī kādam programmētājam no malas turpināt mūsu iesākto darbu.

Nobeigumā vēl maza karikatūra, kas lieliski raksturo to, kāpēc, veidojot aplikācijas kodu, būtu vērts vadīties pēc programmēšanas labās prakses.

Iedomāsimies, ka gribam realizēt web projektu x un ir nepieciešams profesionāls, oriģināls web dizains, kura cena ir, piemēram, 500 Ls. Pirmais veids, neizmantojot barteri, būtu tāds, ka mēs ar saviem pakalpojumiem, piemēram, programmēšanu, šos 500 Ls nopelnam, bet šādā veidā ceļš līdz mērķim (dizainam 500 Ls vērtībā) būs garāks, jo mums ir jāatrod klients, kam ir nepieciešami mūsu pakalpojumi, jāstrādā pie projekta un tad nopelnīto naudu varam samaksāt par mums nepieciešamo dizainu. Bartera veidā tas būtu daudz vienkāršāk – ir jāatrod dizaineris, kam ir nepieciešami mūsu programmēšanas pakalpojumi un jāstrādā uz pakalpojumu apmaiņas principa – 500 Ls vērti programmēšanas pakalpojumi apmaiņā pret 500 Ls vērta dizaina izstrādi. Tas ir tikai mazs maiņas tirdzniecības piemērs. Bez iepriekš minētā piemēra, es arī dažiem klientiem esmu sācis piedāvāt izstrādāt bezmaksas mājas lapu, kā arī nodrošināt bezmaksas hostingu, apmaiņā pret iespēju izvietot šajā bezmaksas mājas lapā teksta saites.

Latvijā arī ir parādījušies vairāki projekti, kas piedāvā publicēt savus piedāvājumus maiņai.

www.mainamies.lv – Jāuzslavē labi realizētā iespēja redzēt, kas piedāvā mainīties tuvumā tavai dzīvesvietai. Mazais trūkums pašlaik šim projektam ir tas, ka nav izveidota sadaļa pakalpojumu maiņai, jo tieši tas ir būtiski daudziem uzņēmumiem.

www.dotspretdotu.lv – Atsevišķi atdalīti privātpersonu un uzņēmumu maiņas tirdzniecības sludinājumi. Izveidota sadaļa arī pakalpojumiem. Pārskatot sludinājumus rodas mazas problēmas, jo nevar uzreiz redzēt pret ko tiek piedāvāts mainīt konkrēto preci vai pakalpojumu, kā dēļ ir jāatvērt katrs sludinājums, kur to var apskatīt.

www.samaini.lv (www.barteris.lv) – Sludinājumu sarakstā uzskatāmi parādīts kas un pret ko tiek piedāvāts. Lietojot pirmajā brīdi rodas mazas neskaidrības ar kategoriju sadalījumu, piemēram, lai atrastu to, kas piedāvā pakalpojumu maiņu ir jāatver sadaļa Darbs->Intelektuālais darbs un tad kāda no sadaļām, bet pakalpojumu sludinājumus var atrast arī zem sadaļas Dažādi->Pakalpojumi, kurā ir jau citi pakalpojumu sludinājumi.

RegExr – rīks, kurā var atrast daudz un dažādus lietotāju iesūtītos regulāro izteiksmju šablonus, kā arī iesūtīt pats savus. Iespēja pārbaudīt ir ne tikai virkņu validāciju, bet arī izteiksmes virkņu pārveidošanu (replace).  Pieejama arī Desktop aplikācija.

Flex 3 Regular Expressions Explorer – Līdzīgi kā RegExr, arī šis rīks piedāvā jau vairākus gatavus regulāro izteiksmju šablonus, kā arī atverot kādu no tiem, ir redzami arī vairāki testa piemēri. Nav iespējas pārveidot teksta virknes pēc regulārās izteiksmes šablona.

DooPHP ātrdabība

Vairums ietvaros ir mēģināts realizēt visu iespējamo, tie ir pārpilni ar visdažādākajiem spraudņiem un komponentēm, tiek pat mēģināts automātiski ģenerēt publiski pieejamo aplikācijas daļu (frontend). DooPHP nav centies iet šo ceļu – DooPHP ietvarā netiek nekas lieks ielādēts, tikai nepieciešamās lietas, lai tiktu uzģenerēta lapa. Attēlā var aplūkot šī ietvara izstrādātāju ātrdarbības testus salīdzinājumā ar citiem PHP ietvariem.

Pie testiem interesanti ir arī apskatīties stresa testēšanas veiktspēju katram no ietvaram, kas tika salīdzināti. Testā tika padoti vienlaicīgi ik pēc laika 1000 pieprasījumi (kopā 10000 pieprasījumi) un salīdzināts apstrādāto pieprasījumu skaits 30 sekundēs. Stresa testēšanas rezultāti:

• DooPHP – kopā apstrādāti 6757 pieprasījumi
• CakePHP – kopā apstrādāti 685 pieprasījumi
• Yii – kopā apstrādāti 2315 pieprasījumi
• CodeIgniter – kopā apstrādāti 2107 pieprasījumi
• QeePHP – kopā apstrādāts 1780 pieprasījums

Vairāk par DooPHP ātrdarbības testiem – http://doophp.com/benchmark

DooPHP funkcionalitāte

Kaut gan DooPHP prioritāte ir ātrdarbība, nav atstātas novārtā arī cita būtiska ietvara funkcionalitāte:

• Model View Controller arhitektūra
• URI maršrutēšana (routing)
• I18n
• Centrālā konfigurācija
• Datubāzes ORM rīki
• HTTP autentifikācija
• Autorizācija
• Kešošana (caching)
• RESTful API
• Templating sistēma
• Koda ģenerēšanas iespēja
• Atbalsts Ajax projektiem

Lai sāktu apgūt DooPHP ietvaru, var sākt ar šo ievadu, kā arī noteikti noderēs izstrādātāju veidotais blogs, kurā viegli uztveramā veidā tiek pastāstīts, kā veidot aplikācijas ar DooPHP. Tajā ir atrodamas pamacības ne tikai jau oficiāli iznākušajām versijām, bet arī jaunākajai izstrādes versijai, kuru var lejupielādēt ar kādu no SVN rīkiem, piemēram, es izmantoju Tortoise SVN. Oficiāli iznākušajām versijām ir pieejams arī API.

Šeit var apskatīt mazu piemēru, kāda veidā DooPHP notiek lapas kartes (sitemap) un controller klašu ģenerēšana:

Secinājumi

DooPHP ietvars pagaidām ir tikai dažus mēnešus jauns (pirmā oficiālā versija 1.0 tika izlaista 2009. gada jūlijā), tomēr tā izvēlētais ceļš ir pietiekami daudzsološs un atšķirīgs no universālo PHP ietvaru (Zend Framework, Symfony u.c.) principiem. Lai rastos skaidrāks priekštats par ietvara lietošanas ērtumu, kādu no nākamajiem web projektiem centīšos realizēt izmantojot tieši DooPHP ietvaru.

Šis barters ir sekojošs – es palīdzu izveidot mājas lapu, blogu, interneta veikalu cenā līdz 100 Ls, kā arī  izvietoju uz servera šo mājas lapu, neprasot par to samaksu, bet, apmaiņā pret to, šinī mājas lapā izvietoju vairākas teksta saites (līdz 15) uz citām lapām. Rezultātā klients tiek pie bezmaksas mājas lapas un hostinga, savukārt mans ieguvums ilgtermiņā ir tāds, ka,  izvietojot saites citās mājas lapās, iegūstu iespēju celt atslēgvārdu Google pozīcijas saviem un citiem projektiem. Ja kādu ir ieinteresējusi iespēja šādā bartera veidā tikt pie bezmaksas mājas lapas (vai 100 Ls atlaides) un bezmaksas hostinga, tad ar mani var sazināties izmantojot šo kontaktformu:

Vēl ikdienas darbu lieliski atvieglo drag’n'drop iespēja ar citām programmām, piemēram, pēdējos 100 ekrānuzņēmumus, kas tiek saglabāti vēsturē, varu uzreiz ievietot Open Office dokumentā, vai pievienot e-pasta pielikumā Outlook vai kādā citā e-pasta klienta programmā. Ja vēlamies iegūt ekrānuzņēmumus no kādas tīmekļa vietnes pilnā garumā, tad noderēs Image Stich iespēja – vairākus ekrānuzņēmumus ar vienādiem izmēriem savienot vienā bildē. Lejupielādēt šo programmu var šeit.

Šo problēmu izdevās atrisināt pavisam vienkārši – konfigurēju WordPress instalāciju, lai e-pasti tiktu sūtīti caur SMTP serveri, piemēram, Gmail. Šī mērķa sasniegšanai var izmantot jau gatavus risinājumus, piemēram, HGK SMTP spraudni. Kad tas uzstādīts, tad atliek vien to nokonfigurēt:

Gmail konta vietā var rakstīt arī e-pasta adresi no domēna, kas pieslēgts Google Apps, piemeram, info@mansuznemums.lv.