14 июля 2010 в 8:40
при создании вакансии есть связь с компанией и на странице вакансии есть ссылка на страницу компании
как вывести на странице компании все ее вакансии?
на странице компании вывести в блок только ее вакансии
Главные вкладки
14 июля 2010 в 8:40
Комментарии
switch ($op) {
case 'view':
if ( ($masters_ref = _ref_get_settings($node->type)) && !$teaser && $page) {
foreach($masters_ref as $slave_type => $ref_set){
$items = _ref_get_slave_nodes($node, $slave_type, $ref_set);
if($items){
drupal_add_css(drupal_get_path('module', 'my_module') . '/my_module.css');
$node->content["ref_salve_nodes_{$slave_type}"] = array(
'#type'=>'item',
'#value' => theme('item_list', $items, variable_get("ref_{$slave_type}_ntitle", node_get_types('name', $slave_type)), 'ul', array('id' => "ref-{$slave_type}", 'class'=>'ref-item-list')),
'#weight' => 101,
);
}
}
}
break;
}
}
function _ref_get_slave_nodes($node, $slave_type, $ref_set){
$sql = "SELECT * FROM {node} n
INNER JOIN {content_type_".$slave_type."} cts ON n.vid = cts.vid
WHERE n.status = 1
AND n.type = '%s'
AND cts." . $ref_set['nodereference_field_name'] . "_nid = %d
";
$result = db_query($sql, $slave_type, $node->nid);
while($slave_node = db_fetch_object($result)){
$items[] = node_view(node_load($slave_node->nid),TRUE,FALSE,FALSE);
}
return $items;
}
$ref_set не привожу у Вас может быть другая.
Если не хотите "париться" + добавление ссылки на создание подчиненного. Бери attach.
Вьюсами без всякого кодирования делается за 10-15 минут.
Ух ты, а можно views' ами сделать фильтр (expose) по таксономии чтобы в список выпадали только термины по которым есть материалы ?
Если немножко пошаманить на шаблоне вьюхи, то можно.
моветон
Я не понимаю Вашего сарказма, или Вы хотите доказать мне что-то чего я не знаю?
views хороший модуль но, не является "панацеей", наряду с «+» у него есть «ограничения» и «-». И если Вы уже пишите время на решение задачи и инструмент, то и напишите хотя бы словесно топикстартеру как ему настроить, если не хотите экспорт примера из views делать.
Drupal классная CMS, но ... "но, не является "панацеей", наряду с «+» у него есть «ограничения» и «-»". Так можно сказать про все.
А в реалии тесты показывают, что самописы в среднем (без своего кеша) быстрее вьюсов с отключенным кешом всего на 0,2 секунды а с включенным кешом для вьюсов проигрывает порядка 0,3сек. (тестировалось на достаточно посещаемом ресурсе, порядка 40.000 уников в сутки)
А теперь внимание вопрос за каким боком изобретать второй велик? Тем более что по расширяемости и гибкости + дальнейшая поддержка и обновление самопис проигрывает этой "панацее".
Теперь по поводу напишите, и экспортов примера. Литературы и скринкастов по этой теме более чем достаточно, а решать задачу и моделировать ситуации за кого-то у меня к сожалению нет времени.
Я лишь могу показать направление куда идти и в какую сторону смотреть или копать, а дальше все в руках топикстартера.
вот кстати данная тема интересна.
а есть статьи по этому поводу? или еще не писались?
Лично мной не писались
Я только принимал участие в таком тестировании, это было вызвано производственной необходимостью.
Программист заказчика с пеной у рта доказывал преимущество своего велосипеда перед вьюсами (новостной ресурс), а когда там установили вьюсы и простые манагеры получили в свои руки конструктор для собирания различных блоков страниц и рсс лент (причем что очень немаловажно без всяческого лазания в код своего самописа по любому чиху), + заказчику были отданы и показаны результаты тестов скорости, то программеру пришлось эту пену вытереть и просто заняться изучением материально технической части модуля вьюс
В любом проекте я всегда использую 100% 2 модуля ССК + Views в настоящий момент нет связки мощнее и гибче.
Лично у меня тормозило иногда намного больше.
Ссылку на тесты в студию !
Это не велик а решение !
Солгласен - я если нет конкретики например, либо пишу направление на модуль, либо на скриншоты.
А У Вас только направление, смутило -
Значит делали ?
Про это написано не мало, но не все решит views - задачу с которой он не справляется я привел в вопросе вначале к Вам - например фильтры по таксономии не строятся исходя из их использования в материалах - а все в случае пустого результата не всегда хорошо и удобно. То, что Вы предлагаете это сделать
Выходит за принцип разделения данных и шаблонов, которых придерживается http://drupal.org/coding-standards
1. Не надо использовать при большом количестве контента тип отображения вьюсов которые выполняют node_load филдовые вьюхи выгребаются и рендерятся гораздо быстрее.
2. Вьюсы в отличии от самописа кешируются что дает огромный прирост производительности при высокой посещаемости.
3. Это не решение а велик причем уже сделанный до Вас и не раз опробованный и проверенный.
4. Завтра к выводу вакансий захотят добавить фильтр по дате к примеру актуальные на сегодня или добавленные сегодня и Вы полезете править в код, а я зайду в админку и за 2 минуты добавлю фильтр по дате создания и нажму кнопочку сохранить. А если надо будет потом и календарик прицеплю чтоб по датам аяксом подгружались вакансии причем сделаю это за 10-15 минут а Вы на написание такого функционала убьете минимум полтора часа времени.
5. 10-15 минут не означает что я делал. Я просто знаю что надо нажимать и какие причинно следственный связи выставлять в настройках вьюсов и знаю что сделаю такую вьюху за 10-15 минут.
6. Я не говорил что функционал по сортировке терминов таксономии надо писать именно в шаблон напишите его отдельно а на шаблоне вызовите данную функцию, еще для этого есть препроцесс, еще для этого есть форм альтер. Было бы желание, кстати на форм альтере это сделать будет правильнее чем на шаблоне.
7. Я утверждаю (сугубо мое личное мнение) что с помощью вьюсов темизации и рук можно решить любую задачу по отображению контента на сайте.
Жалко ссылку не написал на тестирование производительности views. Ничего личного я и сам views использую только IMHO по теме, а не для