Jump to content

Мнфсруыдфм

Newbie
  • Posts

    22
  • Joined

  • Last visited

Everything posted by Мнфсруыдфм

  1. что-бы понять что написать на PHP драйвер видеокарты нереально, для этого много времени не нужно Мы просто не договорились что считать изученным ЯП Если считать что ЯП изучен только когда помнишь все его операторы (это в общем-то реально, у большинства нормальных ЯП их немного) и все библиотечные функции (это уже намного сложнее), тогда получится что большинство программистов-практиков не знают ни одного ЯП Плюс я же специально добавил - "если знаешь С", то за несколько дней реально выучить. PHP и С близкие родственники, разобраться в чем они отличаются можно довольно быстро, PHP взял из С намного больше чем "1,5 оператора" . А если вообще нет за душой ни одного выученного ЯП то тут действительно и месяца может не хватить.
  2. А вы что, знаете хоть один ЯП полностью? И зачем читать список всех функций, какой в этом смысл? Я даже и не пытался запомнить все функции, зачем, хелп всегда под рукой, то что часто использую помню, что не помню всегда можно отыскать в справке. А на то что-бы бегло просмотреть функции, что бы просто узнать что можно сделать с их помощью, что бы не изобретать велосипед самому, на это и одного дня хватит. ИМХО достаточно схватить основную идею, а зубрить все подряд никчему, без практики все равно это все выветрится очень быстро
  3. Не соглашусь. Ведь человек еще не знает возможностей php. Для выбора инструмента решения задачи надо знать на что этот инструмент (в нашем случае php) способен. А я соглашусь, можно ведь и учебную задачку для себя поставить По вопросу, все зависит, как мне кажется, от имеющегося опыта, если человек знает достаточно твердо С, то изучить PHP очень легко, у меня это дело заняло несколько дней, если нет тогда.. Я сначала скачал денвер, потом PHP Expert Editor (редактор для PHP) и хелп PHP на русском.. посидел, почитал и на следущий день уже у меня работал очень убогий и глючный форум на PHP дальше дорабатывал все напильником Думаю учить любой ЯП лучше на какой-то реальной задаче, так проще и интерестнее, постепенно усложняешь задачу и становятся более понятными многие вещи на которые при простом чтении хелпов не обращаешь внимания
  4. </code></div>', $text);$qcount = substr_count($text, "|quote|"); $ccount = substr_count($text, "|code|"); for ($i=0; $i<$qcount; $i++) $text = preg_replace('#[quote](.*?)[/quote]#si', '<div class='quote'>1</div>', $text); for ($i=0; $i<$ccount; $i++) $text = preg_replace('#[code](.*?)#si', '<div class='quote' style='width:400px;white-space:nowrap;overflow:auto'><code style='white-space:nowrap'>1 что-то не пойму, а какой смысл прогонять замену по количеству тегов в строке, ведь preg_replace заменяет сразу все вхождения шаблона, получиться что отработает только первая замена, а остальные будут вызываться вхолостую
  5. спасибо за пример, поначалу думал так и сделать, только регулярные выражения хранить в базе (а не внутри кода), что-бы без правки кода можно было добавить или убрать теги. Но захотелось еще сделать разбор, с выводом ошибок (закрытые, незакрытые теги и т.п.) только уже сейчас сообразил что можно было после прогона регулярными выражениями поискать оставшиеся теги и их уже проанализировать, правда у моего варианта есть и преимущества - админ форума может добавлять теги вообще ничего не понимая в регулярных выражениях, достаточно знать немного HTML
  6. Хорошая идея! У меня еще другая появилась (чем и хороши форумы - сформулировал вопрос, уже на 90% нашел решение ) Надо просто использовать две функции преобразования BBCode (ну, или одну, работающую в двух режимах, это не важно) Первая функция "продвинутая и интеллектуальная", она контролирует правильность кода, соответствие закрытых и открытых тегов, вложенность тегов и т.п. Если что-то не так то скрипт не сохраняет сообщение в базе, если все ОК то сообщение записывается в базу как есть, т.е. в BBCode. Вторая функция "тупая", но быстрая, она просто загружает из базы таблицу соответствий BBCoda и html, запихивает их в массивы $search и $replace и дальше $s=str_replace ($search, $replace, $s); Код там уже проверенный заморачиваться проверками не надо, зато замена будет производиться с максимальной скоростью.
  7. да я уже так и сделал, просто размышляю теперь
  8. вот еще придумал.. А что если сохранять сообщение в отдельной табличке. Т.е. при получении постинга парсим BBCode и записываем его вместе с текстом и HTML в такую таблицу: IDпоста | Текст ——————————————- ID0 | ... собственно текст ID1 | [BBTag]<HTMLTag> теги ID0 | ... собственно текст ID0 | ... собственно текст ID0 | ... собственно текст ID1 | [BBTag]<HTMLTag> теги тогда получится что и избыточного хранения информации нет и любой код можно налету формировать, достаточно выбросить из строки ненужные теги и склеить строки таблицы в одну
  9. получается можно обрабатывать BBCod на входе, и сохранять его в базе в виде "...[Название_BB_тега] > а потом, при выводе менять эти неправильные теги, просто удаляя все что в квадратных скобках с самими скобками, это делаться будет быстро, и перед редактированием получить из такого "полуBBCode" реальный код будет довольно легко. Как говорят в американских фильмах, это должно сработать
  10. другое дело что можно на лету удалять эти неправильные добавки, это будет быстрее чем полный разбор.. это мысль, надо ее подумать
  11. мысль хорошая, но я тоже думаю что противоречит (может и ошибаюсь, я в этом деле еще чайник ). Дело в том что это дипломная работа (но форум будет реально использоваться, пишу не "для полки", его планируют разместить на новом сайте университета), поэтому правильность кода довольна важна, проще вообще отказаться от BBCoda . Вообще, надеюсь, что странички будут валидными, когда подработаю напильником
  12. Попробовал оба варианта, пока что на тестовом форуме (около 200 кБ текста) вроде не тупит, наверное сделаю так, пока пусть все хранится в BBCode, если жизнь покажет что будут тормоза перегнать его в HTML это как два байта переслать, дело максимум на полчас неспешной работы.
  13. да, функция довольно нехилая получилась $this->patTag="~([[^[]*])~"; $this->patOpenTag="~[s*([^/][^s]*?)s*(?:="?(.+?)"?)?s*]~"; $this->patCloseTag="~[s*/s*([^s]+)s*]~"; function GetHTTPFromBB($N,$i,$j){ $ot=$this->HTMLtag; $ot=str_replace('$N',$N,$ot); $this->tegArr[$i]=$ot; $this->tegArr[$j]=$this->HTMLTagClose; } function IsOpenTag($s,&$T,&$N){ $r= preg_match($this->patOpenTag,$s,$g); if (count($g)>1){ $T=$g[1]; $N=""; if (count($g)==3) $N=$g[2]; } return $r; } function IsCloseTag($s,&$T){ $r= preg_match($this->patCloseTag,$s,$g); if (count($g)==2){ $T=$g[1]; } return $r; } function CheckHierarchy(){ $stack[0]=Array(0,"",""); $this->errors=""; for ($i=0; $i<count($this->tegArr); $i++) { if($this->IsOpenTag($this->tegArr[$i],$T,$N)){ //Если тег $stack[count($stack)]=Array($i,$T,$N); } elseif($this->IsCloseTag($this->tegArr[$i],$T)){ if (count($stack)==1){ $this->errors.= "Закрывающему тегу [/$T] не найден соответствующий открывающий "; continue; } if ($stack[count($stack)-1][1]==$T){ $N=$stack[count($stack)-1][2]; if (!$this->FindTag($T,$N)||(!$this->Enabled)){ //такого тега нет! $this->errors.= "Тег <strong>[$T]</strong> не поддерживается". " форумом или отключен администрацией "; unset($stack[count($stack)-1]); continue; } //все ОК $this->GetHTTPFromBB($N, $stack[count($stack)-1][0], $i); unset($stack[count($stack)-1]); } else{ $this->errors.="Неправильная последовательность тегов! "; $this->errors.="([".$stack[count($stack)-1][1]."]—>[/$T]) "; return false; } } } if (count($stack)==1) return true; $this->errors.="Незакрытые теги: "; foreach($stack as $key=>$value) if($key) $this->errors=$this->errors."[".$value[1]."] "; $this->errors=$this->errors." "; return false; } //анализирует теги и формируюе выходную строку //в случае нормального завершения выдает отформатированный текст function GetString(){ $Count=count($this->tegArr); if (!$Count) return ""; $this->errors=""; $this->valid=$this->CheckHierarchy(); //сформируем результат $s=""; foreach($this->tegArr as $value)$s.=$value; return $s; }
  14. Мммда, в принципе логично.. Меня то как раз вопрос производительности больше всего и беспокоил, понятно что сейчас все летает - форум пустой, но если действительно не стоит этим грузиться то сделаю все-же хранение в коде и правку налету.
  15. ну, например: |u|бла-бла|/u| преобразуется в бла-бла и если перегонять этот код html назад в BBCode, то нужно как-то определить что принадлежить иенно тегу |u| а не |s| например. Конечно ничего невозможного в этом нет, но все-же довольно заморочное дело как мне кажется. Проще все-же хранить в двух видах.
  16. Это нормально/гламурно. Риальные пацаны так и поступают. Сами храним 2 формата (wiki/xhtml). в общем, как я понял, пацаны если что поймут :) значит буду так и делать, вариант с преобразованием html в BBCode мне что-то сильно не нравиться, да и перекодировка на лету тоже, надеюсь что форум будет сильно посещаемым, некчему лишняя нагрузка, да и место на винте теперь не такое дорогое как раньше. спасибо за уничтожение моих колебаний, а то я уже заколебался сам и заколебал окружающих своим мрачным видом
  17. В общем, можно вопрос сформулировать и так.. если все обычно хранят сообщения не преобразованные в html, в BBCode а преобразовывают их на лету при формировании страницы, насколько это сильно тормозит сервер? А то может быть я застрял на ерунде и крохоборствую тут вместо того что-бы делом заняться
  18. пишу форум и возникла тут такая альтернатива: хочу ввести в форуме поддержку BBCode т.е. пользователь сможет используя теги вроде |quote||/quote| |code| |/code| |img| |img| (скобки квадратные, заменил тут на прямые что-бы этот форум их не преобразовал в теги) форматировать сообщения. Собственно саму функцию уже реализовал. В базе храниться таблица с кодами в виде {quote=; <span class="quote">$N</span><blockquote class="quote">; </blockquote>} по этим записям функция меняет теги в BBCode на теги HTML все нормально работает, но вот не пойму как сделать редактирование уже введенных сообщений. Пользователю то надо подсовывать текст не с тегами HTML а с тегами BBCode. Если хранить сообщения преобразованные в HTML, то обратное преобразование в BBCode это довольно заморочное дело (надо учесть то что закрывающие теги, например могут принадлежать разным тегам BBCode и т.д. в общем кусок работы. Если же хранить сообщения в базе не преобразованные а преобразовывать их непосредственно перед выводом, то повысится нагрузка на сервер - в принципе функция шустрая, но при большом количестве пользователей не знаю как себя поведет, могут появиться тормоза. Можно, конечно еще хранить два вида сообщений, в html и в BBCode, но как-то это негламурненько Может быть я изобретаю велосипед и есть какой-то другой способ?
  19. Для этого придется у меньшего текста как то увеличивать расстояние между буквами, чтобы компенсировали разницу в размерах. Ну да, стили вроде бы это позволяют сделать (letter-spacing). В общем, надо пробовать. попытался изобрАзить <html> <head> <style type="text/css"> H1 { color:rgb(0,255,153); margin: 0px; /* Убираем отступы вокруг заголовка */ } DIV.shadow H1 { position: relative; /* Относительное позиционирование */ font-size: 217%; left: -1px; /* Сдвиг тени вправо */ top: -1.08em; /* Сдвиг тени вверх от исходного положения */ color: red; /* Цвет тени */ z-index: -1 /* Порядок слоя */ } </style> </head> <body> <h1>Ч</h1> <div class=shadow><h1>Ч</h1></div> <h1>е</h1> <div class=shadow><h1>е</h1></div> </body> </html> вообще-то, конечно перректально это.. проще наверное картинку приделать, либо закинуть 32 картинки и в нужных местах вместо букв вставлять
  20. наверное можно наложить друг на друга два дива, с одинаковым текстом, тот текст что снизу будет на размер больше и с цветом окантовки.. но это пробовать надо.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy