Генерим autocomplete для LiveStreet под Eclipse

1. ставим ls-yii из репозтария

2. делаем
chmod +x plugins/yii/include/framework/lsyiic
mkdir codedoc && chmod 0777 codedoc


3. запускаем генератор
plugins/yii/include/framework/lsyiic lsshell gencodedoc end


4. чекаем на ошибки получившиеся файлы

5. вписываем в проект external source


6. дико тащимся и говорим спасибо

траблашутинг:
— вырубите авадимовскую админку, у нее дикий автолоадер
— в GencodedocCommand закомментируйте 2 ob_start()'а
— смотрите на трейсы

чтобы поцоны совсем расслабились, методы для чистого движка
yaglov.ru/uploader/upload/0lvmlcc-01k50hc-0d1730z/files/codedoc.zip

41 комментарий

avatar
В PHPStorm, кстати, работать не будет. Multiple Declarations все дела. Вообще и будет только в нетбинс мне кажется.
Решить можно попробовать состряпав аналогичный файл только используя phpDOC @method
, но не уверен в результате

ЗЫ
Класс называть Object не самая лучшая идея была, учитывая что есть PHPшный class Object
avatar
ре-зы. а еще он почему-то декларирован как абстрактный в engine/classes/Object.class.php
как так? почему фатал не появляется?
avatar
а с чего бы ему быть?
освежите теорию
avatar
ок
avatar
вроде такая же ситуация?
D:\>php -r "class a{}; abstract class a{}; class b extends a{};"

Fatal error: Cannot redeclare class a in Command line code on line 1

Call Stack:
    0,0004      54424   1. {main}() Command line code:0
avatar
В PhpStrom вот так работает «Autopopup documentation feature» blog.jetbrains.com/webide/2010/07/autopopup-documentation-feature/

avatar
К чему Вы это?
avatar
Может кому-то будет полезно что в нем есть такая возможность изначально просто она по умолчанию только по хоткею появляется
avatar
учитывая что есть PHPшный class Object
может не класс, а тип?
Вот список классов — de2.php.net/manual/en/reserved.classes.php
avatar
Кстати а какую IDE для разработки LiveStreet используешь? Если не IDE, то чем для этих целей пользуешься?
avatar
Всегда использовал Zend 5, с переходом на mac пришлось использовать Zend 7, сейчас смотрю в сторону PhpStorm
avatar
ИМХО, в очень правильную сторону смотришь
avatar
вроде в нем все хорошо, но вот не смог найти, как определять — сохранен файл или нет? вроде стандартная фича, без неё уже не могу
avatar
У меня раньше рефлекс был — Ctrl+S пальцы сами жали, любая пауза, чуть задумался либо через какой-то промежуток времени, автоматом — тынц. А в PhpStorm автосохранение работает, сначала немного непривычно было, но щас настолько к этому привык, что когда мелкие правки делаю в каком-нить Notepad++, то забываю сохранять, хоть там и есть индикатор, сохранен файл или нет
avatar
что когда мелкие правки делаю в каком-нить Notepad++, то забываю сохранять
вот это и пугает
PhpStorm возможно отключить авто-сохранение и включить индикатор изменения файлов?
avatar
Да, тип конечно.
avatar
Спасибо, для Zend Studio все отлично сработало. Хотя все статические методы она и так глотала. Трабл был с автолоадными методами. Только мой совет, отрубайте автобилд, ибо выжирает всю память.
avatar
Как кстати заставить работать сие в плагинах, когда они наследуют Inherit класс?
avatar
после того как сгенеришь для своего проекта, см. файл inherits.php, там всё будет.
avatar
пока не разобрался, как этот генератор запускать в винде, написал скрипт, который сгенерил мне все классы)
avatar
в винде я и запускал )
avatar
«php -f » вначале добавить
avatar
в винде вроде CLI режим запускается как-то так, судя по мануалу:
C:\PHP5\php.exe -f "C:\PHP Scripts\script.php" -- -arg1 -arg2 -arg3

