Maris-S

Varbūt ieinteresēs šis: http://www.w3schools.com/css/css_pseudo_elements.asp http://www.w3schools.com/css/pr_pseudo_first-letter.asp

Mefisto, es vai nu kaut ko nepamanu, vai īsti neizprotu, kā Tu tieši domā, kāpēc šāda eventu pierakstīšana nav ieteicama?

Jā, lapa funkcionē arī ar atslēgtu js, vismaz dzēšana. Vienīgi tai lapai ir prasība, lai ir pārbaude ar javascriptu un ja es pielieku papildus apstiprinājuma lapu, sanāks ka to būs jāapstiprina divas reizes (ar js un pēc tam apstiprinājuma lapā), vai arī jātaisa tā, lai gadījumā ja ir ieslēgts js tad uzreiz redirektot uz to dzēšanas lapu, bet domāju ka problēma ar vidējo pogu paliks tik un tā. Var jau arī veikt pārbaudi vai ir ieslēgts klientam javascripts vai nav, bet sanāks putra, labāk mēģināt sataisīt pēc iespējas vienkāršāk, ja nesanāks izveidot js funkciju, kas nokontrolētu arī vidējo pogu, atstāšu tā pat kā vien ir tagad. Bez js tā lapa pa tiešo izdzēsīs to ko viņai vajag bez jebkāda apstiprinājuma. Vienkārši man sanāca strādāt ar citu cms sistēmu (vajadzēja mazliet saturu viņā palabot) un es tur netišām nospiedu uz dzēšanas linku ar vidējo podziņu, tur tai lapai bija kontroles spāņu vai vācu valodā, tāpēc ne to uzspiedu. Galu galā sanāca tā ka tam cms vispār nav apstiprinājuma (šķiet easy cms), bet nu pēc tā gadījuma nolēmu pārbaudīt kā tad īsti ir manējā ar to vidējo pogu, izrādījās ka šī pieeja pilnīgi neaizsargā pret vidējās pogas nospiešanu, kaut gan man liekās ka ar onclick eventu var apstrādāt arī vidējo un labo peles taustiņu, tāpēc liekās mazliet nesaprotami kāpēc confirms šajā gadījumā nenostrādā. Laikam jau saistīts ar to ka pārlūkam ir sava funkcija uz to pogu (atvērt jaunu tab).

Bieži sanāk, izmantojot onclick metodi, veidot apstiprinājuma paziņojumu pie dzēšanas operācijām. Kods parasti sekojošs: onclick="javascript: return confirm('Are you sure?');" Šī lieta parasti smuki strādā, bet ja viņu pieliek linkam un uz šī linka tiek uzspiesta vidējā poga, tad apstiprinājuma dialogs neparādās, lapa tiek atvērta jaunā tab un ieraksts vai fails protams tiek izdzēsts. Vai nevar kādā veidā likt šai funkcijai nostrādāt arī uz peles vidējo pogu?

Man šķiet ka strpos būtu smuki jāatrod simbolus. Parādi koda gabalu kā Tu mēģināji ar šo funkcju atrast pēdiņas, varbūt ka kļūda kau kur?

Papēti htmlspecialchars funkciju, domāju ka Tavā gadījumā līdzēs, izmanto viņu pie datu izvades, ievadot datubāzē atstāj parastu tekstu kāds viņš ir, neko nekodējot, izņemot eskeipošanu protams.

Patiešām nav saprotami kam tieši jābūt gala rezultātā. Pēc šīs koda daļas var redzēt to ka ne visi div tiek noslēgti, te gan iespējams viss varētu būt savādāk ja redz visu kodu. Par to borderi, ja Tu domā ka dažiem elementiem, kas izmanto klasi x nav vajadzīgs borderis un dažiem ir vajadzīgs (vismaz es tā šo padarīšanu sapratu), tad pie konkrēta div, kam nevajag borderi lieto papildus style="border: none".

