Всем привет! Возможно некоторые постояльцы форума помнят, что в Марте прошлого года я проходил тестирование по PHP, но решил не останавливаться на достигнутом и на этот раз решил пройти тестирование по Zend Framework 2. Решил и прошел В данной заметке я расскажу о Zend сертификациях в целом но больше всего уделю внимание тестированию по Zend Framework 2. Я не буду описывать незначительные мелочи потому что данный пост и без этого получится большим. Если у кого либо возникнут вопросы, пишите тут, я постараюсь на них ответить.
Общее представление о Zend сертификациях:
Если кто не в курсе, компания Zend (разработчик PHP, Zend Framework) проводит сертификацию по PHP и Zend Framework.
Человек, который сдал один из этих экзаменов(независимо от того, по PHP или ZF), получает статус Zend Certified Engineer(ZCE).
Для того что бы было понятно какое/какие именно экзамены сдал разработчик, ZCE имеют уточняющие статусы(можно иметь сразу оба статуса):
1. Те ZCE, которые успешно сдали экзамен по PHP, имеют уточняющий статус: Zend Certified PHP Engineer
2. Те ZCE, которые успешно сдали экзамен по ZF2, имеют уточняющий статус: Zend Framework 2 Certified Architect
Как вообще можно попасть на Zend экзамен?
Процесс регистрации включает в себя заполнение специальной анкеты(заявка на экзамен) и покупку ваучера цена которого на данный момент составляет 195$.
Пройти процедуру регистрации можно на сайте www[dot]pearsonvue[dot]com или в самом тест центре.
Тест-центр для конкретной страны/города можно поискать тут: http://www[dot]pearsonvue[dot]com/servle[dot][dot][dot]ster&cid=346
Экзамен проводится на специальном компьютере где запущена программа для тестирования на весь экран. Нет возможности пользоваться интернетом, читать доки, гуглить и т.п, поэтому нужно быть готовым к сдаче "из коробки".
Экзамены проводятся на Английском языке. Оба включают в себя по 70 вопросов, для ответа на которые предоставляется 90 минут(для каждого экзамена по 90 минут).
В ходе экзаменов вопросы можно пропускать и возвращаться к ним позже.
Ответы на вопросы могут быть трех типов:
1. Выбор одного ответа из предоставленного списка возможных ответов
2. Выбор одновременно 1-3 правильных ответов
3. Нужно ввести ответ самостоятельно с клавиатуры в специальный инпут
Что же представляет из себя тестирование по ZF2? Поехали!
Информация о темах, которые встречаются на экзамене находится по адресу: http://www[dot]zend[dot]com/en/services/[dot][dot][dot]tion/framework-2 (темы описаны после заголовка Exam Topics). Как говорил выше, 70 вопросов по этим темам и 90 минут времени на ответы.
Не доверяйте "облегчающим жизнь источникам"!!!
Перед экзаменом я искал заметки типа той, которую сейчас пишу сам для получения как можно больше информации о тестировании по ZF2.
Наткнулся на пост, где один из сдавших говорил, что не было вопросов по веб службам. Судя по всему, вопросы выпадают рандомно, и мне, похоже, повезло меньше чем ему. Как раз таки были вопросы и по SOAP/WSDL, XmlRpc. Мораль: если Вы собираетесь сдавать экзамен, не рассчитывайте на то, что "эту тему я не буду изучать, потому что парню из блога она не попалась". К счастью, я не повелся на это и изучил все темы максимально хорошо как только смог.
А не перегибаете ли вы, товарисч?!
Некоторые вопросы показались мне слишком "придирчивыми". Встречались вопросы, где нужно было быть в курсе, как программно реализована та или иная фича фреймворка.
Думаю это перебор. В большинстве случаев разработчикам, которые используют фреймворк, скорее всего чихать, как его компоненты устроены на уровне ядра и какие патерны использовались для их реализации.
Так же были вопросы, где нужно было знать сигнатуры интерфейсов фреймворка, которые в свою очередь так же являются интерфейсами и порядок их аргументов. Весело.
Было много вопросов, где ответ приходилось писать руками в специальный инпут, где то штук 10 насчитал. И попробуй ошибись хоть в одной букве.
Причем иногда приходилось вписывать в этот инпут "Ну очень длинное название метода который описан в неком интерфейсе".
Мне повезло в том, что в данный момент я нахожусь в отпуске и у меня было время на "освежение" памяти, иначе хрен бы ответил.
Что я получил от сдачи экзамена:
1. Хорошо изучил популярный и востребованный фреймворк
2. Изучил много хороших практик проектирования, что несомненно помогает мне разрабатывать приложения лучше чем прежде
3. Добавил блатную строчку в свое резюме
В течении 48 часов на моей страничке в Yellow Pages должен появиться бейдж подтверждающий сдачу мною данного экзамена.
Сертификат обещают прислать в течении 4-6 недель по почте.
Надеюсь эта заметка окажется для кого нибудь полезной.
Дело в том, что таким образом мы теряем идеологию MVC, т.е смешиваем все в кучу. Ты утверждаешь, что View должен сам заботиться о получении данных которые ему нужно "отрисовать". Для получения данных которые надо показать во вью может понадобится куча инструментов, например роутер, сессии, обращение к файловой системе, обращение к SOAP(и т.п) серверам с передачей и получением данных, использование API различных сайтов для получения данных которые нужно будет вывести в HTML, и все это ты собираешься делать во View? По хорошему реализация чего либо(в данном случае речь о View) не должна решать 100 задач, максимум одну, свою.
caballero пишет:
его дело представить данные с сервера. Статус коды тоже данные
Да, это данные. Но данные с сервера приходят с ответом, а View сам по себе не является ответом. Так же ответы могут быть разными. Ответ может быть например редиректом на сторонний ресурс, где лично твой View ничего отображать не будет. Представление в контексте MVC это графическое представление, которое в конечном счете видит пользователь.
caballero пишет:
где сказано что он должен быть? На курсах програмирования? мы обсуждаем принцип а не единственное решение которое ты видел в жизни
Ну, во первых это не единственное решение которое я видел в жизни, во вторых, как минимум потому, что это логично. Помимо того, что это логично, программист таким образом может определить для себя единую точку отправки ответа что делает архитектуру более предсказуемой и удобной. Попробуй подумать над этим на уровне интерфейсов а не на уровне реализации, думаю в этом случае все придет на свои места.
DelphinPRO
Пример по правде говоря не очень и добавление одной строчки в контроллере не составит труда, особенно ради внятного кода. И не факт что данные по вью передаются именно по указанному примеру. Мне например удобно сделать что то типа $model->find(array('id' => 5))->fetchIn('Package\Entity\User') и во вью уже отдать этот entity, тогда не придется править контроллер а достаточно будет вызвать $user->getAge()
caballero пишет:
в теме идет речь от ОТОБРАЖЕНИИ данных
А я понял. И получится у тебя неоднозначная логика.
caballero пишет:
что мешает view отправить щзаголовки а потом рендерить собственно страницу?
Технически ничего не мешает, но это не логично. Вью(имеется ввиду не шаблон а API который формирует разметку) не должен отправлять заголовки, его дело заниматься формированием разметки а не устанавливать статус коды/отправлять заголовки и т.п, для этого должен быть Response, который и должен возвращать сформированную View API разметку(если это требуется) + заголовки.
Более того, раз уж перекидываешь отправку ответа на шею View, то смотри: тебе надо отправить клиенту json и ничего более, разве логично отправлять его через View? Здесь нет никакого представления, это всего лишь json.
Зачем же так категорично? Почему вью не может сам обратиться к модели?
Потому что MVC подразумевает отделение мух от котлет.
caballero пишет:
Вообще то он и должен обращатся если по уму
Не нужно забывать, что работа с моделью подразумевает не только получение, но и изменение/добавление/удаление уже существующих данных, а эти задачи выходят за рамки view. К тому же, модель может не иметь данных для вью, а делать какие нибудь внутренние операции с данными, которые не подлежат представлению, что опять же не приемлемо для выполнения этих операций во вью. Так же есть ситуации, где во view работать с моделью уже будет поздно, например в том случае, как написали выше, если требуется отправить заголовки на основе извлеченных данных. А если действовать по обстоятельствам в отношении работы с моделью, это приведет к неоднозначности что отрицательно отразится на качестве кода.
Более того, очень часто приходится брать параметры из роутера, и на основе этих параметров извлекать данные из модели. Это означает, что во вью придется давать доступ в том числе и к роутеру, что не приемлемо, потому как вью не должен знать о роутере. Исключением может быть формирование ссылок по имени роута, и то обычно это делается через плагины вью, а не через прямое общение с роутером.
Можно ещё поговорить о том, почему не нужно работать с моделью во вью, но думаю этого достаточно.
Тут все зависит от того, что вообще нужно сделать в конечном счете.
Если требуется получить именно массив и требуется его дополнительная обработка, например применить к нему функции для работы с массивами, тогда все четко.
А если надо просто вывести данные в цикле, тогда не нужно делать лишние телодвижения вызывая toArray.
armancho7777777
Явное обращение к ResultSet тут не нужно он и так вернется, нужно просто закинуть в форыч $result и в качестве значения будет "сваливаться" экземпляр ArrayObject, а там уже можно с ним работать как с объектом или как с массивом, на выбор.
если есть единая точка входа то можно глубоко не нырять
достаточно в этой точке прописать условие если запрашиваемый адрес тот который регистрирует пользователей то убивать скрипт
До меня не доходит то почему разработчики делят один простой шаблон на образно выражаясь 1000 кусков даже когда это не нужно. Делить нужно тогда, когда в этом есть необходимость и только то, что нужно.
Например, есть какой то блок, который появляется на 4 разных страницах из 10. В этом случае есть смысл выделить этот самый блок в отдельный шаблон чтоб не дублировать код и подключать этот шаблон там где он нужен.
Если образно выражаясь меняется только "центральная часть", то тут двух шаблонов будет достаточно. Один постоянный(общий), а центральный уже подключать в зависимости от страницы. И да, инклюда тут более чем достаточно, никакие регулярные выражения и разделители не нужны. Скажи честно Вам самому удобно этим страдать?
По поводу скорости - тут все зависит от используемых инструментов и количества телодвижений в том или ином случае. Не буду расписывать подробно, думаю понятно о чем я.
Не нужно в БД ничего искать просто не доводи до сохранения входящие данные(например там где в коде процесс регистрации сделай exit('Регистрация запрещена');) ну или поставь нормальную капчу
ЗЫ: где и что лежит в джумле я не в курсе, тут уже сам подсуетись ;) (Добавление)
Вот тут есть процесс отключения регистрации http://otvety[dot]google[dot]ru/otvety/t[dot][dot][dot]3a4522ba5d68e0fd из админки, а так как админки у тебя нет, попробуй поискать таблицы с наводящим названием ориентируясь по ссылке выше(если уверен что это дело управляется именно через БД) а не из какого нить там хмл или ещё чего то. Если гемора на поиск "правильного отключения" уйдет много времени то просто убей скрипт и не сохраняй данные
что происходит при повторном вызове beginTransaction?
Транзакция внутри транзакции? ) Fatal error.
Смысл отключать автофиксацию в том, когда нужно получить "всё или ничего".
Либо запросы выполняются стопудово(ну, во всяком случае если ответ PHP после "общения" с СУБД таков), либо не выполняется вообще.
если в трайе пойдет что то не так(в контексте PDO), то ни один запрос не будет считаться зафиксированным. Не будь этого механизма, то первый query выполнился бы и было бы плевать если в третьем query произошел error.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1465
В данной заметке я расскажу о Zend сертификациях в целом но больше всего уделю внимание тестированию по Zend Framework 2. Я не буду описывать незначительные мелочи потому что данный пост и без этого получится большим. Если у кого либо возникнут вопросы, пишите тут, я постараюсь на них ответить. 
