swetlana

а такое бывает вообще?

создатели сайтов разный смысл извлекают. Пионеры полагают, что это очень просто, и ввязываются. мудрые и терпеливые, умеющие общаться с заказчиками, берутся и объясняют заказчику, что именно ему нужно. жертвы по убеждениям ввязываются и потом жалуются на заказчика, который «задолбал своими придирками». я просто стараюсь обходить стороной такие задачи. По крайней мере не браться за них. Поскольку «точно такой же» — это неизвестно что, которое пришлось бы оценивать по неизвестно каким критериям. Был опыт.

если вам известно, что нужно, то не надо ставить задачи как «сделать точно такой же».

иногда больше смысла взять на себя полную переделку всего независимо от того, что хочет клиент. Не клиенту же в этом разбираться.

если бы речь шла хотя бы о 50 млн. рублей… тогд можно было бы говорить о создании точно такого же.

да ладно, не привязались. У каждого своя система ценностей. Можно один раз предложить улучшить ситуацию, но если это предложение неактуально с точки зрения личной системы ценностей, то действительно привязываться не стоит.

Я знаю вариант только пройтись по корзине и просуммировать. Для того есть CSaleBasket::GetList. Но есть и более простая в использовании, но недокументированная функция GetBasketList(). Использовать так: $arBasket = GetBasketList(); $arResult["TOTALPRICE"] = 0; foreach($arBasket as $arBasketItem) { $arResult["TOTALPRICE"] += $arBasketItem["PRICE"] * $arBasketItem["QUANTITY"]; } но на свой страх и риск. Бонусный счёт же — исключительно штатная возможность, здесь методы работы с ним.

шаблон лежит в /bitrix/templates/<id_шаблона>/. и там есть файлы header.php и footer.php. Соответственно — код html до основного содержания страницы и после оного. Вот туда и надо ставить.

ага. И программиста тоже. К программисту только требования попроще: крепкое понимание MVC и умение читать документацию. Ах да, ещё обязательное требование: ленивость. А пусть это не смущает. html5+css3 — это мой выбор, для себя. А заказчику-то как правило плевать с высокой колокольни на все эти стандарты и спеки. Главное — чтобы результат был. А результат может быть достигнут как при помощи html5+css3, так и при помощи html3.2. И в нашем стандарте качества ничего нет о применяемой спеке. Гораздо важнее некоторые другие параметры в вёрстке. Например, её ориентированность на интеграцию с CMS. нужен. нам. Но только при том условии, что есть искреннее желание поработать над своей неуверенностью, и перевести её в состояние уверенности

FF4, Safari5, Opera11, Chrome11. Вообще, конечно, удивительно, как так получилось сделать настолько отлично в сафари и хроме. у меня в подписи ответ есть.

попробую и я дать объявление. А вдруг что выйдет из этого? Итак… Молодой, развивающейся веб-студии требуется на удаленную работу web – верстальщик. На сегодняшний момент 1 - 2 4—5 проектов в месяц. Оплата договорная, за каждый отдельный проект, в зависимости от сроков и сложности задачи. Мы заинтересованы в долгосрочном сотрудничестве, если Вы хорошо себя покажете. Веб-технологии: Уверенные знания HTML5, CSS3, Javascript, иметь представление о Frameworks JQuery или Mootools, умение при необходимости делать кроссбраузерную верстку ( знание особенностей работы IE 6.0 и IE 7.0 ), валидная верстка. Было бы прекрасно, если бы Вы имели опыт работы с CMS Joomla, Bitrix или Drupal. Графика: Минимально необходимые знания по Photoshop для работы с готовым порезанным макетом. Знать, чем отличаются графические форматы PNG, JPEG, GIF и когда лучше использовать тот или иной формат. Находить общий язык с дизайнером Обязательные требования: Место проживание Москва или ближайшее Подмосковье; Собеседование и выполнение тестовых заданий; Умение оценивать сроки выполнения поставленной задачи и главное укладываться в эти сроки. Желательно наличие портфолио. Наши координаты: Ждем Ваших предложений и портфолио на resume@allin-studio.ru где-то здесь. Можно в личку писать. Или в профиле контакты. может именно так правильно искать специалистов?

желаний более чем достаточно, знания кое-какие тоже есть, но, как показывает практика, навыков маловато. Так что будем учиться. В том числе и у вас. Спасибо.

Вам вот эту страничку надо сверстать так, чтобы стало возможно прочитать, что там написано?

да, Рус, в курсе. И тебе спасибо

4 моих зарплаты госслужащего ничего себе! А как насчёт улучшить своё материальное положение?

