ну, хаков у нас одинаково: адинадин. Ибо !important - тоже хак. Я имею ввиду то, что между ! и словом нужно пробел ставить, тогда его все браузеры воспринимают.
А у вашего варианта преимущество в отсутствии дополнительного дива "all" - это семантически правильно.
Хотя он меня не раз спасал ;)
мало того! зачем содержание - не понимаю. все-равно нужно будет нажать ctrl+F и искать по ключевому слову (ну, класс, айдишник, свет...).
Считаю достаточным разбивать все по группам + визуальные разделители между группами.
кстати, не известно что еще будет лучше: использовать document.write или eval(содержимое_с_ajax_запроса_нужного_файла).
Может есть еще какой-то способ? Так, на вскидку не вспомню
чтобы не встретиться с уже известными проблемами нужно посмотреть какие проблемы уже известны :) Это считаю неотъемлемой частью разработки чего-либо (в т.ч. плагина).
А дольше-не дольше это как посмотреть.
Допустим:
* «x1» время, затраченное на изучение существующего плагина;
* «y1» время на исправление найденных ошибок;
* «z1» время на добавление необходимой функциональности в плагин (или удаление ненужной функциональности);
* «x2» время на «посмотреть что уже написали до меня»;
* «y2» время на разработку плагина;
* внедрением плагина в проект пренебрегаю;
* считаю, что в мануал по написанию плагина я знаю, как свои пять;
Очевидно что:
x1 = x2;
Т.е. задача состоит в определении того, что будет рациональней: использовать чужое с вытекающими от сюда последствиями (две ключевых составляющих), или писать свое (одна составляющая).
Так вот: если вам нужен плагин сейчас и сиюминутно, ибо завтра утром проект сдавать, то писать свой плагин нет смысла:
y1 + z1 < y2
А вот если эту функциональность нужно использовать в _надцати следующих проектах, то:
y1 + z1 < y2
Знал ли ты про «baseClass»-параметр в schema.yml?
...
model_name:
_attributes: { phpName: ModelName, baseClass: i18nModelName }
...
Это позволяет «вклиниваться» между BaseObject и нашим классом, который генерируется при build-model. Я, например и не догадывался, пока мне носом не ткнули (решение зарыто глубоко в дебрях форума). ctrl+пробел спас бы ситуацию, подсказав возможные варианты названия параметра.
Так что «гадость эта ваша заливная рыба». А если не гадость, то вы ее еще не распробовали :) Просто не наступали вы еще на грабли.
Я например тоже в начале пришел в восторг от «простоты» yml. Сейчас понимаю, что лучше бы это были экземпляры php-класса sfConfig. Реализовали бы config-класс как положено: с интерфейсом и наследованием. И котролпробел работал бы и быстрее в кучу раз компилилось, (остальные преимущества додумайте).
Хотя (повторюсь) лучше Симфони я пока не видел. Увижу обязательно переквалифицируюсь ;)
Я в CSS-е тоже автокомплитом не пользуюсь вообще (редактирую в FARe). Вот только в CSS-е жестко структурированный набор ключей и значений. А тут для каждого плагина в app.yml свои ключи и набор значений. Это что-же получается мне в голове это все держать? Или каждый раз мануал к плагину перечитывать?
Или еще хуже: если плагин не документирован, или был писан тобою год назад. "Use the force, look the source, Luke."
только вот по контрол-пробелу он мне и в xml-е подсказывать не будет, ни в ini-структуре. Ибо обращение к параметрам происходит в любом месте кода (т.е. чтобы полностью и наверняка узнать какие параметры бывают нужно перечитать все исходники). Очень удобно.
если вы уже заговорили про удобство:
а в какой среде разработки вы пишите на Симфони? Я остановился на Zend Studio (Symfoclipse). Так вот: yml-файлы редактируются РУЧКАМИ! Мне нужно помнить все константы наизусть? Лучше бы PHP-объекты сделали. Тогда бы ctrl-пробел работал.
P.S. Я голосовал за Симфони (на данный момент пишу на нем).
С вами тяжело спорить, тем более что вы говорите все правильно (почти ;)
Задача стоит несколько по-другому. Нужно выбрать фреймворк, который не нужно дотачивать напильником, а писать c помощью него сайты.
Симфони (ядро) почти не вызывает претензий, но вот писанные для него плагины - это ужас. Поэтому нужно писать полностью свои (или переписывать). Проект нужно начинать уже сегодня, а у меня нет даже основных нормально работающих плагинов.
Вот в этом проблема Симфони.
тогда зачем же Симфони? Эфемерное качество за счет траты огромной кучи времени на на написание своих плагинов, переписывание admin generator, создание своих taskов.
Тогда уж проще свой фреймворк написать, глядя на «папок» (Симфони, Зенд и др.). Но, как вы понимаете, это не выход.
на работе мы используем UFO-фреймворк под названием «Фреймворк самописный для сайтов» )). Писанный на PHP4.
И свои задачи, надо сказать он выполняет весьма и весьма неплохо. Только проблема состоит в том, что он отстал от жизни. Там, AJAX всякий приходится через выхлопную трубу прикручивать, URL rewriting делается исключительно через htaccess, что такое плагин фреймворк наш не знает.
Вот и пришлось доганять технологии посредством выбора другого фреймворка. Остановились на symfony, и как показала практика, разрабатывать приложения на нем получается не так уж и быстрее (по сравнению с «UFO»), хотя симфони позволяет делать более «продвинутые» по технологии задачи.
а как на счет admin generator и i18n? по-дурацки там сделана генерация таблиц с мультиязычными столбцами. Нужно потом самому напильником дотачивать.
попробуй в плагине sfPropelFileStorage файл с таким же самым именем зааплоадить. Такая же ситуация. Берешь напильник - и вперед.
Следом идут sfKsnNewsPlugin и много других, которые тот самый sfPropelFileStorage используют в качестве обязательных. Тоже их нужно под самопереписный FileStorage прогибать-переписывать.
А этот "переводчик"? Все ли он фразы выдергивает из шаблонов? ответ: нет. приходится admin generator'ские фразы либо самому дописывать, либо "приседать" и переписывать "sfPakeI18n.php" из папочки "task" в библиотеке.
И говорят, что это лучший фреймворк на PHP5 - даже страшно...
(Cчитаю, что PHP4-фреймворки уже не конкурентноспособны - этому способствует сам язык PHP4)
Если не составит большого труда, объясни пожалуйста свой выбор.
У нас стал вопрос выбора фреймворка совсем не давно, когда окончательно поняли, что UFO-фреймворк не в состоянии конкурировать с вышеперечисленными (ну, и остальными тоже).
После долгих поисков symfony казался вкусным и с перламутровыми пуговицами.
Сейчас видим много недостатков этого фреймворка. Создается впечатление, что нужно "спрыгивать" с него и искать что-либо другое.
Может мы его не правильно готовим и поэтому он нам кажеться не таким вкусным?
тут как раз все понятно:
для IE6 - height: 100%;
для остальных: height: auto; min-height: 100%;
т.е. пользователь set не совсем правильно написал про "без хака".
А у вашего варианта преимущество в отсутствии дополнительного дива "all" - это семантически правильно.
Хотя он меня не раз спасал ;)
Считаю достаточным разбивать все по группам + визуальные разделители между группами.
document.writeилиeval(содержимое_с_ajax_запроса_нужного_файла).Может есть еще какой-то способ? Так, на вскидку не вспомню
CSS:
html, body {
height: 100%;
margin: 0;
padding: 0;
}
#all { /* all content must be wrap in <div id="all"></div> */
position: relative;
height: 100%;
min-height: 100%;
}
html>body #all {
height: auto;
}
#footer {
position: absolute;
left: 0;
bottom: 0;
width: 100%;
}
#footer, #empty {
height: 50px;
}
HTML:
<body>
<div id="all">
<div class="content">
Some content
</div>
<div id="empty"></div>
<div id="footer">
This is content of footer path
</div>
</div>
</body>
только нужно писать через пробел:
height: 100px ! important;
Может такая у вас есть по generator'у?
А дольше-не дольше это как посмотреть.
Допустим:
* «x1» время, затраченное на изучение существующего плагина;
* «y1» время на исправление найденных ошибок;
* «z1» время на добавление необходимой функциональности в плагин (или удаление ненужной функциональности);
* «x2» время на «посмотреть что уже написали до меня»;
* «y2» время на разработку плагина;
* внедрением плагина в проект пренебрегаю;
* считаю, что в мануал по написанию плагина я знаю, как свои пять;
Очевидно что:
x1 = x2;
Т.е. задача состоит в определении того, что будет рациональней: использовать чужое с вытекающими от сюда последствиями (две ключевых составляющих), или писать свое (одна составляющая).
Так вот: если вам нужен плагин сейчас и сиюминутно, ибо завтра утром проект сдавать, то писать свой плагин нет смысла:
y1 + z1 < y2
А вот если эту функциональность нужно использовать в _надцати следующих проектах, то:
y1 + z1 < y2
...
model_name:
_attributes: { phpName: ModelName, baseClass: i18nModelName }
...
Это позволяет «вклиниваться» между BaseObject и нашим классом, который генерируется при build-model. Я, например и не догадывался, пока мне носом не ткнули (решение зарыто глубоко в дебрях форума). ctrl+пробел спас бы ситуацию, подсказав возможные варианты названия параметра.
Так что «гадость эта ваша заливная рыба». А если не гадость, то вы ее еще не распробовали :) Просто не наступали вы еще на грабли.
Я например тоже в начале пришел в восторг от «простоты» yml. Сейчас понимаю, что лучше бы это были экземпляры php-класса sfConfig. Реализовали бы config-класс как положено: с интерфейсом и наследованием. И котролпробел работал бы и быстрее в кучу раз компилилось, (остальные преимущества додумайте).
Хотя (повторюсь) лучше Симфони я пока не видел. Увижу обязательно переквалифицируюсь ;)
Или еще хуже: если плагин не документирован, или был писан тобою год назад. "Use the force, look the source, Luke."
http://www.picamatic.com/show/2008/05/26…
Красивый раскрашиватор для YML - это клево:
http://www.picamatic.com/show/2008/05/26…
только вот по контрол-пробелу он мне и в xml-е подсказывать не будет, ни в ini-структуре. Ибо обращение к параметрам происходит в любом месте кода (т.е. чтобы полностью и наверняка узнать какие параметры бывают нужно перечитать все исходники). Очень удобно.
Я без автокомплишена не могу ;)
Лучше всего сесть и написать плагин самому. Тогда и грешить не на кого.
а в какой среде разработки вы пишите на Симфони? Я остановился на Zend Studio (Symfoclipse). Так вот: yml-файлы редактируются РУЧКАМИ! Мне нужно помнить все константы наизусть? Лучше бы PHP-объекты сделали. Тогда бы ctrl-пробел работал.
P.S. Я голосовал за Симфони (на данный момент пишу на нем).
Задача стоит несколько по-другому. Нужно выбрать фреймворк, который не нужно дотачивать напильником, а писать c помощью него сайты.
Симфони (ядро) почти не вызывает претензий, но вот писанные для него плагины - это ужас. Поэтому нужно писать полностью свои (или переписывать). Проект нужно начинать уже сегодня, а у меня нет даже основных нормально работающих плагинов.
Вот в этом проблема Симфони.
Тогда уж проще свой фреймворк написать, глядя на «папок» (Симфони, Зенд и др.). Но, как вы понимаете, это не выход.
И свои задачи, надо сказать он выполняет весьма и весьма неплохо. Только проблема состоит в том, что он отстал от жизни. Там, AJAX всякий приходится через выхлопную трубу прикручивать, URL rewriting делается исключительно через htaccess, что такое плагин фреймворк наш не знает.
Вот и пришлось доганять технологии посредством выбора другого фреймворка. Остановились на symfony, и как показала практика, разрабатывать приложения на нем получается не так уж и быстрее (по сравнению с «UFO»), хотя симфони позволяет делать более «продвинутые» по технологии задачи.
попробуй в плагине sfPropelFileStorage файл с таким же самым именем зааплоадить. Такая же ситуация. Берешь напильник - и вперед.
Следом идут sfKsnNewsPlugin и много других, которые тот самый sfPropelFileStorage используют в качестве обязательных. Тоже их нужно под самопереписный FileStorage прогибать-переписывать.
А этот "переводчик"? Все ли он фразы выдергивает из шаблонов? ответ: нет. приходится admin generator'ские фразы либо самому дописывать, либо "приседать" и переписывать "sfPakeI18n.php" из папочки "task" в библиотеке.
И говорят, что это лучший фреймворк на PHP5 - даже страшно...
(Cчитаю, что PHP4-фреймворки уже не конкурентноспособны - этому способствует сам язык PHP4)
У нас стал вопрос выбора фреймворка совсем не давно, когда окончательно поняли, что UFO-фреймворк не в состоянии конкурировать с вышеперечисленными (ну, и остальными тоже).
После долгих поисков symfony казался вкусным и с перламутровыми пуговицами.
Сейчас видим много недостатков этого фреймворка. Создается впечатление, что нужно "спрыгивать" с него и искать что-либо другое.
Может мы его не правильно готовим и поэтому он нам кажеться не таким вкусным?