Aa nu tādas lietas kā produktu nosaukumus vai arī viņu aprakstus pilnīgi noteikti jāliek datubāzē, tur jau jāveido cms atbilstoši prasībām. Neesmu rūpīgi izpētījis visus datubāzes risinājumus kādi šeit tika piedāvāti, bet es personīgi jebkuram saturam, kas atrodas datubāzēs un ko jāatspoguļo vairākās valodās, lieku klāt lang_id koloniņu, vai arī pašu valodas kodu (lv, en, ru, kas valodu tabulā ir kā primary key). Valodām atsevišķa tabula. Cms cenšos taisīt, lai ievadīšanai vai labošanai valodu lauciņi tiek ģenerēti atbilstoši šai valodu tabulai, tad viegli pievienot valodu, vienkārši ievietojot jaunu ierakstu valodu tabulā, bišku ir sarežģītāk nekā veidot, piemēram, trīs kolonas, katru savai valodai. Nolasīšana arī notiek ņemot vērā izvēlēto valodu. Laba lieta valodas koloniņām taisīt indeksus, pie lielām tabulām selectiem būtu ātrāk jāstrādā, jo pārbaude notiks arī pēc valodas (tas protams ja, piemēram, netiek ņemts konkrēts produkts pēc identifikatora, bet ja nolasa produktu sarakstu konkrētai valodai).

Jā, ja ir nepieciešamība pēc dinamiska satura, tad nederēs. Man personīgi pagaidām nav sanācis tā ka tabuliņu kolon, pogu un tml. nosaukumiem tas būtu pilnībā nepieciešams. Arī šīs tēmas autors līdzīgu variantu apskatīja, tāpēc secināju ka šī pieeja varētu daudz maz noderēt. Vēl jau variants veidot iespēju valodu failus labot no admin paneļa pa tiešo, te protams mainīgo un masīvu pieeja nederēs, jāveido failam kāda sava struktūra, bet vienalga tas nav labākais variants dinamiskajam saturam, jo viss būs vienā čupā. Protams jau var mēģināt kaut ko atdalīt vai sakārtot, te jau jāskatās kādas ir prasības konkrētam projektam.

Vienkāršām lapām es parasti neglabāju datubāzē dažādus tabuliņu kolonu nosaukumus un līdzīgas lietas. Izmantoju kaut ko līdzīgu kā hmnc norādīja pirmajā variantā, vienīgi es nelietoju to tādā stilā: title_lv, title_en, title_ru, tā vietā es zimantoju mainīgos (kaut gan parasti masīva elementus), ar vienādiem nosaukumiem katrai valodai (caption_count, caption_price, caption_color, button_ok, button_cancel). Katrai valodai ir atbilstošais fails, piemēram, language_lv.php, kur ir sadefinēti valodas masīva elementi un, kas tiek includots atbilstoši izvēlētai valodai. Ar šo pieeju nav nekādu problēmu pievienot jaunu valodu, jāiztulko tikai viens fails. Vēl vienai mājas lapai izmantoju xml, pēc pieredzes saku, labāk nevajag. Neesmu nopietni pētījis gettext paplašinājumu, bet liekās ka to arī var izmantot lokalizācijas jautājumu risināšanā. Pielabojiet ja kļūdos.

Paldies par palīdzību, izskatās ka var droši palikt pie šī nosaukumu varianta.

Gribēju uzprasīt vai ir droši formas elementiem piešķirt nosaukumus sekojošā veidā: <input type="text" name="names[]"> <select name="choses[]">...</select> ... Situācija ir tāda, kad ar javascript var pievienot klāt neierobežotu skaitu šo elementu kopu, tādu kā jaunu ierakstu veidot. Rodas nedroša sajūta, vai nevarētu sanākt pie kādiem specifiskiem nosacījumiem, ka sūtot visus šos ierakstus php pusē masīviem sajauksies indeksi un atbilstoši pēc piemēra vienam konkrētajam names[] elementam būs atbilstoši nepareizais choses[] elements?

Nu tas ka par cenu autors grib runāt privāti nav jau nekas traks, bet nu vajadzētu tā kā bišku konkrētāk aprakstīt kādus uzdevumus tieši būs jāveic ar to javascript, jo neviens jau nevar uzminēt kas autora skatījumoā ir javascript speciālists. Domāju ka to būtu vieglāk pierakstīt kopējā topikā, nekā katram skaidrot privāti, jo katrs patstāvīgi varēs izanalizēt vai ir spējīgs konkrēto uzdevumu izpildīt un vai ir vērts pieteikties.