торовый каталог всё же чаще импортируется как XML. А здесь понимание будет затруднено, если не знать, что такое инфоблоки, и как их готовить. У каждого элемента инфоблока есть ID — уникальный идентификатор. Он имеет значение только внутри самого сайта. XML_ID же — внешний код, на который ориентируются системы импорта/экспорта. В частности, при выгрузке торгового каталога из 1С товары узнаются именно по этому коду. Вообще, инфоблок — это нечто вроде таблицы в базе данных. Элемент инфоблока — это как запись в такой таблице. Существенное отличие лишь в том, что инфоблок может иметь древовидную структуру разделов. У каждого элемента есть предопределённые свойства, такие как ID, название, дата начала и окончания активности, символьный код, и могут задаваться произвольные. Вот в приведённом перечне описаны предопределённые свойства: NAME — название. Тут должно быть всё понятно. ACTIVE — активность. Это просто флажок. На него ориентируются каталоги или ленты новостей, принимая решение, показывать ли данный элемент или нет. Если флажок активности снят, то этот элемент также не участвует в поиске. ACTIVE_FROM, ACTIVE_TO — активность может устанавливаться и по времени. PREVIEW_PICTURE, PREVIEW_TEXT, PREVIEW_TEXT_TYPE, DETAIL_PICTURE, DETAIL_TEXT, DETAIL_TEXT_TYPE — эти поля ориентированы на традиционное представление каталогов и лент новостей. То есть, имеется список, в котором маленькая картинка и краткий текст, и у каждого элемента есть своя собственная страница, на которой большая картинка и развёрнутый текст. Текст может быть plain или html, это указывается в полях PREVIEW_TEXT_TYPE и DETAIL_TEXT_TYPE. CODE — мнемонический код. Ещё встречается такое название как «символьный код». Чаще всего используется для построения URL в чпу. GROUP0, GROUP1, GROUP2 — может быть и GROUP60 и GROUP76587659765, теориетически вложенность не ограничена, ограничивается лишь соображениями здравого смысла. Это привязка к разделам. В этих полях указываются ID разделов, в которые нужно поместить элемент при импорте. PROP50 — странная запись. Может всё же PROPERTY_50? Откуда вообще информация? Пользовательские свойства традиционно указываются именно так: PROPERTY_код-или-номер-свойства.

вы меня, конечно, извините, но очень хотелось бы понять. Из представленных вариантов какой правильный?

править оформление в коде движка — последнее дело. Так делать нельзя ни при каких обстоятельствах.

В код компонента можно передать что угодно через параметры.

ну это не странные. Это маргины того ul'а, которые в одном из блоков обитают.

не всегда. Бывают случаи… У меня однажды было. И специально ещё предупредил посредник, что цену надо называть повыше. Но у меня не хватило фантазии на такую цифру тогда. Надо было сделать визитку из трёх страниц с посредственным дизайном. Моей наглости хватило назвать 50 т.р. А тому человеку, который мне привёл этого заказчика, потом от него влетело: «что ты мне всяких быдлокодеров сватаешь? Разве можно мой суперпуперсайт сделать дешевле, чем за 100т.р.?». Заказали потом за 180. Даже обидно и досадно не было. Настолько было удивительно.

вообще да, возникает вопрос: что же за спец такой, что у него заказов не будет? но и сотрудник в офисе не застрахован от того, что в один прекрасный день он не придёт к закрытым дверям или не будет уволен только из-за того, что у шефа плохое настроение. Так что отдельно этот пункт действительно видимо не стоит рассматривать.

это не заказчика должно заботить, а самого фрилансера. Заказика заботит общая цена — это естественно. И качество работ, конечно же. Просто при формировании общей цены фрилансер должен включить всё, чтобы иметь возможность заниматься работой, а не сидеть перед экраном, схватившись за голову в попытках сосредоточиться, держа одну руку на клавиатуре, а второй постоянно сбрасывая названивающих кредиторов.

У верстальщика? хм… В теории-то это, конечно, возможно…

rus, а потому что неправильно. У этого метода несколько неожиданное поведение: он не возвращает никакого результата. И потому if($APPLICATION->ShowTitle(false)) не имеет никакого смысла. С таким же успехом можно написать if(false). Тут суть вот в чём: заголовок выводится в начале страницы, но определён он может быть при этом где-нибудь в середине, то есть позже. Как вывести раньше то, что определено позже? Правильно, буферизация в помощь. Метод SetTitle() устанавливает заголовок. Затем обрабатывается буфер, и в то место, где встречается вызов ShowTitle(), подставляется значение, установленное SetTitle(). То есть, проверять установленность заголовка этой функциоей нельзя. Она не для того. Есть ещё GetTitle() — с его помощью можно проверять. Но в данном случае тоже неприемлемо, ибо заголовок ещё не задан. Вообще, не до конца понимаю, почему отложенные функции работают именно так, а не иначе. В этом определённое неудобство есть для разработки. В своё время, когда у меня была подобная задача, решилось написанием такого компонента: <? global $my_title; $my_title = false; function myShowTitle($t="title"){ global $APPLICATION; echo $APPLICATION->AddBufferContent("myGetTitle"); } function mySetTitle($t){ global $my_title; if(strlen(trim($t))>0) { $my_title = "<h1>".$t."</h1>"; } else { $my_title = $t; } } function myGetTitle(){ global $my_title; if($my_title === false) { global $APPLICATION; $my_title = "<h1>".$APPLICATION->GetTitle()."</h1>"; } return $my_title; } $this->IncludeComponentTemplate(); ?> Чую, что криво. Но работает исправно. Если кто обругает мой вариант и предложит более правильный — заранее спасибо.