Jump to content
php.lv forumi

rATRIJS

Moderatori
  • Posts

    1,505
  • Joined

  • Last visited

Everything posted by rATRIJS

  1. Es īsti nesapratu, bet paskaties PHP dokumetāciju. ob_flush: This function does not destroy the output buffer like ob_end_flush() does. Lai iegūtu bufferot'os datus, izmanto, piemēram, ob_get_contents()
  2. Vienmēr var aizsūtīt e-pastu un pajautāt kas būs jādara. Manuprāt, būs jāveido mājaslapas (no way). Nesaprotu kādēļ vienmēr būtu jānorāda kas TIEŠI būs jādara. Prasīts ir - ko vajag zināt. Ja atbilsti prasībām tad piesakies, ja nē, tad nē. Viss...
  3. Runa ir par problēmu tavā lapā vai vispār? Cik es sapratu, tad vispār - sliktākajā gadījumā vienmēr var pārinstalēt firefox (vai arī slēdz ārā pa vienam add-on'us un skaties kurš traucē)
  4. rATRIJS

    Smarty

    Nepadalīšos gan ar pieredzi, bet pasūdzēšos sakot, ka neredzu jēgu tādai templeitu valodai :) Manuprāt, ir vienlīdz ekvivalenti lietot šādu lietu (šis ir improvizēts piemērs, jo es nezinu Smarty sintaksi - kā piemēru ņēmu Liquid (viena no Rails templeišu valodām) sintaksi) {% for category in categories %} Kategorija: {{ category->name }}<br /> {% endfor %} un šādu <?php foreach($categories as $category) { ?> Kategorija: <?php echo $category->name ?><br /> <?php } ?> Ir vienlīdz viegli apgūt kā vienu - tā otru (ja skatās no dizaineru viedokļa). Ja Smarty piedāvā arī ko tādu, ko parasti piedāvā vienkārši Framework'i, tad vēl ir OK, bet ja nē, tad nu paldies, bet neredzu tam vispār nekādu jēgu. + ja mainās sintakse pa versijām, tad vispār trakums... Vienīgā templeišu valodas izmantošana, kuru redzu, ir, lai veidotu kaut kādas semi-static lapas ar nelielu dinamisku saturu un lai parasts lietotājs varētu pamainīt šīs lapas uzvedību nedaudz. Ar šo var nedaudz samazināt kaut kādus drošības coķus...
  5. Nav jau arī tik traki, ja lietotāju dati nedaudz dublēsies - aka ja būs divas tabuas, viena priekš phpBB, otra tavai lapai. Man vienai lapai tā nācās darīt, jo forums ar pašu lapu bija maz saistīts, kā arī visas lietotāju lomas nav atkarīgas starp forumu un pašu lapu - tad nu ir phpBB users tabula un mana users tabula. Ja nu tu izvēlies tā darīt, tad nāksies pacīnīties ar šo divu tabulu sinhronizāciju (ja izdzēs kādu no foruma, tad arī no lapas izdzēšanas, piemēram). Tātad nāksies paurbties iekš phpBB core funkcijām un tās pamainīt. Tāpat, noteikit, vajadzētu sapludināt kopā lietotāju autorizāciju - ja lietotājs iežurnalējas forumā, tad arī pašā lapā viņš ir autorizējies un otrādāk (es izmantoju izmainītu phpBB autorizāciju). Priekšā es neko nerakstīšu, jo tas nav izdarāms, viens, divi, bet paskatot phpBB dokumentāciju visam vajadzētu būt saprotamam... Bet nu nevajadzētu taisīt divas tabulas, ja vien nav galēja nepieciešamība... Manuprāt, vienkārši, atstāj divus administrācijas paneļus - vienu forumam, otru lapai.
  6. Es ceru, ka tu nedomā, ka kāds tev pa velti "uzkodēs skriptiņu"
  7. Neko tu par to klikšķināšanu nenopelnīsi...
  8. Ārzemēs freimwork'i ir ļoti populāri. Man pat liekas, ka reti kur izmanto pliku PHP (vai jebko citu). PHP gan tur nav vispopulārāk izmantotais, toties ASP.NET ir visur (es šobrīd pa Lielbritāniju runāju) pieprasīts - es gan īsti nesaprotu kādēļ, jo man viņš neliekas īpaši ērts. Ja skatamies darba piedāvājumus par PHP, populārākie freimwork'i ir Code Igniter un Zend. Esmu papētījis Code Igniter, taču ja ir lietots Rails, kuram viņi cenšas līdzināties, tad viņš liekas tāds nedaudz saspīlēts un ne-tik-tīrs. Runājot par Smarty templeitiem - es arī īsti neizprotu kādēļ vajag veidot vēl savu valodu, valodā. Manuprāt nav liela starpībā ko izprast - nedaudz PHP sintakses, vai Smarty sintaksi. Tas pats vien būs. Bet nu lai vai kā nedomāju, ka php freimwork'i ir kaut kas slikts - varbūt nevajag tik ļoti censties līdzināties ekvivalentiem uz citām valodām, taču visādi citādi tas ir ērtāk kā lietot pliku php.
  9. Man liekas, ka tagad gandrīz visiem ir piešķirti :) pirms dažām nedēļām visi spiegtu no prieka - tagad nevienam tā īsti tos ielūgumus nemaz nevajag :)
  10. rATRIJS

    addClass

    $("a#" + page).parent(".pnavigM").addClass("pnavigMactive");
  11. Nē - es to domāju tā kā biju uzrakstījis. Lietotājs hidden lauku vērtības var nomainīt ar JS palīdzību. Tas ko atgriež $(this).serialize() jau būs ar nepareizo news_id vērtību.
  12. Ja jau taisi pamācību pašam sākumam, tad vajag sākt ar to KĀ rakstīt kodu. Jāiepazīstina ir ar sintaksi kā tādu.
  13. Ja tā info un users relācija ir one-to-one, tad tiešām, ļoti iespējams, labāk ir glabāt visu vienā tabulā. Kādā ziņā tad būs nepārskatāms? Neviens tak pa tiešo MySQL tabulā tāpat neskatīsies. Lai nu kā tabulas var JOIN'ot (http://dev.mysql.com....0/en/join.html) Tavā gadījumā tas droši vien izskatītos kaut kā tā: SELECT users.id, info.* FROM users INNER JOIN info ON users.id = info.info_id WHERE users.nick = 'niks' LIMIT 1
  14. It kā jau nav liela vajadzība, bet var piesārņot DB ar bezjēdzīgiem datiem, kā arī taisīt pigorus pievienojot komentāru ar nākotnes news_id :) Fakts - viss kas nāk no formām nav uzticams :) un to hidden vērtību var nomainīt ar JS vai vienkārši kāds var POSTēt random lietas ar random datiem uz tavu skriptu kaut vai no savas lapas. Nop, drīzāk kāds var nospert session_id un uzdoties par kādu citu lietotāju :) Tādēļ vajadzētu session_id ģenerēt gana drošu ņemot vērā visādus parametrus.
  15. Priekš SQL kvērijiem tas ta būtu tas vienīgais/svarīgākais, bet ne kopumā. Vajag nodrošināties arī pret citām injekcijām, kaut vai XHR vai vienkārši HTML :) un atkarībā no tā kas tiek taisīt var klāt nākt vēl n lietas.
  16. Kavacky - pietiks ar clear: left
  17. It kā jau gana droši, bet nepārbauda vai ziņas kurām tiek pievienots komentārs eksistē. + current_user.id (lietotāja, kurš ir iežurnalējies) id var pieglabāt jau sesijā, lai nav jāsavāc no DB katru reizi exit() var likt arī pašās beigās, nevis pēc katra nosacījuma izpildes beigām. Un kādēļ tev tur vispār ir exit? Pareizi būtu pārmest lietotāju atpakaļ uz savu komentāru, bet nu ja te ir AJAX, tad OK.
  18. Uzgāju šādu jauku resursu, kur apskatīti 20 MySQL best-practices (kā būtu Latviski?) - Top 20+ MySQL Best Practices Iespējams kāds var padalīties ar līdzīgām saitēm :)
  19. Nu, nu, nu - pirms bļauj paskaties uz sevi :)
  20. rATRIJS

    SQL INSERT

    Ja tu pats vismaz kaut 5-10min būtu patērējis un pameklējis kaut vai šajā forumā, tad viss jau būtu, bet nē...tā vietā labāk ir stulbi prasīt pat nemeklējot.
  21. Nu jau, nu jau - ne jau ar php veido tikai "mazas personīgās mājaslapiņas". (nez kādēļ to vienmēr saka JAVA programmētāji) Freimworks paātrina izstrādes gaitu, konkrēti nosaka kur, kam ir jābūt, atvieglo programmētāju no daudz, viendabīgā, koda rakstīšanas. Par katra konkrētā freimwork'a izmantojamību jau ir cits stāsts. Domāju, ka daudzi freimwork'i ir iespaidojušies no citu valodu analogiem (Django, Rails) un mēģina attēlot to darbību. Ne vienmēr tas ir viegli izdarāms, vai vispār iespējams, bet kādēļ necensties.
  22. php atgriež OK? Kādēļ tu session_id() glabā vēl kādā sesijas mainīgajā? session_id() pats par sevi satur sesijas id (kuru vajadzētu pašam uzģenerēt). Lai nu kā - ja php atgriež OK, tad lai sesija iedarbotos vajadzēs parlādēt lapu.
  23. Tu vispār kādreiz ņem vērā kaut kādus ieteikumus?
  24. Es varu vairākus piemērus iedot: http://www.google.com/search?rlz=1C1GGLS_enLV336LV336&sourceid=chrome&ie=UTF-8&q=php+mysql+tutorial
×
×
  • Create New...