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

4
Livestreet & Yii
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
  • +7
  • 03 декабря 2011, 07:57
  • 1d10t

Комментарии (40)

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

ЗЫ
Класс называть Object не самая лучшая идея была, учитывая что есть PHPшный class Object
0
ре-зы. а еще он почему-то декларирован как абстрактный в engine/classes/Object.class.php
как так? почему фатал не появляется?
0
а с чего бы ему быть?
освежите теорию
0
ок
0
вроде такая же ситуация?
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
0
В PhpStrom вот так работает «Autopopup documentation feature» blog.jetbrains.com/webide/2010/07/autopopup-documentation-feature/

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

Только надо иметь пых на локальном компе.
У меня как раз он на удаленном в сети, и чего-то не получилось.
0
у меня в PATH прописана папка в бинарником php.exe, так что запускается из любой папки в консоли. часто юзаю php в cli-режиме даже под виндами
0
принцип тот же — создать список возможных Inherit классов и унаследовать их от Object
+2
А правильно ли от 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(). Да и не придумал я еще, как это лучше сделать.
0
та как не делай, при добавлении нового плагина надо перегенеривать.
Никто не знает, эклипсу можно ли написать паттерн, по которому бы он отслеживал автолоад и не матерился на Plugin_Module_Method?
0
Хех, так у меня как раз при активации нового плагина и происходит перегенерация цепочек. Так что «все учтено могучим ураганом» ;)
0
Это кстати на уровне ЛС реализовано, на методе Activate() висит обработчик?
0
Я ж ведь со своей админкой все, как с писаной торбой :) Она частично заменяет ядро движка. И у меня там активация/деактивация плагинов через свои методы идет
0
ждем API админки. А то вот у меня управление в плагине доп характеристик топика через экшен Admin идёт. Юзер себе поставит админпанель, а она ведь перезатрет этот экшен.
Надо хоть какую-то совместимость предусмотреть :).
0
Начал уже это делать, но переход на 0.5 с поддержкой двух разных js-библиотек занял в разы больше времени, чем планировал. Щас устаканится чуток — доделаю
0
Исходя из темпов развития jQuery и Mootools, ветку последнего можно депресировать :)
0
И можно, и нужно. Но у людей пока еще есть рабочие проекты на мутулзе, поэтому деваться некуда. Но дальгейшее развитие, конечно, только под jQ
0
в чем смысл лепить такие длинные цепочки? ведь не известно в каком порядке они выстроятся (плаги же могут быть в разном порядке, ведь так ?)
0
выше ответил уже — у меня генерация кода происходит сразу после активации плагина. Так что с одной стороны — порядок выстраивания плагинов учтен, с другой — генерируются описания только для активных плагинов.
0
в принципе согласен. Название, применение, аргументы почти не меняются при переопределении. К тому же я всегда переопределяю так? чтоб не запутаться, чего там передавалось в аргументах:

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

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

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