Diemžēl ar innerHTML arī nesanāk, nācās tomēr manuāli piešķirt selectam aktīvo opciju kā rādīja Indoom. Problēmu sarežģīja tas, ka klonējās tabulas rinda kurā ir vairāki selecti un vairāki input lauki (input jāpeliek tukšiem). Galā sanāca mazliet garāks js nekā gribējās: function cancelEvents(e) { if (!e) e = window.event; e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); } function clone(element, e) { var dub = element.cloneNode(true); if (!e) var e = window.event; element['on'+e.type]=null; element.parentNode.appendChild(dub); cancelEvents(e); return dub; } function cloneRow(element, e) { newRow=clone(element, e); var previousSelects=element.getElementsByTagName('select'); var newSelects=newRow.getElementsByTagName('select'); for (var i=0; i<previousSelects.length; i++) if (previousSelects[i].name==newSelects[i].name) newSelects[i].options[previousSelects[i].selectedIndex].selected=true; var newInputs=newRow.getElementsByTagName('input'); for (var i=0; i<newInputs.length; i++) newInputs[i].value=''; cancelEvents(e); }

Mēģinu klonēt objektus ar cloneNode funkcijas palīdzību. Nostrādā viss kā arī vajadzētu, bet objektam select netiek saglabāta aktīvā vērtība, input (text) laukiem value vērtība saglabājās. Vai var panākt, vai arī varbūt ir kāda analoga funkcija, kas saglabātu arī select aktīvo vērtību pēc klonēšanas?

Būs jāpapēta vai var uz parastā xp uzlikt to iis, ja būs win Server OS jāliek, tad gan pa lēto nesanāks izkļūt cauri. Tā ir ka sākotnēji neizvēlās strādāt ar bezmaksas open source programmatūru.

Kas būtu nepieciešams, lai varētu darbināt asp lapas? Lieta tāda ka vienai lapai jātaisa kopija citā valodā, pārsvarā viss ir html, ar to nav problēmu, bet ir viena sadaļa, kas ir asp, to nevajag ne tulkot, ne arī labot, vienkārši jāpārkopē, bet ko vispār ir jāinstalē, lai strādā asp? Varbūt kādam ir pieredze ar viņu?

Piedošanu! Šo tēmu var neturpināt, IE6 tomēr arī strādā.

Radās situācija, kad vajag no failu saglabāšanas dialoga lodziņa jānoņem iespēja open, jāpaliek tikai save un cancel. To vajag tikai IE, Mozillās nav nepieciešams. Atradu sekojošu risinājumu: <meta name="DownloadOptions" content="noopen"> IE7 strādā, bet kā varētu to pašu panākt IE6?

A kāpēc būtu jāatsakās no garumzīmēm linkā?

Savā laikā es arī sastapos ar šo problēmu, mēģināju ar ajax selecta optionus mainīt. Tas ir kaut kāds kārtējais IE bugs, vai varbūt viņi speciāli neļauj to darīt. Es problēmu atrisināju samērā vienkārši, lai netērētu daudz laika risināšanai, paņēmu visu selectu ieliku divā un mainīju innerHTML divam, protams mainot innerHTML šajā gadījumā ir jāraksta ar visu <select>. Šī pieeja strādā, bet ne visai ērti ir.

Man jau šķiet ka jāglabā tā kā ir ērtāk konkrētajā situācijā. Es pats personīgi parasti glabāju datuma/laika vienības kā vienu no pieejamiem mysql datu tipiem (atkarīgs no situācijas). Timestampu pa tiešo parasti nesaglabāju, konvertēju to uz unix timestampu selektā, protams ja tas ir nepieciešams, ar mysql funkciju UNIX_TIMESTAMP, vēlāk jau kā vajag var saformatēt ar php funkciju date. Unix timestampu pa tiešo glabāt man ne visai patīk, tad nevar redzēt saprotamu datumu, ja jāskatās datubāzē pa tiešo. Tomēr kā jau teicu jālieto to, kas ir piemērotāks atbilstošai situācijai.

Apache configā neko neesmu licis saistībā ar apc, php.ini sekojošs: [APC] apc.rfc1867 = On apc.max_file_size = 500M apc.include_once_override = On apc.cache_by_default = Off apc.rfc1867_freq = 1k extension=php_apc.dll Šajā gadījumā ir apc.cache_by_default = Off, sākumā protams nebij šīs rindiņas. Iespējams ka gļukojas lapa kā tāda. Tur ir diezgan daudz includes un arī zend frameworkā taisītie kontrolieri samērā palieli. Vispār tā lapa ir pasmaga, man uzreiz likās ka labāk ar zendu viņu neprogramēt, arī te forumos izteicās ka veiktspējas ziņā zend frameworks lielākām lapām nevisai spīdošs. Tagad ir tā, ka manā lokālajā kompī ātri refrešojot lapu var nobrucināt apache (pieaug apache procesam izmantotā operatīvā atmiņa un pārstartē servisu), pēc sistēmas pārinstalēšanas arī tas pats. Nu vismaz serverus, kur šī lapa stāv, nevar uzkarināt. Uz serveriem apc nemēģināju likt, negribās eksperimentēt uz strādājošas sistēmas. Webs darbojās uz os windows.

