j2b

Kā jau minēju, katram darbam un vajadzībām ir savs instruments. Ja tev vajag 2 tabulas un 5 lapas, tad CMS vai Web App Framework tam nav nepieciešams. Ņem CodeIgniter vai jebkādu citu, un būsi laimīgs. Ja vēlies izmantot Web App Framework funkcijas, un visu no sākuma nerakstīt, bet jau izmantot kā gatavas sastāvdaļas, tad tur var sākt skatīties. Un kādēļ lai šādu sistēmu nesauktu par framework? No linka: http://en.wikipedia.org/wiki/Web_application_framework Features sadaļa. Ja nezināji, ka Drupal to var nodrošināt, tad kādēļ vari izteikt tādus apgalvojumus? Tabulas - jā, var veidot savas pēc vajadzības. Protams, ka Drupla "uzspiestās" saglabājas, jo savādāk pats Drupal nedarbojas - tas ir App Framework, jeb drīzāk platforma, nevis programmētāju palīglīdzeklis. Bibliotēkas - kādēļ ne? URL filtrēšana un rewrite & routing - lūdzu, kā divus pirkstus ... nedomāju, ka šis jautājums ir Drupal vai kas cits, jo jebkura sistēma ir jāiemācās, un ja to zini un saprotu, tad ir kā 2 pirkstus. Ja nezini, pat ar roku būs par maz... Un jā, ja pareizi visu dara, tad visi apdeiti iet griezdamies un bez ietekmes uz savu radīto. Tā šķiet, ka esi par slinku palasīties, un vēl joprojām, cenšoties aizstāvēt savu viedokli, nesaprotu, kā šī bezjēdzīgā diskusija var palīdzēt euphoric atrisināt viņa problēmu? Ja tev Drupal nepatīk - nelieto, bet liec savas zināšanas lietā un palīdzi cilvēkam atrisināt viņa problēmu, nevis diskutē par savām pārliecībām.

Tur nav jāpīpē, bet vienkārši jālasa :) Lai arī tev tehniski varētu būt taisnība, ka Drupal nav frameworks, tad piekristu tev tikai tehniskā nosaukuma ziņā, un arī tajā, ka Drupal nav Programming Framework. Par šo patiesībā ir daudzas diskusijas. Šeit kaut vai viena: http://www.mattfarina.com/2009/02/03/is-drupal-a-web-application-framework-or-just-a-content-management-system No konteksta izņemot... ja salīdzina pamata Programmēšanas framework fīčas, tad Drupal faktiski nodrošina to pašu. Tas nekas, ka nav oficiāli dots tāds nosaukums, un potenciāli ar Wordpress, varētu būt līdzīgi. Šeit ir Wikipēdijas raksts, un nezin kādēļ, tur ir Drupal minēts. Var būt čaļi arī pīpē :) http://en.wikipedia.org/wiki/Web_application_framework Es Drupal uzskatu par Web application framework, nevis par Programming Framework.

Tā tas varētu būt, bet cik nojaušu, tad nejau pats izvēlējies šo darbiņu darīt uz Drupal, kā rezultātā ir jārēķinās ar to, kas jau ir. Veiksmi!

Ja lieto jQuery, tad ir parametrs .toggle .show/.hide vietā. Var būt tas noder...

Ja serveris ir tavā kontrolē, tad alternatīvs risinājums ir VirtualHost norādīt Redirect. http:// kā tāds nav obligāts, jo modernie pārlūki to uztver pēc noklusēšanas. www vai "cits-nosaukums" ir atkarīgs no tā, kādi ir tavi DNS ieraksti A hostam un to visu var risināt 3 veidos: DNS līmenī VirtualHost vai web servera konfigurācijas līmenī .htaccess līmenī

