Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 85
Аж захотелось посмотреть, а то сам сижу на Eclipse + phpeclipse =)
Рекомендую пересесть. Сам перепробовал огромное количество редакторов. На данный момент лучшие:
1. Neon
2. Studio 5.5
3. NuSphere PHPEdit
1. Neon
2. Studio 5.5
3. NuSphere PHPEdit
Маленькое уточнение:
3. NuSphere PhpED.
PHPEdit это от WaterProof
3. NuSphere PhpED.
PHPEdit это от WaterProof
Прошу прощения.
Действительно Waterproof PHPEdit :)
Действительно Waterproof PHPEdit :)
Маленькое уточнение.
PHPEdit это может быть и от WaterProof.
А PhpED - все таки от NuSphere.
И это единственный редактор, который по функционалу может действительно конкурировать с Зендом.
PHPEdit это может быть и от WaterProof.
А PhpED - все таки от NuSphere.
И это единственный редактор, который по функционалу может действительно конкурировать с Зендом.
а вот интересно, в зенде есть mark occurences?
До меня только сейчас допёрло, что софтина то буржуйская и денюшку стоит.
Посижу я дальше на своём любимом eclipse + phpeclipse
Посижу я дальше на своём любимом eclipse + phpeclipse
И некоторую часть под хабракат бы спрятать, думаю будет лучше =)
Спасибо за статью.
Однако:
1. SVN. Прекрасно работало в ZDE, пользовался и был рад.
2. PHPDoc. Прекрасно работал в ZDE, также не нашел принципиальных различий.
3. TODO-лист был в ZDE, правда требовал проинсталлированного Zend Platform.
4. Дебаггер, профайлер в ZDE работали нормально, отличий принципиальных не нашел.
Собственно нового то только по сути оболочка... IDE. Остальное все осталось старое. Новый IDE дает нам прирост скорости, более удобный find/replace (его назвали рефакторингом), кучу настроек и плагинов.
Однако:
1. SVN. Прекрасно работало в ZDE, пользовался и был рад.
2. PHPDoc. Прекрасно работал в ZDE, также не нашел принципиальных различий.
3. TODO-лист был в ZDE, правда требовал проинсталлированного Zend Platform.
4. Дебаггер, профайлер в ZDE работали нормально, отличий принципиальных не нашел.
Собственно нового то только по сути оболочка... IDE. Остальное все осталось старое. Новый IDE дает нам прирост скорости, более удобный find/replace (его назвали рефакторингом), кучу настроек и плагинов.
Гм. В зенде профайлера как такового не было. Дебаггер - да, профайлера нет ) Приходилось юзать xDebug.
Вы говорите не было, а я им пользовался. Смысл в том, что кажется нужен был Zend Platform. Но факт остается фактом. Профайлер был и был неплохой, во всяком случае с его помощью я легко находил узкие места в проектах.
профайлер был. если юзался удаленный дебаг(а это удобно), то в меню можно было пользоваться "Debug->Profile URL"
и полного ZP не надо было, достаточно было удаленного экстеншна для дебага. он, кстати, бесплатен, и раньше входил в Zend Studio Server(и теперь лужит где-то в http://downloads.zend.com ). То что информацию про екстеншн больше не распространяют - наверно попытка всех перетащить на платный ZP
и полного ZP не надо было, достаточно было удаленного экстеншна для дебага. он, кстати, бесплатен, и раньше входил в Zend Studio Server(и теперь лужит где-то в http://downloads.zend.com ). То что информацию про екстеншн больше не распространяют - наверно попытка всех перетащить на платный ZP
Unit-test все же упрощает работу с оным. Попрошу попрошу. Хотя да, могли бы вместо визивига сделать работу с веб-сервисами (soap wsdl всякими), к примеру, или еще чего полезного программистам.
SVN был врапером для консольного клиента, и нормально работать с ним было можно только, если вы на проекте в одиночку.
Автор, а можно по подробнее про Database Explorer. Хочется посмотреть на это, т.к. ищу альтернативу SQLyog. Гугл мне сказал что есть такая вещь но только в сборке MyEclipse, не подскажешь где взять отдельно сам плагин?
Это бета, но ей уже реально можно нормально пользоваться?
в дополнение, хотя может это уже известно, в папке "\Program Files\Zend\Zend Studio Neon - Beta\docs" лежит user guide
Насчет рефакторинга - оно и понятно. Вы хотели чтоб ZS за вас догадывался что такое, к примеру
define('ROOT_DIR', dirname(__FILE__) . '/');
include ROOT_DIR . 'library/' . $someclass . '.php';
и так далее? Это уж слишком. В java все проще будет, там вы пишете чего используете а чего нет и где копать. В гибкости это лучше для пхп, но в рефакте - нет.
define('ROOT_DIR', dirname(__FILE__) . '/');
include ROOT_DIR . 'library/' . $someclass . '.php';
и так далее? Это уж слишком. В java все проще будет, там вы пишете чего используете а чего нет и где копать. В гибкости это лучше для пхп, но в рефакте - нет.
В идеале - да :)
Честно говоря жестко типизированные языки мне нравятся гораздо больше.
Честно говоря жестко типизированные языки мне нравятся гораздо больше.
На вкус и цвет, как говорится... А вообще думаю что php идет к тому чтоб сделать как в питоне возможность галочки жесткой типизации. Не помню, было ли это в тексте "это будет в пхп 6", однако надо бы поглядеть.
А сия гибкость мне нравится просто потому что можно граммотно разбить на файлы ваш скрипт и, к примеру, делать
require_once 'Kost/Tree/Exception.php'
throw new Kost_Tree_Exception('error with your tree');
- это экономит время так как в остальных случаях о существовании Kost/Tree/Exception.php никто даже спрашивать не будет, уж тем более обрабатывать его. А это такой себе неплохой плюсик.
А сия гибкость мне нравится просто потому что можно граммотно разбить на файлы ваш скрипт и, к примеру, делать
require_once 'Kost/Tree/Exception.php'
throw new Kost_Tree_Exception('error with your tree');
- это экономит время так как в остальных случаях о существовании Kost/Tree/Exception.php никто даже спрашивать не будет, уж тем более обрабатывать его. А это такой себе неплохой плюсик.
А в php вы пишете __autoload и ему показываете где копать :)
Да ради только одного повышения скорости работы стоит непременно пощупать. Спасибо за обзор.
Есть. есть различия. Для меня очень важные :)
Например:
- Автодополнение в Js. Т.е пишем: "window." потом клацаем Ctrl+space и наслаждаемся списком всех свойств/методов класса.
- Тоже самое для css
- Переключалка просмотра xml "Design"/"source"
- Валидация HTML/CSS
- Проверка на наличие подключаемых файлов. там выше писали про:
"
define('ROOT_DIR', dirname(__FILE__) . '/');
include ROOT_DIR . 'library/' . $someclass . '.php';
" >> не будет работать.
Но, позволю себе заметить. Это не правильно. Ну т.е код будет работать. Но так лучше не делать.
За пример я беру ZendFramework. там такого кода не встретишь.
Т.е я хочу сказать, что лучше найти более красивое решение или пересмотреть архитектуру.
Например:
- Автодополнение в Js. Т.е пишем: "window." потом клацаем Ctrl+space и наслаждаемся списком всех свойств/методов класса.
- Тоже самое для css
- Переключалка просмотра xml "Design"/"source"
- Валидация HTML/CSS
- Проверка на наличие подключаемых файлов. там выше писали про:
"
define('ROOT_DIR', dirname(__FILE__) . '/');
include ROOT_DIR . 'library/' . $someclass . '.php';
" >> не будет работать.
Но, позволю себе заметить. Это не правильно. Ну т.е код будет работать. Но так лучше не делать.
За пример я беру ZendFramework. там такого кода не встретишь.
Т.е я хочу сказать, что лучше найти более красивое решение или пересмотреть архитектуру.
Автодополнение для js и css это отлично. Все время этого ждал. Буду качать даже только ради этого;)
понятное дело что такое лучше не делать, но в коде зенда можно найти файлы, подключаемый в середине кода (те же эксепшны), есть и адаптеры которые подключаются по мере необходимости, есть loadClass'ы, вообще являющиеся утилитами. И все это вещи нужные и правильные (в отличии от моего примера, само собой). Может частично ZS и маг, но всего он не умеет делать.
Кстати тоже вот вопрос:
У меня есть один класс в котором я юзаю функцию __call
Ну и естественно есл ия его начну использовать - то для него не будет работать автодополнение.
Вопрос: Надо ли переписать класс таким образом что бы не было __call()?
Я как то не видел нигде информации о том, рекомендуется ли использовать эту функцию или всё же стоит страться проектировать классы таким образом что бы таких ситуаций не возникало?
У меня есть один класс в котором я юзаю функцию __call
Ну и естественно есл ия его начну использовать - то для него не будет работать автодополнение.
Вопрос: Надо ли переписать класс таким образом что бы не было __call()?
Я как то не видел нигде информации о том, рекомендуется ли использовать эту функцию или всё же стоит страться проектировать классы таким образом что бы таких ситуаций не возникало?
Глобально мысль сводится к тому что:
Если редактор реагирует на ваш код неадкватно - надо ли его(код) переписывать? Или положится на то что "мой код просто очень хитрый и такое решение на самом деле гениально по сути. А то что IDE на него плюётся так это его проблемы.
Если редактор реагирует на ваш код неадкватно - надо ли его(код) переписывать? Или положится на то что "мой код просто очень хитрый и такое решение на самом деле гениально по сути. А то что IDE на него плюётся так это его проблемы.
Я думаю не стоит прогибаться под редактор, ведь все равно останутся ситуации когда ф-ция возврщает переменную какого-то класса, а так как php не типизированный - IDE теряется и внутренних ф-ций особо не находит. С этим должна бороться IDE и разработчики пхп (насчет строгой типизации должны подзадуматься чтоб была возможность такая), а не вы.
Насчёт этого в ещё в Zend Studio придумали решение.
Там когда обьявляешь функцию пишешь:
Там когда обьявляешь функцию пишешь:
/**
* __getSomeObject
*
*
* @author josser
* @class someClass
* @access public
* @return <b>ObjectClass</b> $someObject
*/
function __getSomeObject() {
... }
И потом при вызове функции резальтат будет иметь тип ObjectClass и для него будет работать автодополнение.
Т.е некоторые вещи можно делать. И как правило это не какие-то хаки. а стандартные всеми принятые варианты реализации чего-либо. (Как например в вашем примере когда функция возвращает обьект).
А что делать с теми которые нельзя?
С той же функцией __call() или __autoload()?Прошу прощения за незакрытый тег и не совсем адекватно-понимаемые названия классов и методов.. :)
Но я надеюсь суть я передал.
Но я надеюсь суть я передал.
Действительно, я в топике пропустил что идешку научили этому. Но вещь эта совсем даже стандартная и называется PHPDoc. Немного костыли, но уже приятно. (если оно в случае ошибки возвращает false, к примеру? надо описывать как mixed, а потом еще как-то?)
p.s.: ушел проверять на понимание @throws и прочего
p.s.: ушел проверять на понимание @throws и прочего
> Даже несмотря на то что приходится ставить заглушки вида…
По-вашему, засорять свой код в угоду не совсем умному аналайзеру — это правильно?
По-вашему, засорять свой код в угоду не совсем умному аналайзеру — это правильно?
Эм. Если взять за сравнение что хуже - такая безобидная заглушка, или реально непроинициализированная переменная - то я выбираю первое. По крайней мере четко знаешь чего от него ожидать.
А зачем эти беды сравнивать? Инициализируйте переменные, не пишите мусора, и будет вам щастье. Пускай они лучче аналайзер поправят, чтобы он на пустой метод обработки исключения не ругался.
А Вы с Eclipse PDT знакомы?
Я вчера полчаса пытался найти отличия Neon от PDT с плагинами - так и не нашел. Хочу еще чье-нибудь мнение узнать :)
Я вчера полчаса пытался найти отличия Neon от PDT с плагинами - так и не нашел. Хочу еще чье-нибудь мнение узнать :)
Эм :)))
Тут не пробовали смотреть? http://www.zend.com/products/zend_studio…
Тут не пробовали смотреть? http://www.zend.com/products/zend_studio…
Да-да, поддерживаю. Я уже второй год работаю только с PDT. (Сказать по правде, когда узнал, что PDT ZEND разарабатывают, был весьма и весьма удивлен).
Из перечисленного в статье к Eclipse нельзя так запросто прикрутить профайлер. Все остальное, ну почти все, это достоинства не Neon, а Eclipse в целом и PDT в частности.
HTML, CSS и JS? Это WTP. База данных? Это DTP. PHPDoc и тайпхинтинг? Это из PDT.
//FIXME и //TODO? Это еще из JDT тянется.
PHPDocumentor и PHPUnit как external tool в Eclipse подключается на ура.
etc
Главная разница - PDT вы накачиваете сами, Neon уже прокачан. Это, безусловно, здорово, но все вышееперечисленое не позволяет говорить о Neon, как о "революционном" продукте.
Сдается мне, Zend хорошо все продумали: был у них Zend Studio; они пишут открытый и бесплатный PDT; захватывают значительную часть рынка PHP IDE; переезжают сами на PDT; теперь пользователи PDT легко и безболезненно могут переходить на Neon, как только денег накопят =)
Стратегически - на 5+
P.S. PDT, кстати, не заморожен - новые билды продолжают появлятся
Из перечисленного в статье к Eclipse нельзя так запросто прикрутить профайлер. Все остальное, ну почти все, это достоинства не Neon, а Eclipse в целом и PDT в частности.
HTML, CSS и JS? Это WTP. База данных? Это DTP. PHPDoc и тайпхинтинг? Это из PDT.
//FIXME и //TODO? Это еще из JDT тянется.
PHPDocumentor и PHPUnit как external tool в Eclipse подключается на ура.
etc
Главная разница - PDT вы накачиваете сами, Neon уже прокачан. Это, безусловно, здорово, но все вышееперечисленое не позволяет говорить о Neon, как о "революционном" продукте.
Сдается мне, Zend хорошо все продумали: был у них Zend Studio; они пишут открытый и бесплатный PDT; захватывают значительную часть рынка PHP IDE; переезжают сами на PDT; теперь пользователи PDT легко и безболезненно могут переходить на Neon, как только денег накопят =)
Стратегически - на 5+
P.S. PDT, кстати, не заморожен - новые билды продолжают появлятся
божее.. эклипс... и его АДСКОЕ КОНФИГУРАЦИОННОЕ ОКОШКО.... найти чтото с первого раза просто нереально..
А для любителей Перла есть что-нибудь сопоставимое по мощи? (под Linux)
Кстати, на "В Zend Studio 5.5 был баг, из-за которого при настроенной работе с SVN-ом сам редактор начинал тормозить. " - ссылку можно? А то у меня эти тормоза тоже наблюдались.
Я так понял, что они встроили SVN в Zend Studio Neon? Интересно, зачем. Есть ведь плагин Subclipse, который прекрасно работает.
На всё воля Аллаха - решили разработчики и встроили :) С subeclipse не работал, поэтому сравнить не могу :(
Попробуйте. У меня вообще никаких проблем с ним не было. Прекрасно работает с любыми типами файлов, с любыми view. Очень удобен.
Просто так нельзя. Они тогда могли бы и Eclipse не использовать, а продолжать писать свою Zend Studio с нуля. Огромный потенциал Eclipse — именно в плагинах. Зачем встраивать в свой и без того монструозный плагин дополнительную функциональность, для которой уже существуют вполне стабильные и мощные решения.
В Zend Studio и раньше были phpdoc и profiler.
Грубо говоря это та же Aptana к которой добавили Zend Framework.
Что-то трудно назвать этого монстра удобным продуктом для разработки, кроме автоматизации работы с фреймворком больших удобств в работе не наблюдается в сравнии с тем как "быстро" эта каракатица работает, у меня не слабый компьютер на коре 2 дуо и даже он бедняга втыкает при сохранении проекта всего на 10к строк. Просто Zend Studio как по мне более живучий и удобный продук, не смотря на перечисленные недостатки.
Что-то трудно назвать этого монстра удобным продуктом для разработки, кроме автоматизации работы с фреймворком больших удобств в работе не наблюдается в сравнии с тем как "быстро" эта каракатица работает, у меня не слабый компьютер на коре 2 дуо и даже он бедняга втыкает при сохранении проекта всего на 10к строк. Просто Zend Studio как по мне более живучий и удобный продук, не смотря на перечисленные недостатки.
Почему то у меня в этом неоне для PHP скрипта не работает outline, то есть список функций в классе не отображается. Я что-то не так делаю? Где там покрутить можно?
Может быть кто-то знает как можно руссифицировать zend neon?
В 5.5 версии перевод языка был посредством изменения локали в файле desktop_options.xml.
В 5.5 версии перевод языка был посредством изменения локали в файле desktop_options.xml.
Всетаки в анализаторе кода достаточно много глюков. Например, передача параметра по ссылке:
Выдает ванинг "переменная $param не используется". Если его убрать, получим другой варнинг "неиспользуемый параметр функции".
Конструкция:
выдает варнинг "Результат выражения $this->var++ не ипользуется". Если заменить на $this->var+=1, то всё ок.
И, кстати, как отключить проверку валидации HTML - реально задолбала?
function x(&$param){
$param = 123;
}
Выдает ванинг "переменная $param не используется". Если его убрать, получим другой варнинг "неиспользуемый параметр функции".
Конструкция:
class X{
public $var;
function f(){
$this->var++;
}
}
выдает варнинг "Результат выражения $this->var++ не ипользуется". Если заменить на $this->var+=1, то всё ок.
И, кстати, как отключить проверку валидации HTML - реально задолбала?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Небольшой обзор Zend Studio Neon Beta