Давайте учить PHP!

Ты помнишь как всё начиналось...:

:)

Пускай тут будет и "формирован мышления", но "обычная учёба" - это всё же получение базовых знаний. Минимум практики и та синтетическая.

"Не очень получается" далеко не у всех. А те редкие инд. репититоры - они лишь по одному (нек по 2 и 3) предмета, а не по всем. И эти как раз предметы, где ученик либо "не тянет" как все, либо нужны углублённые знания либо банально - коррупция (не будешь ходить - не видать медальки)

И причем у большинства тех, у кого "не получается" связано с плохими учителями и собственным разгильдяйсвом. Так что.. см п1 :)

Вот я расскажу реальный пример. У нас в общаге вместо штор висела клеёнка с чертежами схем телевизоров и пр радитехники (это дип. работы пред. поколений). Так вот, мы, как бухали (а не редко и без этого) - так всегда и начинались обсуждения этих схем. И я тебе скажу, что такое "обучение" (заметь - даже без преподов) было очень эффективным. И практически все, живущие в общаге были грамотные. За исключением пары трезвенников и полнейших раз..звиздяев, которые вообще ничего не хотели знать.

ИМХО это самое первое, что надо усвоить неофиту. А уж потом 10 команд SQL и прочие strpos().

Этим должны заниматься отдельные люди. Их можно нанимать. А если все изучать самому, то это не бизнес, а трудоустройство. К проекту нужно подходить, как к бизнесу.

Вот казалось бы, всегда считалось, что чтобы вести какой-то бизнес надо разбираться во всех его аспектах.

Т.е. суметь сделать работу любого нанятого человека. Несколько хуже, гораздо дольше и дороже, но суметь.

Знать как что работает, итд итп.

И тогда тебя не обмануть. Достаточно один раз вместо увольнения показать человеку, что ты прекрасно

понимаешь что к чему, и лапшу на уши тебе вешать не надо, и рабочие отношения налаживаются.

Нет, можно и увольнять, но это менее продуктивно. Дорого это очень, куча запоротых проектов итп.

Но чей-то последние лет 10 молодежь стали агитировать в сторону "ничё знать не надо - спецов купите,

главное чтобы пиджак на вас был правильным и часы".

Лично я условий успеха по такой схеме не знаю, но может и бывают....

Не, это не надо даже повторять. Это удобная форма для одурачивания.

Знания - это неизвестно что. А вот СОПОКУПНОСТЬ базовых ПОНЯТИЙ с возможностью оперирования ими - это и есть предметное мышление.

Кстати, есть очень выпуклое описание этих различий в обучении у Фейнмана в воспоминаниях о преподавании в Бразилии. Там вот этим "знаниям" учат.

Ну, я тоже свое психологическое образование получил преимущественно в кофейне общаги. Алкоголя там не было, а трава случалась :)

(Главные недостаток этого подхода - можно пропустить большие области "знаний", просто по неосведомленности. Ну, и время, время - его нужно много).

Кстати, именно так и строится учеба в элитных школах США - 2 ученика готовят по докладу с противоположными т.зр. на некую проблему, а потом - обсуждение в классе. Правда, там в качестве учителей - университетские преподы.

....

<?php include("/header.inc.php");?>

....

По поводу инклудов, включений и т.д. Любой файл на php должен начинаться с <?php и заканчиваться на ?>. Внутри больше не должно встречаться этих конструкций. То есть, программа на php не должна включать никаких разметок страницы и прочее. Только код. Включать другие php-обработчики естественно можно, но только без html.

Вся разметка должна находиться в шаблонах (файлы tpl, шаблонизатор xtemplate). Туда подставляются данные в нужные места и уже готовая страница выводится пользователю. Это позволит менять разные варианта дизайна, даже не залезая в код программы. И при этом, замена кода никак не повлияет на дизайн, и не придется переделывать все файлы. Есть и другие шаблонизаторы, но я с этим поработал - он меня полностью удовлетворяет.

В своей CMS я для себя вообще выделил несколько слоев управления:

1. Ядро системы. Все модули работают только через нее, никак не обращаясь напрямую к другим модулям. Это позволяет отключать модули и подключать их, не боясь, что все слетит.

2. Модули/функции, отвечающие за функционал сайта. К примеру, для интернет-магазина, модуль Shop - там все необходимые функции для работы с товаром, корзиной, каталогом и проч.

3. Абстрактный уровень. Блоки на сайте. Имеем только объекты, которые взаимодействуют друг с другом. Например объект "товар" и объект "корзина". Чтобы добавить товар в корзину, надо всего одну строчку кода (объект продукт помещаем в объект корзину):

$basket->add($product);

для удаления:

$basket->del($product);

Все! Настолько просто, что разработка новых блоков делается чуть ли не за минуты. И на абстрактном уровне не надо думать, как это все попадает в базу, какая база используется (да хоть в текстовые файлы можно записывать) - все необходимые действия делает модуль второго уровня. Да и то, он сам не знает, пишет ли он в базу данных, либо отправляет куда-то по сети, хоть в текстовый файл - этим всем управляет ядро.

Вообще, это тема отдельной статьи, если не книги... Столько нюансов, через которые пришлось пройти самому и после этого поняв, что надо делать именно так, а не иначе. По поводу верстки я тоже создал довольно большой список требований, чтобы при любых ситуациях не возникали "вот тут съехало, там теперь криво и т.д."