Tas, ka saudzē savu e-pasta adresi (kas ir visai apsveicami) tevi neglābj no tā, ka citu (saņēmēju) dators ir inficēts un nodrošina Spam listes ar tavu e-pasta adresi. Kā tu secināji, ka Gmail sūta no tava konta vēstules? Vai Gmail web vide arī norāda Sent folderī, ka tu esi izsūtījis kaut ko? Kā tu sazinies ar Gmail? (IMAP/Webmail, utt.)

Ņemot vērā to, ka šī vietne ir diezgan populāra LV vidē, gribēju ierosināt izveidot kādu no risinājumiem: Pielietot kopēju praksi (var būt pat kā ieteikumu noteikumos), ka atrisinātās problēmas, kas ir diskutētas šajā saitā vismaz Topic Titile jānomaina ar [ATRISINĀTS] priekšvādru; Var būt pastāv iepsēja IPB papildināt ar čekboxu - Atrisināts, lai veiktu vienkāršāku atzīmi sniedzot kārtējo komentāru. Tas būtu jauks žests arī tiem, kas ne tikai vēlas diskutēt ar līdzīgi domājošiem, bet arī varētu uzreiz identificēt risinājumus. Piemēram: ja meklēju konkrētu problēmu un tās risinājumu, tad tādā veidā meklētājs varētu izdot visu atrasto sarakstu, kur Title norādītu uz to, vai problēma ir palikusi "gaisā", vai tomēr ir rasts risinājums. Un ja ir, tad tieši kāds. Tas varētu rast pievienoto vērtību šim saitam. Pagaidām vienkāršākais būtu lūgt lietotājus pēc problēmu atrisināšanas ievietot papildus identifikāciju [ATRISINĀTS], pirms topika tēmas, attiecīgi to rediģējot. Bet vis labāk būtu dot tādu funkcionalitāti iesūtot pēdējo komentāru ar čekboxu. Ko domājat?

>>Rij vairāk resursu... Viss ir ļoti relatīvs. Skatoties no kāda skatu punkta tu raugies. Nav tādas sistēmas, kas būs adekvāta "vizītkartes tipa lapai" un komplicētai satura vadības sistēmai. Katrā gadījumā ir jāvērtē, vai tev un kas tev ir vajadzīgs. Tas pats jautājums varētu būt saistīts arī diskusijai PHP vai Java vai Python. Ir jābūt jēgai pielietot vienu vai otru, vai arī izvēlēties komplicētu CMS, pret vienkāršu CMS (tajā skaitā pašrakstītu PHP kodu). Visam ir savs pielietojums un sava efektivitāte. Resursu patēriņš nav PHP vai sistēmas jautājums (lai gan tā atkal ir atsevišķa tēma). Tas ir risinājumu komplekss, kuru jāvērtē pēc vajadzības, iespējām un adekvātuma. >>...kā piemēram ar parastu PHP... "Nezināju", ka PHP iedalās "parastajā" un "citā" (noprotams Drupal, kas arī ir PHP bāzēts). Ja ņem vērā ierobežojumus, par kuriem minēju iepriekšējā tekstā attiecībā uz Drupal FW kā tādu (būtiski mainīsies D7 versijā), tad jā - visu to pašu, ko var izdarīt ar "parastu PHP", to var izdarīt arī Drupal, jo arī Drupal ir parasts PHP. :) Tikai papildus nāk klāt nianses par MVC un OOP. Nav vēl parastāka! Starp citu ne tikai PHP! Tādēļ to dēvē par "Framework" vai "Application framework", nevis vienkārši kā CMS, no kā patiesībā tas arī savā laikā radās. Katrā gadījumā resursu plānošana un patēriņš, kā arī PHP versijas nebija euphoric jautājums. Līdz ar to domāju, ka, ja tevi interesē šis jautājums, tev būtu jāatver jauna diskusija. Pretējā gadījumā, kā tavs komentārs palīdz/atbild uz jautājumu euphoric? Vai arī apgāž manu piedāvājumu risinājumam?

