coderpp

Ok, aizmirstiet. Nav labi naktī ko taisīt :D Problēma tāda, ka kamēr dati lādējas pārējās kods jau ir izpildījies. Vienkārši līki sakodēts :D

Nu Firebug rāda pilnu pieprasījuma linku. Nokopējot viņu un iekopējot pa taisno pārlūkprogrammā viss notiek. Fails uzģenerē datus un tie tiek izvadīti.

Pielikumā redzams, ko rāda firebug. Pie tam uz to pašu failu tiek veikti arī citi pieprasījumi - tie strādā.

Sveiki,

problēma tāda, ka netiek ielādēti json dati. Firebug rāda, ka no faila nav nekādas atbildes, bet atverot tieši browserī pieprasijuma linku, dati tiek izvadīti. json dati ir valīdi. tika pārbaudīti šeit - http://www.jsonlint.com/

Kods, kam butu jāielāde dati:

$.getJSON(
'json.php?type=images&action=load',
{id : $("#gallery_id").val(), lang: "lv"},
function(data){
}
);

Dati, kādus ģenerē pieprasītais fails:

{"4d6977ff07ef4.jpg":"","4d69786a4fed0.jpg":"","4d6978be27033.jpg":"","4d6979dd1f0ae.jpg":"","4d697c44cbc88.jpg":"","4d697f758cc91.jpg":"","4d698059c0256.jpg":"","4d6981cf72575.jpg":"","4d69835707c5a.jpg":"","4d698468c257b.jpg":"","4d6985852278a.jpg":""}

Man ar to primitīvo pietiek.

Nu ok, tās f-jas var apvienot. Bet tad būs papildus parametrs type. Nafig man tas vajadzīgs? Es taisu tā, lai ir ērtāk man to lietot.

Ko tu uzbāzies ar tiem namespace? Nu neintersē man viņi tagad.

Ko tad es gvelžu? Man autoload ir tikai un vinigi priekš klašu automātiskas ielādēšanas. Ar to pietiek. Vari lipināt kopā visu ko vēlies.

Nemēģināju, joprojām to arī daru. Negribas mācīties citus/gatavos frameworkus. Doma izveidot, kaut ko minimālu uz kā varētu nedaudz vieglāk/ātrāk turpmāk veido mājas lapas.

Kāpēc nedod? Manām vajadzībām der.

Kāda jēga? Jēga tāda, ka lai izveidotu formas, man turpmāk nebūs jāraksta tie visi xhtml tagi. Manuprāt dzīve uzreiz vieglāka. :)

Nepatīk man namespace pieraksts, tos kaut kā negribu lietot. Par autoload esmu jau lasījis. Taij nelielajia daļai, kas man ir esmu izveidojis autoload klasi. Ārāk vai vēlāk tā nonāks arī šeit.

Man arī nepatīk statiskās funkcijas. Kāda jēga no viņām vai drīzāk kāds labums ka viņas lieto?

Paskatījos formu helpera klasi. Pa lielam protams man nav kur piekasīties, vienīgi pietrūkst metodes, kas uzģenerē label tagu, jo es pats personīgi labeļus lietoju sakarā ar formām.

 

Vēl man neškiet labi, ka viss HTML kods tiek salīmēts kopā pa daļām un tad vienā brīdī izvadīts. Labāk būtu ka katrs metodes izsaukums izvadītu savu HTMLu.. Jo nu pagrūti ir tagad uztaisīt formu, saliekot input laukus sarakstā vai tabulā vai kā labāk katram patīk

Par label piemirsu pārrakstot. :( Man jau bija šis klases kaut kā sarakstītas un vienkārši pārrakstu pielikot šo to klāt. Pats arī bieži lietotju label-us.

Ir iespējams izvadīt - echo $forma->input('vards');

Man kaut kā negribas apvienot.

1)Es parasti controller-a un view-a klases apvienoju vienā, jo manā izpratnē ar view-u sazinās tikai un vienīgi controller-is un to dara lielākajā daļā gadījumu, tāpēc neredzu jēgu tos atdalīt.

 

2)Tāpat parasti izmantoju nevis maģiskās __get __set metodes, bet gan ArrayAccess implementāciju, tā rezultātā datus templeitam padodu $this['title']="Hello World", nevis $this->title="Hello World". Priekšrocība tam ir tāda, ka klases propertiji nejaucās ar templeitam padodamajiem datiem.

 

3)Ļoti bieži kopējais layout-s nav pliks layout-s, bet satur kādu mainīgu informāciju, tā var būt lietotāja jauno vēstuļu skaits, u.c., tāpēc es parasti daru tā, ka arī layout-am ir controller-is, kurš attiecīgi nodrošina datu apstrādi priekš pamat layout-a. Patiesībā man layout-s būtībā ar neko neatšķirās no parasta controller-a ar template-u, tikai atšķirība tā, ka parastam controller-im viņš ir norādīts kā parent-s, bet pats layout-a controller-is satur parametru, kurš norāda, ka viņš nav pa tiešo pieejam request-am.