И кстати, не стоит путать понятие программист и кодер. Программист - это человек, который составляет алгоритмы работы программы. А кодер по этим алгоритмам пишет непосредственно код. Обычно, эти два понятия объединяются в одном человеке.

Мануал не так что бы согласен с Вами (вот никто не читает мануалы, ну никто:) ).

http://php.net/manual/ru/language.basic-syntax.phptags.php

Более того, во многих фреймворках и цмс, даже если файл содержит не только пхп код, но последним идет пхп код, то в конце закрывающий тэг не ставят.

Вся разметка это фанатизм. Большая часть разметки - да, лучше если будет в шаблонах. Но вот прям перфекционировать так, что бы непременно вся была в шаблонах - смысла нет. Зачастую оставить часть разметки в пхп коде куда разумнее.

Это из серии что "лучше писать i++ или ++i". Надо меру знать:)

Я вот, в свое время, читал, что написано:

PHP также допускает короткий открывающий тег <?,

Но после того, как при переносе сайта с одного хостинга на другой (с естественно, другими настройками) не сразу смог понять - какого фига ничего не работает. Ах, да, это же не обязательный тэг. Обязательный <?php - его игнорировать нельзя! А упрощенный - да нафиг его. Ну вот и не работает.

Так что после этого, все рекомендации вида "PHP также допускает" или "предпочтительно опустить" мною сознательно игнорируются, ввиду их необязательности к применению. Дабы избежать такого, что в следующей версии они все-таки решат, что закрывать нужно было. И что - опять все переделывать?

А насчет "случайных символов пробела или перевода строки после закрывающего тега PHP" - так проверяю все файлы, удаляю лишнее, смотрю кодировку и т.д. И нет проблем.

---------- Добавлено 29.06.2018 в 21:12 ----------

Нет. Во-первых, полное отделение разметки от кода позволяет настолько абстрагироваться, что вся программа пишется с ходу, вообще не задумываясь, что, где и как должно отображаться. Во-вторых, сразу знаешь, в каких файлах что искать и менять, при смене дизайна.

Единственное, что я оставил (да и то - временно) пока в php - это ответ на ajax запрос - в файлах есть текстовые сообщения, которые выводятся пользователю. Но и это, на самом деле, делать нежелательно - все должно идти из базы. Таким образом проще будет сделать мультиязычную систему. А вот ответ на ajax запрос в виде части html (например для корзины) - тоже берется разметка из шаблона. Это позволяет менять дизайн только в одном месте, а не выискивать кучу мест, где это могло быть.

P.S. Я никому не навязываю это. Но если есть желание лучше сразу делать хорошо, красиво и удобно, а не городить очередной битрикс.

---------- Добавлено 29.06.2018 в 21:17 ----------

Зря смеетесь. Я тут недавно столкнулся с невиданным "перлом" верстальщика. Вот эта строчка кода меня убила наповал:

colvo = colvo - 1 + 2;

Это было в готовом проекте! Ну ладно, я молчу, может человек не знал инструкции

colvo++;

Но вычесть единицу и прибавить два, чтобы получить инкремент - это уже за гранью. И нет, это не было опечаткой - этот код встретился три раза!

A007MP, поскольку тема в курилке, Вы можете писать любые измышления. Но при этом не забывайте почаще вставлять слова "Ящетаю", "ИМХО" и т.п.

Нам лениво спорить с доводом о сознательном игнорировании рекомендаций из мануала по пхп, но мы хотели бы повторно обратить Ваше внимание на то, что крупные фреймворки (zend, symfony, yii и многие другие) не используют закрывающего тэга. Посмотрите и убедитесь.

Хотите изобретать свой велосипед? Пожалуйста. Но будет все-таки неплохо, что бы он следовал стандартам индустрии при его использовании, а не так что направление движения задается багажником, а не рулем.

То что Вы хотите - это утопия, так же как хотят сделать универсальную цмс или с самого начала все так заоптимизировать, что бы работать быстрее всех. На самом деле 100% отделение это пустая трата времени. Идея здравая, идеалистическая, но... бессмысленная.

Вы сейчас рассуждаете как человек слышавший о нормализации БД и всюду все пытающися нормализовать... но проблема тут в том, что следующий этап обучения после нормализации - это денормализация. Обратное действие, которое в некоторых ситуациях имеет смысл.

Поэтому еще раз - выносить хтмл из кода надо, но не надо возводить это в абсолют. Часть конструкций можно и нужно оставлять в коде. Иначе Вы не просто потратите кучу времени впустую, но и сделаете тормозной движок со избыточно усложненной логикой.

Ох уж эта священная корова мультиязычности:) В серьезном проекте встроенная мультиязычность Вам будет не нужна просто потому, что по настоящему заточенный на мультиязычных людей сайт должен учитывать разницу не только в языках, но и в подаче контента, алгоритмах работы и прочем, т.е. по сути быть индивидуальным сайтом. Как следствие - он должен быть отдельно установлен и отдельно работать.

А мы вот привыкли не смеятся над странными решениями. То что оно странное - не значит что оно не имеет под собой причин, возможно причины есть - просто они непонятны.

Вот в приведенном Вами примером Вы смеетесь над "colvo = colvo - 1 + 2;" говоря что человек тупой и не знал конструкции colvo++, но Ваше рассуждение сомнительно, т.к. даже если он не знал конструкции colvo++, то несомненно он знал конструкцию colvo=colvo+1 (ведь он использует такую конструкцию), а значит для отказа от colvo++ была определённая причина, а не просто блажь. И неизвестно что Вы сломаете "оптимизировав" это до ++.