Uzreiz ieteiktu vairākas lietas: Necensties ko mainīt Core kodā, jo tā gan ir slikta prakse, gan daudz kas var nobrukt veicot apdeitus un apgreidus. D komanda tajā ziņā ir malači. Ne tikai savas lietas labo, bet arī sabiedrības ieguldītos moduļus čeko no drošības jautājumu puses. Tādēļ Updates un Upgrades - pēc noklusējuma būtu jāuzstāda. Visu ko tev nepieciešams darīt, vis ērtāk būtu veikt savā modulī, ja tas ir loģiskais risinājums. Ja vizuālais - tad attiecīgi specifiskajā tavā Tēmā (Theme). Ja kāds to ir veicis (vismaz daļēji), centies to izmantot, jo nav jēgas lieki tērēt savu laiku, kā arī papildinot Drupal moduļu klāstu ar jaunu - Drupal paliek ar vien jaudīgāks un konkurēt spējīgāks. Mazliet vēstures: Ar Drupal es sāku patiesi mācīties web izstrādi, lai gan tas nav vienkāršākais un pareizākais ko darīt. Bet šis Freimworks (kuru būtībā pat varētu dēvēt jau par Application Framework ar CMS pamatu) var izdarīt praktiski visu. Ir daži ierobežojumi tehniskajā dizainā, bet par tiem esmu tikai lasījis, bet nekad neesmu ar to saskāries. Līdz ar to varētu teikt, ka izdarīt to var. Moduļu veidošana ir salīdzinoši primitīva. http://drupal.org/developing/modules Kā jau iepriekš rATRIJS norādīja, API ir labākā info vieta, ja nevēlies iedziļināties moduļu kaudzē un to atrašanā: http://api.drupal.org. Es vēl bieži izmantoju šo: http://www.drupalmodules.com, kas palīdz ātrāk atrast nepieciešamo. Ja nepieciešama palīdzība, dod ziņu, jo esmu pamatīgu laiku veltījis moduļu izpētei, līdz ar to varu palīdzēt ieekonomēt tavējo (laiku). Kā var būt ir nojaušams, neesmu kodētājs, tādēļ recepti kodiem neiedošu, bet varu palīdzēt sameklēt nepieciešamos moduļus un nokomentēt to uzstādījumus. Pārējais varētu būt tad tavā ziņā. Ko es būtu darījis tavā vietā, ja esmu pareizi tevi sapratis: Izmantotu sekojošus moduļus: CCK (http://drupal.org/developing/modules) - izveido vizuālu interfeisu lauku papildināšanai kontentu tipos, ieskaitot dažādus input widgets, ja tas ir būtiski. Ar šo tu jebkuru kontenta tipu vari papildināt ar sev vajadzīgiem lauciņiem un to paveidiem. Content Profile (http://drupal.org/project/content_profile) - šis dod iespēju noteiktu kontenta tipu piesaistīt kā profilu, attiecīgi ir labāk nekā lietot Core Optional Profile moduli, jo pēdējais ir ar ierobežojumiem. Content Profile gadījumā tu dabū lielu modifikācijas iespēju, tajā pat laikā to automātiski sasaistot ar konkrēto lietotāju bez papildus programmēšanas. Lauku satura testam es izmantotu kaut ko no Validation... moduļiem. Te gad bija būtiskas izmaiņas moduļos, un būtu nepieciešams konkrētāk zināt uzdevumu, lai piemeklētu vajadzīgo, bet pēc būtības var skatīt piemēru Webform Validation (http://drupal.org/project/webform_validation'>http://drupal.org/project/webform_validation). Webform modulis (http://drupal.org/project/webform) būtu izmantojams gadījumā, ja vēlies vienkārši savākt datus no klienta tos pēc būtības nesaistot ar lietotāju, bet tas laikam ir kas cits. Tālākās darbības: Izveidotu jaunu kontenta tipu, attiecīgi ar CCK palīdzību papildinot to ar nepieciešamajiem lauciņiem. Katram papildus lauciņam ir iespējams nodefinēt, vai tam ir jābūt pieejamam lietotāja reģistrācijas formā. Atkarībā no uzdevuma nodrošinātu šo lauciņu validāciju. Pārējais viss notiktu Drupal ierastā garā. Manā gadījumā labākais tajā visā ir tas, ka nebūšu patērējis laiku un uzrakstījis nevienu kodu - viss ir pieejams UI. Ja nepieciešama palīdzība, dod ziņu iekš Private message, tiksim galā.