Только надо иметь пых на локальном компе.
У меня как раз он на удаленном в сети, и чего-то не получилось.
avatar
у меня в PATH прописана папка в бинарником php.exe, так что запускается из любой папки в консоли. часто юзаю php в cli-режиме даже под виндами
avatar
принцип тот же — создать список возможных Inherit классов и унаследовать их от Object
avatar
А правильно ли от Object?
Допустим, есть PluginBla и PluginFoo (и подгружаются именно в таком порядке), и в обоих наследуется класс ActionTopic. Значит, явно у нас определяются классы:
class PluginBla_ActionTopic extends PluginBla_Inherit_ActionTopic {}
class PluginFoo_ActionTopic extends PluginFoo_Inherit_ActionTopic {}

Я для себя сварганил скрипт, который генерит дополнительно такие объявления:
class PluginFoo_Inherit_ActionTopic extends PluginBla_ActionTopic {}
class PluginBla_Inherit_ActionTopic extends ActionTopic {}

И теперь, если я правлю код в классе PluginFoo_ActionTopic, то PhpStorm нормально определяет всю цепочку наследования, показывает перекрытие классов, вызывается автокомплит свойств и методов родительских классов при написании кода и проч. Короче, все, как доктор прописал.

Если же PluginBla_Inherit_ActionTopic и PluginFoo_Inherit_ActionTopic наследовать сразу от Object, то вся цепочка наследования ломается.

У меня пока только вот руки не дошли методы модулей описать, которые через «магические» методы вызываются, типа $this->Viewer_Assign(). Да и не придумал я еще, как это лучше сделать.
avatar
та как не делай, при добавлении нового плагина надо перегенеривать.
Никто не знает, эклипсу можно ли написать паттерн, по которому бы он отслеживал автолоад и не матерился на Plugin_Module_Method?
avatar
Хех, так у меня как раз при активации нового плагина и происходит перегенерация цепочек. Так что «все учтено могучим ураганом» ;)
avatar
Это кстати на уровне ЛС реализовано, на методе Activate() висит обработчик?
avatar
Я ж ведь со своей админкой все, как с писаной торбой :) Она частично заменяет ядро движка. И у меня там активация/деактивация плагинов через свои методы идет
avatar
ждем API админки. А то вот у меня управление в плагине доп характеристик топика через экшен Admin идёт. Юзер себе поставит админпанель, а она ведь перезатрет этот экшен.
Надо хоть какую-то совместимость предусмотреть :).
avatar
Начал уже это делать, но переход на 0.5 с поддержкой двух разных js-библиотек занял в разы больше времени, чем планировал. Щас устаканится чуток — доделаю
avatar
Исходя из темпов развития jQuery и Mootools, ветку последнего можно депресировать :)
avatar
И можно, и нужно. Но у людей пока еще есть рабочие проекты на мутулзе, поэтому деваться некуда. Но дальгейшее развитие, конечно, только под jQ
avatar
в чем смысл лепить такие длинные цепочки? ведь не известно в каком порядке они выстроятся (плаги же могут быть в разном порядке, ведь так ?)
avatar
выше ответил уже — у меня генерация кода происходит сразу после активации плагина. Так что с одной стороны — порядок выстраивания плагинов учтен, с другой — генерируются описания только для активных плагинов.
avatar
в принципе согласен. Название, применение, аргументы почти не меняются при переопределении. К тому же я всегда переопределяю так? чтоб не запутаться, чего там передавалось в аргументах:

public function Method() {
	$args =  func_get_args();
	$result = call_user_func_array(array('parent',__FUNCTION__),$args);
        ...
}

Даже, если поменяется в исходной, то переопределение сработает в большинстве случаях.
avatar
Это палка о двух концах. С одного конца — лепим этот код и не задумываемся. С другого — переименование метода, изменение типа и/или числа аргументов, как правило, просто так от балды не делается. Поэтому можно упустить какие-то важные нюансы рефакторинга родительских классов.

По мне так пусть лучше ошибка вылезет из-за несовпадения имен методов или числа передаваемых параметров — исправить недолго, но зато я буду знать, что был рефакторинг, посмотреть, на что он может повлиять, и, возможно, свой код переписать под новые условия
avatar
так что виртуальный инхерит класс для автокомплита наследуем от оригинального первого класса
avatar
всё верно, это я предложил самый простой вариант для $this->Viewer_Assign без анализа цепочки
avatar
Спасибо
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.