Tur jau tā lieta ka nav tāda konkrēta koda gabala, kā jau teicu, sākumā, kamēr nenomainīju failiem modificēšanas datumu, vajadzēja vienkārši ielikt kaut kādu izmaiņu, kaut vai tukšu rindiņu, vienalga ko, lai būtu izmaiņa, vēlāk noņemot viņu arī turpināja strādāt (gala rezultātā kods bez izmaiņām), vēl pamanīju, ka funkcija apc_cache_info() atgriež problemātiskos failus deleted_list masīvā, ko viņš nozīmē es nezinu, dokumentācijā neatradu, pēc loģikas spriežot vajadzētu tā kā būt failam, kurus viņš negrib sakešot vai kaut kā tam līdzīgi. Pie tam kā deleted viņi parādījās tikai tad, kad tā lapa daudz maz aizgāja, jo pirms tam (arī tagad pēc failu modifikācijas datuma nomaiņas) vienkārši nobrūk apache logos ierakstot kļūdu par kādas klases pārdefinēšanu: [Tue Jun 09 16:58:27 2009] [apc-error] Cannot redeclare class zend_registry in D:\web\agora\Zend\Loader.php on line 178. [Tue Jun 09 16:58:32 2009] [crit] Parent: child process exited with status 2 -- Aborting. Pirms es nomainīju failu modificēšanas datumus vismaz sanāca panākt, ka apache nenobrūk, vienīgi faili, kas izraisīja problēmas, vienkārši nenolasījās, tā koda daļa vienkārši nebija (dažiem failiem man ir vienkārši includoti valodu mainīgi, tāpēc sapratu ka koda daļa iztrūkst), apache error logos sekojošs paziņojums: [Tue Jun 09 13:09:05 2009] [notice] Apache/2.2.11 (Win32) PHP/5.2.9-2 configured -- resuming normal operations [Tue Jun 09 13:09:05 2009] [notice] Server built: Dec 10 2008 00:10:06 [Tue Jun 09 13:09:05 2009] [notice] Parent: Created child process 640 [Tue Jun 09 13:09:05 2009] [notice] Child 640: Child process is running [Tue Jun 09 13:09:05 2009] [notice] Child 640: Acquired the start mutex. [Tue Jun 09 13:09:05 2009] [notice] Child 640: Starting 64 worker threads. [Tue Jun 09 13:09:05 2009] [notice] Child 640: Starting thread to listen on port 80. Iespējams ka modulim nav ne vainas, vienīgi nezinu kāpēc viņš negrib strādāt, iespējams, ka viņš tā uzvedās pie konkrētiem nosacījumiem, jo uz maza atsevišķa koda man nesanāca atkārtot problēmu. Ja kļūdu paziņojumā ieraksta ka tiek pārdefinēta klase, iespējams ka sakešotu kodu kāda iemesla pēc izpilda divas reizes, kaut gan diezvai. Vēl ko pamanīju, ir tā ka problemātiskie failiem (pārsvarā, ne visiem) modificēšanas datums bija janvārī, tātad pus gadu neaiztikti, diezvai tas kaut ko ietekmē, visdrīzāk sakritība.

Visumā sapratu ka kešošanai šis modulis galīgi neder. Nomainīju visiem failiem date modified un vispār pārstāja strādāt. Tomēr, galvenais mērķis man ir iegūt failu augšupielādes progresa rādītāju, tāpēc koncentrējos uz šo padarīšanu. Varbūt ja kādam interesē risinājums, tad php.ini failā jāatslēdz apc.cache_by_default: apc.cache_by_default = Off Noklusēti ir ieslēgta, ja viņu atslēdz, tad kešošana notiek pēc filtriem (nav ne jausmas kas viņi ir), bet visumā sanāk ka viņš neko vairs nekešo kamēr to filtru nav un augšupielādes progresa rādīšanai tā pietiek.