Один из способов чуть-чуть автоматизировать процесс объединения — транслитерировать русские теги и прогонять их через soundex()/metaphone(), при совпадении результатов с латинскими тегами объединять.
На мой взгляд, отношение родитель-ребёнок здесь не совсем уместно. Теги должны быть равноправны, они же синонимы, а отношение родитель-ребёнок возможно в паре, скажем, «поисковик > google». Т.е. это на самом деле должно быть два разных вида связывания, которые должны работать в паре :)
За Гуглом будущее. Когда-нибудь мы будем работать на слабеньких терминалках с миниатюрной операционкой, вшитой в биос, но зато оснащённых терабитными каналами и весь софт будет подгружаться из Сети. А софтверные и хардверные компании сами виноваты, что не думают о будущем. Нельзя вечно жить принципами 90-х. Эта концепция устаревает и нужна новая. Гугл просто пока первый, кто поставил на web-based workplace.
я знаю :) я вообще не люблю подобные изыски. особенно в случае с бд — люблю, знаете ли, всегда явно указывать идентификатор соединения, чтобы не дай бог не выбрать что-нибудь из соседней базы :)
Наверное меня щас заминусуют, но... нафига? :) Хороший код должен работать без ошибок и исключений в продакшне. Т.е. фактически, ни перехват, ни оформление не нужны :)
>> Junior PHP Developer - восторженно изучает Smarty и еже с ними
>> PHP Developer - везде использует Smarty, но начинает что-то подозревать
>> Senior PHP Developer - пишет свой шаблонизатор, понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View
>> Lead Developer - не задумывается о таких мелочах
Фигасе о_О Это получается я сначала был Senior Dev'ом, потом по долгу службы пришлось быть Dev'ом, а теперь я Lead Dev? :) Фигасе, фигасе!
ЗЫ: Никогда не был восторжен Smarty, т.к. не видел смысла в дублировании функционала самого РНР надстройками (да ещё и вводя дополнительный язык разметки/программирования в проект). Получается никогда не был Junior'ом :)
эмм... я что-то упустил, или body { background-image: url('images/dev/maket.jpg') } является самым простым решением задачи? :) или не катит, потому что контенту надо будет задавать дополнительный контейнер? :)
ИИ - это не компьютер. ИИ - это программа. Компьютер - это "тело". А чувствовать может программа, если её научить. И не будет чувствовать, если не научить (как психи или маньяки, которые могут не испытывать чувств). А физическая боль требует рецепторов ("тело"), на которые программа должна будет реагировать ("боль"). у людей тоже есть расстройства, при которых они не чувствуют боли. Просто ИИ нужно моделировать с очень высокой точностью, которую пока не способны обеспечить современная психология и физиология :)
к вопросу об эстетичности и простоте восприятия верстальщиками смарти-тэгов :) на мой взгляд (а я сейчас в одном лице и программер, и верстальщик) такие конструкции уродливы.
А я делаю так:
1. у меня есть класс шаблонизатора, который по большому счёту состоит из одного метода и приватного свойства, в которое пишется кэш. Этот метод принимает на вход имя файла и массив и заменяет в HTML-шаблоне все <%переменная%> на значения массива с ключём "переменная".
2. В самом коде формируется этот массив.
3. Перед вызовом Parser::parse($skin, $values) достаточно проинклюдить соответствующий языковой файл и сделать $values = array_merge($LANG, $values)
В результате: код чист от представления, представление чисто от языко-зависимых данных, размер кода минимален, логика отделена от представления (нет всяческих богомерзких {section name=user_loop loop=$users})
Кроме РС и приставок есть ещё море всякого разного ;) Например, станции для 3д-моделлинга. И вообще, ГПУ хорошо считает флоаты, так что такая связка может быть полезна не только там, где дело касается графики, но и, например, в космических исследованиях, моделировании ядерных процессов, етс. Т.е. ГПУ - не только для развлечений нужен. То, что его сейчас позиционируют как синема 2.0 не значит, что он не будет использоваться для других целей.
Почему связка процессор+видеокарта - это прежде всего РС? :) Разве в других железках нет процессоров и видеочипов? (кстати, связка не процессора и видеокарты в статье упоминается, а процессора и видеочипа ;))
На мой взгляд, отношение родитель-ребёнок здесь не совсем уместно. Теги должны быть равноправны, они же синонимы, а отношение родитель-ребёнок возможно в паре, скажем, «поисковик > google». Т.е. это на самом деле должно быть два разных вида связывания, которые должны работать в паре :)
Вот как-то так.
mysql_connect().mysql_select_db().mysql_query() or die();
Только дурь это.
Нет. Тут тонкий семантический момент. Словарь в данном случае не источник информации, а образец. Как «переписал с монитора».
>> PHP Developer - везде использует Smarty, но начинает что-то подозревать
>> Senior PHP Developer - пишет свой шаблонизатор, понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View
>> Lead Developer - не задумывается о таких мелочах
Фигасе о_О Это получается я сначала был Senior Dev'ом, потом по долгу службы пришлось быть Dev'ом, а теперь я Lead Dev? :) Фигасе, фигасе!
ЗЫ: Никогда не был восторжен Smarty, т.к. не видел смысла в дублировании функционала самого РНР надстройками (да ещё и вводя дополнительный язык разметки/программирования в проект). Получается никогда не был Junior'ом :)
зы: статья мне понравилась, просто думаю над другими вариантами :)
или моральные проблемы создания искусственного интеллекта
{else}
{section name=field_loop loop=$fields}
<tr>
<td class='form1'>{$fields[field_loop].field_title}{if $fields[field_loop].field_required != 0}*{/if}</td>
<td class='form2'>
{if $fields[field_loop].field_id == 5}
<select name='field_{$fields[field_loop].field_id}' id='ajax_city' val='{$fields[field_loop].field_value}' style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 1}
<select name='field_{$fields[field_loop].field_id}' id='ajax_country' val='{$fields[field_loop].field_value}' onchange="loadInfo('#ajax_city', 'cities', '&country='+this.value, this)" style='width: 200px'></select>
{/if}
{if $fields[field_loop].field_id == 2}
<div><input type='text' class='text' name='field_2' value='{$fields[field_loop].field_value}' style='{$fields[2].field_style}' maxlength='{$fields[field_loop].field_maxlength}'></div>
<div class='form_desc'>{$fields[field_loop].field_desc}</div>
{/if}
</td>
</tr>
{/section}
{/if}
1. у меня есть класс шаблонизатора, который по большому счёту состоит из одного метода и приватного свойства, в которое пишется кэш. Этот метод принимает на вход имя файла и массив и заменяет в HTML-шаблоне все <%переменная%> на значения массива с ключём "переменная".
2. В самом коде формируется этот массив.
3. Перед вызовом Parser::parse($skin, $values) достаточно проинклюдить соответствующий языковой файл и сделать $values = array_merge($LANG, $values)
В результате: код чист от представления, представление чисто от языко-зависимых данных, размер кода минимален, логика отделена от представления (нет всяческих богомерзких {section name=user_loop loop=$users})