Comments 72
кофе — он:) Но погубит — точно!
с недавних пор — и оно тоже
UFO just landed and posted this here
Поищите, пожалуйста, за меня: сравнительно недавно в министерствах решили, что оба варианта употребления (и мужской, и средний род) являются правильными — для «осовременнивания» правил русского языка.
Я сам очень удивился, но у меня теща учительница — подтвердила, «черное» кофе больше ошибкой не является.
Я сам очень удивился, но у меня теща учительница — подтвердила, «черное» кофе больше ошибкой не является.
function H(){
}
что вы этим хотели сказать? ;)
function t($text,$html=false){
$text = str_replace ("'","\'",$text);
$text = str_replace ("\\\'","\'",$text);
$text = str_replace ('\\\\','',$text);
$text = str_replace ('<||>','<||>',$text);
$text = rT($text);
return $text;
}
оригинальный у вас способ защиты от sql иньекций
Да! – 5 раз я удалял с винта тонны кода, но через несколько месяцев теста новой системы — мне пришлось удалить ее и в 6-й раз.
узнав о всех радостях php5 код будет удален еще примерно раз ндцать %)
удачи в нелегком деле повышения собственного опыта
Вся проблема в платформе. PHP — это Personal Home Page. Убогость платформы (которой нет) заставляет пользователей извращаться.
Кстати, у меня есть система работы с классами и пакетами на PHP.
Например, можно импортировать классы командой import(«ru.mycompany.projectname.packagename.classname») на манер Жавы.
Надо?
Например, чтобы использовать твою CMS в своем проекте, достаточно было бы написать import(«ru.mrhard.cms.*»), и дальше кодить с чистой душой.
Это позволяет прозрачно переиспользовать код.
В течение следующих двух недель сделаю свой сайт, и отдельно — сайт проекта.
Мы можем всегда выкладывать исходники в таком формате, чтоб
ы они могли цепляться пакетной системой, и в результате получить OpenSource проект с неибическим рейтингом и возможностями.
Если интересно — добавляй во френды, буду держать в курсе.
Кстати, у меня есть система работы с классами и пакетами на PHP.
Например, можно импортировать классы командой import(«ru.mycompany.projectname.packagename.classname») на манер Жавы.
Надо?
Например, чтобы использовать твою CMS в своем проекте, достаточно было бы написать import(«ru.mrhard.cms.*»), и дальше кодить с чистой душой.
Это позволяет прозрачно переиспользовать код.
В течение следующих двух недель сделаю свой сайт, и отдельно — сайт проекта.
Мы можем всегда выкладывать исходники в таком формате, чтоб
ы они могли цепляться пакетной системой, и в результате получить OpenSource проект с неибическим рейтингом и возможностями.
Если интересно — добавляй во френды, буду держать в курсе.
иногда необходимо «разжевывать» код прямо в коде, чтобы те кто продолжит его и правда разбирался в нем)
Ты имеешь в виду, что импорты уменьшают читабельность кода, потому что не видно что именно подключается?
Ну, я так понял. Если понял неправильно, переправь :)
1. Подключаемые классы и пакеты должны быть документированы. Информацию о том как документировать — можно найти где угодно.
В качестве хорошего примера — гид по стилю для Питона: «www.python.org/dev/peps/pep-0257/».
Но ведь в PHP этот их PHPDocumentor уже достаточно хорошо работает?
2. Когда страничка использует один-два класса и пару десятков строк кода — то всё пучком. А если нужно подключить пару десятков, или упаси бог сотен классов?
Ну и по организации:
3. Совсем недокументированные проекты к участию не допускать.
Ввести систему рейтингов, и соответственно лучше документированные проекты получат гораздо больший ретинг.
4. Самый большой рейтинг давать программам, документрированным с помощью тестов. Хороший пример — js-фрэймворк Dojo.
5. Причем проектам, разработанным с помощью настоящего TDD выдавать самый-самый-самый большой рейтинг.
В общем, сложность не написать скрипт импортирования, а удержать правильное сообщество. Ну и распиарить. Сейчас над этим активно думаю.
Ну, я так понял. Если понял неправильно, переправь :)
1. Подключаемые классы и пакеты должны быть документированы. Информацию о том как документировать — можно найти где угодно.
В качестве хорошего примера — гид по стилю для Питона: «www.python.org/dev/peps/pep-0257/».
Но ведь в PHP этот их PHPDocumentor уже достаточно хорошо работает?
2. Когда страничка использует один-два класса и пару десятков строк кода — то всё пучком. А если нужно подключить пару десятков, или упаси бог сотен классов?
Ну и по организации:
3. Совсем недокументированные проекты к участию не допускать.
Ввести систему рейтингов, и соответственно лучше документированные проекты получат гораздо больший ретинг.
4. Самый большой рейтинг давать программам, документрированным с помощью тестов. Хороший пример — js-фрэймворк Dojo.
5. Причем проектам, разработанным с помощью настоящего TDD выдавать самый-самый-самый большой рейтинг.
В общем, сложность не написать скрипт импортирования, а удержать правильное сообщество. Ну и распиарить. Сейчас над этим активно думаю.
сори, я тебя не так понял, на счет библиотек, классов и т.д. у меня реализовано примерно так как ты сказал, а насчет распиарить — неужели ты думаешь я из корыстных целей тут?
Сообщество должно быть пропеарено. И бесплатное сообщество тоже должно быть пропеарено. Иначе оно заглохнет не начавшись.
Ха, с таким подходом распиарить не получится вообще. Более 9000 хороших разработчиков вообще не документируют свой код, просто потому, что у них есть более важные задачи — и это вполне нормально, я считаю.
Хороших разработчиков чего?
Хорошие разработчики библиотек для переиспользования — всегда документируют свой код.
Некоторые хорошие разработчики имеют в команде специальных людей для документирования и тестов.
Проекты, разработанные на основе TDD в документации почти не нуждаются (только описания смысла тестов). Правда очень мало гигантов, которые справляются с этим.
Хорошие разработчики библиотек для переиспользования — всегда документируют свой код.
Некоторые хорошие разработчики имеют в команде специальных людей для документирования и тестов.
Проекты, разработанные на основе TDD в документации почти не нуждаются (только описания смысла тестов). Правда очень мало гигантов, которые справляются с этим.
В PHP не создают, как правило, специальные библиотеки для переиспользования с хорошей документацией. Исключения — Zend Framework и другие — прекрасно существуют и без Вас, и привлечь их (на первом этапе) вряд ли удасться. А обычные девелоперы не всегда команду-то имеют, не то что документацию своих проектов. Тот же demirGo.CMS, о котором идет речь и который Вы (в первом коментарии) предлагали импортировать в другие проекты одной строкой — много там документации? (Правда, я не считаю, что этот проект созрел для документирования)
Наверняка там ни документации, ни автотестов :)
Мало ли что «не принято». Хорошие идеи — все равно пробьются вперед.
То что в среде PHP-программистов не создают специальные библиотеки — как думаете, почему?
Мне кажется, это потому что бОльшая часть PHP-программеров — это веб-дизайнеры, научившиеся вписывать между строками HTMLя тексты скрипта на PHP. Поэтому сайт им представляется в виде веб-страничек, нафаршированных скриптами. Что уж тут говорить о библиотеках, в таком майндсете они просто не существуют.
То что сейчас на рынке есть только Зенд (потому что он бох) и Симфония (потому что автор жжот), значит только то, что рынок свободен! Это можно замечательно использовать!
Мало ли что «не принято». Хорошие идеи — все равно пробьются вперед.
То что в среде PHP-программистов не создают специальные библиотеки — как думаете, почему?
Мне кажется, это потому что бОльшая часть PHP-программеров — это веб-дизайнеры, научившиеся вписывать между строками HTMLя тексты скрипта на PHP. Поэтому сайт им представляется в виде веб-страничек, нафаршированных скриптами. Что уж тут говорить о библиотеках, в таком майндсете они просто не существуют.
То что сейчас на рынке есть только Зенд (потому что он бох) и Симфония (потому что автор жжот), значит только то, что рынок свободен! Это можно замечательно использовать!
Зенд — бох?! Я вас умоляю.
На самом деле, я насчет документирования не закончил — вот вы говорите, что у гигантов есть специальные команды, занимающиеся документацией — мне кажется, сама структура сообщества должна быть разделена на две части — программистов и писателей документации. И рейтинг не должен никак зависить от документированности, потому что наверняка в таком случае хорошо документированные, но слабые проекты будут постоянно превосходить сильные проекты по рейтингу. Надо организовать сообщество так, чтобы разработчики находили людей, которые будут писать документацию им (правда, и насчет мотивации этого я еще не придумал)
На самом деле, я насчет документирования не закончил — вот вы говорите, что у гигантов есть специальные команды, занимающиеся документацией — мне кажется, сама структура сообщества должна быть разделена на две части — программистов и писателей документации. И рейтинг не должен никак зависить от документированности, потому что наверняка в таком случае хорошо документированные, но слабые проекты будут постоянно превосходить сильные проекты по рейтингу. Надо организовать сообщество так, чтобы разработчики находили людей, которые будут писать документацию им (правда, и насчет мотивации этого я еще не придумал)
О, ну, хм.
Хорошее предложение.
Но я еще подкину возражений, чтобы поддержать конструктивный диалог :)
Каким фигом документаторы будут документировать, если программисты сами этим не занимаются?
То есть допустим, вот я член команды документаторов. Я открываю исходник программы и вижу метод:
public static fooBarBazSupermethod(Object[] source; Object destination);
а в реализации метода написан какой-то алгоритм, в котором очень много вызовов других методов, объектов, проверок на константы со страшными названиями, и так далее.
Что такой метод делает — ну нифига ведь непонятно.
Можно, конечно, позвонить или написать на почту программисту, и попросить объяснить, чо это такое.
Но если метод не задокументирован, есть вероятность что даже его создатель в точности не помнит что он делает, как и почему. Особенно если с момента написания прошло полгода.
Если даже создатель не понимает что там творится — как с этим может справиться «левый» человек?
Имхо, сразу после написания и тестирования на работоспособность, нужно сразу написать нечто вроде:
/**
Склеивание и шифрация массива объектов.
Алгоритм базируется на сжатии хаффманом, и шифровании по ключу, который захардкоден в текст класса.
Object[] source — входной набор объектов. Внимание: будут использованы не сами объекты, а их клоны!
Object destination — выходной объект совместимого формата (статья 345 документации), рапознавание рефлекшеном. Если destination == null, то создается новый объект типа BarBazStore.
public static fooBarBazSupermethod(Object[] source; Object destination) {
// Этап первый: клонирование объектов
…
// Этап второй: подготовка к сжатию
…
…
}
Вот так уже гораздо лучше.
Хорошее предложение.
Но я еще подкину возражений, чтобы поддержать конструктивный диалог :)
Каким фигом документаторы будут документировать, если программисты сами этим не занимаются?
То есть допустим, вот я член команды документаторов. Я открываю исходник программы и вижу метод:
public static fooBarBazSupermethod(Object[] source; Object destination);
а в реализации метода написан какой-то алгоритм, в котором очень много вызовов других методов, объектов, проверок на константы со страшными названиями, и так далее.
Что такой метод делает — ну нифига ведь непонятно.
Можно, конечно, позвонить или написать на почту программисту, и попросить объяснить, чо это такое.
Но если метод не задокументирован, есть вероятность что даже его создатель в точности не помнит что он делает, как и почему. Особенно если с момента написания прошло полгода.
Если даже создатель не понимает что там творится — как с этим может справиться «левый» человек?
Имхо, сразу после написания и тестирования на работоспособность, нужно сразу написать нечто вроде:
/**
Склеивание и шифрация массива объектов.
Алгоритм базируется на сжатии хаффманом, и шифровании по ключу, который захардкоден в текст класса.
Object[] source — входной набор объектов. Внимание: будут использованы не сами объекты, а их клоны!
Object destination — выходной объект совместимого формата (статья 345 документации), рапознавание рефлекшеном. Если destination == null, то создается новый объект типа BarBazStore.
public static fooBarBazSupermethod(Object[] source; Object destination) {
// Этап первый: клонирование объектов
…
// Этап второй: подготовка к сжатию
…
…
}
Вот так уже гораздо лучше.
Увы, так получается делать только в идеале.
К примеру, я сейчас разрабатываю как раз библиотеку/фреймворк. Сложность кода уже — пипец, а в ближайшие месяцы все станет сложнее в несколько раз. На написание документации, хотя бы в виде комментариев, уйдет еще несколько месяцев — и только если я переборю свою лень.
А документировать в процессе я просто не могу — я говорю, код очень complicated, соответственно реализация каждой новинки занимает не несколько минут, а несколько часов и дней, во время которых я просто не могу отрываться (отвлекаться) от программирования, чтобы не потерять мысли.
Решение может быть таким: после написания какого-то куска или всей библиотеки программист пишет краткий код, иллюстрирующий, как с библиотекой работать — т. н. «точку входа» для документаторов, глядя на которую и отправляясь от нее, они будут смотреть код и составлять описание.
К примеру, я сейчас разрабатываю как раз библиотеку/фреймворк. Сложность кода уже — пипец, а в ближайшие месяцы все станет сложнее в несколько раз. На написание документации, хотя бы в виде комментариев, уйдет еще несколько месяцев — и только если я переборю свою лень.
А документировать в процессе я просто не могу — я говорю, код очень complicated, соответственно реализация каждой новинки занимает не несколько минут, а несколько часов и дней, во время которых я просто не могу отрываться (отвлекаться) от программирования, чтобы не потерять мысли.
Решение может быть таким: после написания какого-то куска или всей библиотеки программист пишет краткий код, иллюстрирующий, как с библиотекой работать — т. н. «точку входа» для документаторов, глядя на которую и отправляясь от нее, они будут смотреть код и составлять описание.
А Зенд, кстати, идет своей дорогой, весьма отличной от пути C#/Java. Мне с ним точно не по пути, нафиг его привлекать =)
Этот проект не созрел для того чтобы его документировать — а смысл, если на протяжении нескольких недель я буду заниматься его переделкой по факту того о чем здесь писали, а когда все будет хорошо и багов будет исчерпывающее количество — тогда и будет идти документация готового релиза
на 'personal home page' написано столько крупных, успешных, а главное 'легких' проектов, что я бы не был столь категоричен.
пхп можно ругать или не ругать, но без него было бы тяжко:)
и тот факт, что это не, например, .net, имеет свои очевидные плюсы.
Да — больше времени на разработку, да — куча 'лишних' движений.
Результат — быстродействие.
Конечно говнокодеров учитывать не надо — для каждой платформы свои говнокодеры, так уж вышло, что в виду специфики языка пхп-говнокодеров очень много.
пхп можно ругать или не ругать, но без него было бы тяжко:)
и тот факт, что это не, например, .net, имеет свои очевидные плюсы.
Да — больше времени на разработку, да — куча 'лишних' движений.
Результат — быстродействие.
Конечно говнокодеров учитывать не надо — для каждой платформы свои говнокодеры, так уж вышло, что в виду специфики языка пхп-говнокодеров очень много.
OMG!
а зачем требование mbstring, ведь iconv входит в большинство стандартных поставок/конфигураций php и меньше загружает систему? лень?
Окей, поясняю минусующим: расширение mbstring включено далеко не на всех хостингах и не во всех дистрибутивах, это первая проблема.
Вторая проблема — использование автоматического перекодирования (mbstring_internal_encoding) вместо того, чтобы просто iconv'ом преобразовывать кодировку только там, где это действительно нужно — занимает лишнее процессорное время и память, пусть и по мизеру, но в сочетании с первым пунктом, смысл использования этого расширения в проектах, делаемых на публику (а автор вышел со своим проектом на публику) — совершенно неясен.
Разве автору самому нравится дополнительное системное требование, без которого можно обойтись, в принципе?
Просто это один из элементов подхода к разработке, пока он не поменяется, вы еще много раз будете переписывать все заново.
Вторая проблема — использование автоматического перекодирования (mbstring_internal_encoding) вместо того, чтобы просто iconv'ом преобразовывать кодировку только там, где это действительно нужно — занимает лишнее процессорное время и память, пусть и по мизеру, но в сочетании с первым пунктом, смысл использования этого расширения в проектах, делаемых на публику (а автор вышел со своим проектом на публику) — совершенно неясен.
Разве автору самому нравится дополнительное системное требование, без которого можно обойтись, в принципе?
Просто это один из элементов подхода к разработке, пока он не поменяется, вы еще много раз будете переписывать все заново.
Так ведь можно и на ассемблере везде писать, а то мало ли =)
Ориентироваться на хостинги где даже mbstring нету — надо ли? Чего хорошего-то в таком хостинге? Хотите посоветую достаточно дешевый хостинг где и это, и еще множество расширений есть? )))) (хотя можно просто погуглить секунд 10).
Скоро ль там шестой пых…
Ориентироваться на хостинги где даже mbstring нету — надо ли? Чего хорошего-то в таком хостинге? Хотите посоветую достаточно дешевый хостинг где и это, и еще множество расширений есть? )))) (хотя можно просто погуглить секунд 10).
Скоро ль там шестой пых…
— Контент
— Оформление
— Структура
Неужели MVC?
— Оформление
— Структура
Неужели MVC?
смотря, что под этим понимать и как к этому относиться
о, коллега! :)
вы согласитесь, что «мвц не существует»? ;)
вы согласитесь, что «мвц не существует»? ;)
и с какой стати мвц не существует?!
он даже на PHP существует, если очень поднапрячься этим вопросом.
он даже на PHP существует, если очень поднапрячься этим вопросом.
не к вам вопрос.
если немножко поднапрячься вопросом, вы поймёте, о чём я
если немножко поднапрячься вопросом, вы поймёте, о чём я
нет, я серьезно не понимаю.
«если немножко поднапрячься вопросом» — из этих слов у меня складывается впечатление что здесь всё очевидно.
а мне — не очевидно. Объясните пожалуйста, просветите — почему невозможно выдержать MVC? Под MVC я понимаю то, что написано у GoF'ов.
Давайте обсудим! :)
«если немножко поднапрячься вопросом» — из этих слов у меня складывается впечатление что здесь всё очевидно.
а мне — не очевидно. Объясните пожалуйста, просветите — почему невозможно выдержать MVC? Под MVC я понимаю то, что написано у GoF'ов.
Давайте обсудим! :)
Ребят, если чесно я неочень понимаю о чем Вы, не — я знаю что это, но никогда этим не пользовался))
здесь не всё очевидно; нужно действительно поднапрячься
фраза не гуглится?
если очень надо, могу найду старую статью и выложить в хабре. скорее всего, с дополнениями. гоф написали не всё
фраза не гуглится?
если очень надо, могу найду старую статью и выложить в хабре. скорее всего, с дополнениями. гоф написали не всё
Фразу загуглил, и нашел вот что: phpclub.ru/faq/DesignPatterns/ThereArentMVC
Порадовал аргумент автора:
«предположим, контроллер получает сигнал о необходимости изменений представления данных, обращается в модель за данными, модель (как достаточно высокоуровневая система) обращается к подсистеме хранения данных. И, следуя идее МВЦ, обращается она к контроллеру подсистемы, который запрашивает собственную модель, и т.д. вглубь… „
Да. Вглубь. Много-много раз вглубь. И что? Это написано из желания ограничиться тремя уровнями абстракции? Ну пусть будет тридцать пять уровней абстракции, лишь бы все были к месту.
Мне кажется, это не столько паттерн разработки, сколько паттерн мышления. Помните как было в Delphi/Pascal — в любом модуле обязательно выделять интерфейс и реализацию? Для этого даже кейворды специальные были. Ну или как в C++ — обязательно заголовок и основной текст. Точно так же и здесь: достаточно всегда проектировать все сущности исходя из MVC.
“г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.»
Веб-интерфейс на основе Ajax, поддерживающий код на стороне сервера, связь через RPC. Коллбэк клиенту со стороны сервера реализовать не получится, но в крайнем случае решается таймером или хорошими идеями %)
Со стороны это выглядит как монолитный модуль :) А еще есть всякие флешки и WebOrb'ы (которые как раз реализуют такой функционал искаропки).
«е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.»
Необъектные языки отправляются в жопу. PHP5 обладает убогой поддержкой ООП, но путем тяжкого труда и извращений она эмулируется. И статическая типизация эмулируется, да.
Порадовал аргумент автора:
«предположим, контроллер получает сигнал о необходимости изменений представления данных, обращается в модель за данными, модель (как достаточно высокоуровневая система) обращается к подсистеме хранения данных. И, следуя идее МВЦ, обращается она к контроллеру подсистемы, который запрашивает собственную модель, и т.д. вглубь… „
Да. Вглубь. Много-много раз вглубь. И что? Это написано из желания ограничиться тремя уровнями абстракции? Ну пусть будет тридцать пять уровней абстракции, лишь бы все были к месту.
Мне кажется, это не столько паттерн разработки, сколько паттерн мышления. Помните как было в Delphi/Pascal — в любом модуле обязательно выделять интерфейс и реализацию? Для этого даже кейворды специальные были. Ну или как в C++ — обязательно заголовок и основной текст. Точно так же и здесь: достаточно всегда проектировать все сущности исходя из MVC.
“г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.»
Веб-интерфейс на основе Ajax, поддерживающий код на стороне сервера, связь через RPC. Коллбэк клиенту со стороны сервера реализовать не получится, но в крайнем случае решается таймером или хорошими идеями %)
Со стороны это выглядит как монолитный модуль :) А еще есть всякие флешки и WebOrb'ы (которые как раз реализуют такой функционал искаропки).
«е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.»
Необъектные языки отправляются в жопу. PHP5 обладает убогой поддержкой ООП, но путем тяжкого труда и извращений она эмулируется. И статическая типизация эмулируется, да.
а) вы не дочитали
б) мвц на самом деле не является шаблоном реализации.
в) мвц — это приём проектирования систем.
я уже отспорил своё по поводу мвц. моё мнение вы только что невнимательно прочитали.
я позже вывешу эту статью, чтобы желающие могли высказаться. оффтопик — плохо. и троллинг с оверквотингом тоже плохо. мои извинения топикстартеру
б) мвц на самом деле не является шаблоном реализации.
в) мвц — это приём проектирования систем.
я уже отспорил своё по поводу мвц. моё мнение вы только что невнимательно прочитали.
я позже вывешу эту статью, чтобы желающие могли высказаться. оффтопик — плохо. и троллинг с оверквотингом тоже плохо. мои извинения топикстартеру
В теме про CMS обсуждение важного для построения CMS вопроса — не оффтопик.
Квотинг ровно такой, чтобы не читая исходную статью можно было понять смысл предложения. Я же не виноват что они там такие длинные.
зы, спасибо минус в карму =)
Квотинг ровно такой, чтобы не читая исходную статью можно было понять смысл предложения. Я же не виноват что они там такие длинные.
зы, спасибо минус в карму =)
ух, отозлился, теперь спокойнее %)
«дочитайте статью до конца» — это о последней фразе?
Тезисы всё те же: «всё есть объект», «всё есть MVC».
* Не используем под страхом расстрела необъектный код (кроме точки входа в программу)
* мысль о том, что пхп-скрипт является веб-страницей — запрещена.
* не используем любые другие методы проектирования и реализации кроме MVC.
Все эти тезисы — не просто рассуждения, которые надо держать в уме типа «хорошо бы это сделать», а жесткие и быстро реализуемые стандарты проектирования и кодирования.
Например, если замечен код вне классов — код считается невалидным.
«дочитайте статью до конца» — это о последней фразе?
Тезисы всё те же: «всё есть объект», «всё есть MVC».
* Не используем под страхом расстрела необъектный код (кроме точки входа в программу)
* мысль о том, что пхп-скрипт является веб-страницей — запрещена.
* не используем любые другие методы проектирования и реализации кроме MVC.
Все эти тезисы — не просто рассуждения, которые надо держать в уме типа «хорошо бы это сделать», а жесткие и быстро реализуемые стандарты проектирования и кодирования.
Например, если замечен код вне классов — код считается невалидным.
Даже не так,
— Контент
— Структура
— Оформление
MVP — вот :)
— Контент
— Структура
— Оформление
MVP — вот :)
через обманывание вашей системы я смог-таки ее поставить (почему сайт обязан быть в корне?), правда при установке он ругался что нет функции parent.ShowMessQ (обидно, не смог мне сказать, что все поставилось хорошо =)
а вот дальше хуже, поставилось… и… и что? как какой-нибудь «hello, world» сделать непонятно… или это у меня из-за грязных хаков при установке он недопоставился?
а вот дальше хуже, поставилось… и… и что? как какой-нибудь «hello, world» сделать непонятно… или это у меня из-за грязных хаков при установке он недопоставился?
это очень бетка — бетка))
еще замечание
— почему у файлов не указаны расширения?
не все пользуются блокнотом, и если в файле HTML + PHP пускай это будет *.php
— почему у файлов не указаны расширения?
не все пользуются блокнотом, и если в файле HTML + PHP пускай это будет *.php
ужасные названия файлов и переменных
что за директория «X» в корне?
что это за файл "_incl/source/p"?
ну и выше указанная функция «H()»
что за директория «X» в корне?
что это за файл "_incl/source/p"?
ну и выше указанная функция «H()»
За старения вам плюс, конечно.
1. Неплохо бы видеть online-demo.
2. Вы вот прямо так весь код html формирует для head и body в php? (извините за наверное глупый вопрос, но я не стал скачивать ставить CMS, так что вопросы только по описанному в топике)
3. В чем же «особенность» вашей CMS почему именно она, а не другие?
4. Клёвый домен r-ip прям таки R.I.P.
1. Неплохо бы видеть online-demo.
2. Вы вот прямо так весь код html формирует для head и body в php? (извините за наверное глупый вопрос, но я не стал скачивать ставить CMS, так что вопросы только по описанному в топике)
3. В чем же «особенность» вашей CMS почему именно она, а не другие?
4. Клёвый домен r-ip прям таки R.I.P.
1. Будет
2. Не совсем понял
3. В том, что ее сделал я сам;)
4. Сам в шоке!
2. Не совсем понял
3. В том, что ее сделал я сам;)
4. Сам в шоке!
2.
ну у вас в коде есть:
=$this->head() && =$this -> content(), например. Вот вы весь html код данных блоков генерируете или только то что меняется от страницы к странице? например: в head у вас script scr=«blablalba» генерируется или просто подставляется blablalba, это утрированный пример конечно? В то время как в body генерируется структуры блоков с содержанием или только содержание распределяется по блокам?
3.
Не определяющий фактор.
ну у вас в коде есть:
=$this->head() && =$this -> content(), например. Вот вы весь html код данных блоков генерируете или только то что меняется от страницы к странице? например: в head у вас script scr=«blablalba» генерируется или просто подставляется blablalba, это утрированный пример конечно? В то время как в body генерируется структуры блоков с содержанием или только содержание распределяется по блокам?
3.
Не определяющий фактор.
2. отчасти генерируется, от части подставляется
3. а почему этим нельзя гордиться?
3. а почему этим нельзя гордиться?
определенно этим стоит гордиться, развитие и нарабатывание опыта никогда и никому не мешали… однако я например не вижу смысла делать все то же, что есть у других, но самому. если делать, так то, чего еще нет, или как-то по-другому, лучше, интересней, быстрее, красивей наконец…
3. «Делайте сегодня то, о чем другие завтра только подумают…»
Сократ.
Сократ.
к online-демо можно ещё скриншоты добавить и код выложить на google
1. Это движок для php4? В требованиях вроде 5 тогда зачем ты используешь конструкцию вроде:
class APP{
var _Q;
Хотя пора бы уже так:
class APP{
private $_Q;
— 2. Конструкции переборов циклов не айс…
3. Использование виртуальных функций нет… может просто не нашел
4. Комментарии не дают понять что происходит в коде и зачем он нужен
5. Класс PHPMailer, SMTP хорошо написанs но под 4 версию…
Я бы тебе посоветовал овладеть еще PHP5 и идти в ногу со временем… А вообще я рад что есть такие энтузиасты, с такой силой пишешь ты свою cms =)
class APP{
var _Q;
Хотя пора бы уже так:
class APP{
private $_Q;
— 2. Конструкции переборов циклов не айс…
3. Использование виртуальных функций нет… может просто не нашел
4. Комментарии не дают понять что происходит в коде и зачем он нужен
5. Класс PHPMailer, SMTP хорошо написанs но под 4 версию…
Я бы тебе посоветовал овладеть еще PHP5 и идти в ногу со временем… А вообще я рад что есть такие энтузиасты, с такой силой пишешь ты свою cms =)
да — это уже превращается в смысл жизни
на счет php 5,4 система писалась очень долго и много раз переделывалась сами понимаете – за всем не угонишься, я например, сравнительно недавно только jQ увидел и освоил, у меня к сожалению нет помощников в этом деле, за этим я и пришел сюда, чтобы Вы мне помогли)
на счет php 5,4 система писалась очень долго и много раз переделывалась сами понимаете – за всем не угонишься, я например, сравнительно недавно только jQ увидел и освоил, у меня к сожалению нет помощников в этом деле, за этим я и пришел сюда, чтобы Вы мне помогли)
Only those users with full accounts are able to leave comments. Log in, please.
demiurGo.cms Вступление