1) Man kaut kā negribas apvienot.

2) Nesapratu, kas tur īpaši var jaukties. Vai vēl kādi plusi tādai metodei?

3) Es daru tā, ka ir kontrolieris, kurā konstruktorā tiek izveidots kaut kāds defaultais layouts + norādu visur nepieciešamos css un js failus. Beigās destruktorā šo layoutu zīmēju. Šo kontrolieri nevar izsaukt pa tiešo. Piemēr sākumlapai taisu kontrolieri indexController kas ekstendo Controller klasi. Tajā veidoju tad tālāk funkcijas, defaultā index, kas parasti izvada tikai kaut kādus datus. Šajās funkcijās tad arī ielādējo skatus. Par to kā darboties ar tādiem datiem vēl neesmu aizdomājies. Kaut kā tā. Gan jau kaut kad, tās arī sarakstīšu, tad arī iemetīšu te lai var arī par tām padiskutēt.

Lieta tāda, ka zemāk ir ievietotas adreses uz 3 manis rakstītām klasēm. Ko sagaidu no Jums? Kritiku, ieteikumus, padomos kā nedarīt vai arī kā labāk darīt.

view.class.php

layout.class.php

form.helper.php

Paldies.

Tātad pie katras izmaiņas jauns ieraksts revizijā.

Kā darīt ar tiem, kas veic izmaiņas? Rādīt tikai jaunāko revīziju, vai arī visas? Adminam ta skaidrs, vinam jāredz visas.

nepareizi ...

Buus gruutak uztaisiit lai raadas PAREIZAIS varjants...

--

Kāpēc?

Ir texts publiskajā laukā un rediģēšanas laukā. Ja saturs vienāds, nekas ar to sadaļu/rakstu nav darīts. Ja nav vienādi, tad parādam kādu paziņojumu, kad tur veiktas izmaiņas. Admins to redzot, apskatās publicē vai arī nepublicē.

Pareizais variants vienmēr skaitās tas, kurš ir bijis publicēts neatkarīgi no tā vai tur veiks vai neveiks izmaiņas.

Piem, tev būs scenārijs -

 

tiek pievienots raksts, nav redzams publikai. Tad admin apstiprina, un tad kļūst redzams visiem. ..bet tad tiek veiktas izmaiņas - vecā raksta versija joprojām ir redzama visiem, bet jaunās izmaiņas vēl nav apstiprinātas. Kad jaunās izmaiņas apstiprina, tad vecais raksts tiek aizstāts ar jauno?

Jā tieši tāda arī ir tā prasība un man nekas cits neatliek kā to darīt.

Ja tāda ir situācija, tad varētu rakstus glabāt vienā tabulā. Tabulas kolonnas: publiskais teksts, nepubliskais teksts, raksta statuss..

Paldies, tik tālu nebiju aizdomājies. Domāju ka šis būs labākais variants. Būs arī vieglāk parādīt atbilstošajam lietotājam vai izmaiņas ir veiktas.

Neuztraucies, man ar smadzenēm viss kārtībā.

Es jau ar par tādu variantu esmu iedomājies. Bet ar ko tad īsti atšķirsies?

Pirmajā gadījumā 2 tabulas, Otrajā viena tabula, bet informācija 2x vienā tabulā. Ideja ir tāda. Pimēram ir sadaļa noteikumi, kura jau ir publicēta, bet sistēmā to ir iespējams rediģēt, bet izmaiņas nedrīkst uzreiz parādīties publiski. Tās vispirms apskatīs un tad pārbulicēs augstākstāvoš lietotājs. Tātad šajā situācijā jebkurā gadījumā visam saturam jābūt divās kopijās, viena publiskā, kuri redz lapas apmeklētāji, otra ar kuru var strādāt cms lietotāji.

Cik saprotu tad divas tabulas ar viena veida struktūru nav labi veidot. Bet tas ļautu glabāt atsevišķi publisko informāciju.

Mani interesē, kādi varianti vēl varētu būt šādai situācijai.

Jāizveido sistēma, ar vairāk lietotāju piekļuvi. Vieni var rediģēt saturu, bet tas neparādās publiski. Tad ir augstākstāvoši lietotāji, kuri šīs izmaiņas apskatot/piekoriģējot var tās publicēt lapā.

Kā pareizi veidot datubāzi šadai sistēmai?

Vienkāršākais laikam taisīt divas vienādas tabulas, ar dažādiem nosaukumiem. Viena priekš rediģēšanas, otra tikai gatava materiāla glabāšanai priekš publiskās lapas. Vai šāds varinats ir normāls? Vai arī ir kādi labāki risinājumi šādai situācijai.