Vai ar šo tu domāji ka nepieciešami papildus jau esošajiem user laukie jauni savējie? Ja jā, tad ir divas iespējas. Viena lieta būtu lietot pamata moduli Profile, attiecīgi papildinot ar vajadzīgajiem laukiem, otra, var izmantot CCK un Content Profile, kas dod lielākas iespējas. Iepriekš reģistrēto lietotāju datu papildināšana šajā gadījumā būtu atsevišķa dziesma. Kas precīzāk būtu nepieciešams?

Tā problēma ir tajā, ka to jau dara Joomla, un kaut kā to pasniedz. Tomēr es pašlaik vēl neesmu dziļāk pētījis Joomla kodus attiecīgajam modulim, lai izprastu funkcijas. Līdz ar to rezultātā to rakstu var apskatīt gan Teaser skatā, gan Full article skatā. Bet nianse ir tajā, ka standarta Joomla modulis nemaina neko CSS stilu klasēs, lai ar CSS varētu apstrādāt vienu vai otru variantu. Klases objektiem ir pilnīgi vienādas. Līdz ar to šis risinājums pagaidām neiet. Biju domājis, vai nevar iegūt kādus linkus risinājumiem, lai panāktu, ka Joomla modulis izdodot galējo HTML kodu, faktiski piedāvātu šīs klases nomainīt. Un tad jau viss būtu vienkārši.

Varu, bet vairāk pats specializējos uz dizaina ieviešanām, nekā kodēšanu. (PHP pārvaldu ļoti primitīvā līmenī) Kā arī domāju mazliet ieekonomēt sava laikā, pirms ķeros klāt kodu izprašanai, jo var būt kāds jau ar to problēmu bija saskāries.

Joomla forumā diemžēl neizdevās piereģistrēties, tādēļ nolēmu apjautāties šeit. Var būt kāds var līdzēt ar ideju vai virzienu Joomla sakarā. Problēma: Joomlā rakstu var apskatīt divos veidos - Teaser veidā (piemēram blog tipa attēlošanas rezultātā) un pēc klikšķināšanas uz Title, attiecīgi Full article. Nepieciešams pielietot dažādus CSS stilus vienam un otram skatījumam (Tieši Teaser daļai). Tomēr pētot HTML kodus, Joomla nepapildina neviena div klasi, kas varētu norādīt uz to, vai raksts ir Teaser vai Full view. Vienīgā atšķirība, kuru pamanīju, ir tā, ka Full view raksts ir ievietots mazāk tabulās, nekā Blog view, bet tomēr klases nav definētas. Tā rezultātā uzskatu šo par nedrošu risinājumu, uz ko balstīties. Jautājums: Vai kāds varētu ieteikt risinājumu šajā jautājumā, ja ar to ir bijusi saskarsme?

Man šķiet, ka tāda pati kā IK. Vis efektīvākais ir mazais SIA, jo tad uzņēmums atbild tikai ar kapitālu un savu mantu (protams, līdz to 2k uzkrāšanai ir mazliet savādāk). Par šo atbildību tomēr iesaku aizdomāties. Kā jau minēts iepriekš, nav jau lielas ziepes jāsavāra, lai nonāktu uz paklāja un sāktu domāt, kā to visu nokārtot.