Veseloff
Moderator-
Posts
3,457 -
Joined
-
Last visited
-
Days Won
40
Content Type
Profiles
Forums
Calendar
Store
Everything posted by Veseloff
-
Ну записывайте эту дату куда-нибудь, а потом выдавайте. Вроде просто всё.
-
В ассоциотивном массиве $_SESSION не существует элемента с ключом «sess_type». Чтобы проверить существование необходимо использовать функцию isset
-
Я вот что про это всё думаю. Я всегда крошки делаю так <div id="crumbs"> <a href="/">Mainpage</a> » <a href="/catalog/">Catalog</a> » <a href="/catalog/somecat/">Somecat</a> » <a href="/catalog/somecat/somegood">Somegood</a> </div> id у дива потому что я считаю, что этот блок должен быть единственным на странице. Хотя никто не мешает заменить id на class. Кроме ссылок и знака-разделителя внутри ничего не бывает, поэтому стилизацию разделителей делать можно в «#crumbs», а стилизацию ссылок в «#crumbs a». Если тут будут списки, то добавится собственно элементов (ul, li...) и стили станут немного длиннее. Возможно, это повиляеят на скорость рендеринга, добавит «веса» странице, но это всё фигня, я считаю. Я бы не стал делал крошки списком, поскольку не вижу в этом никакого смысла.
-
Ну тогда я вижу два варианта: 1. Изучить PHP 2. Заплатить денег программисту, который это сделает
-
1. Да, так и надо делать — считаете время вы правильно. 2. Чтобы не писать для каждого события, может, стоит циклы использовать, не?
-
А что неудобного?
-
Насколько я помню, то кросдоменные запросы запрещены. Я как-то реализовывал кросдоменные запросы, но это был какой-то жуткий костыль навроде того, что в сайте подгружался «скрипт» вот таким образом <script type="text/javascript" scr="http://example.com/somefile_someparams.js"></script> На том сервере я раврайтил это хозяйство на php-скрипт, который выдавал нужный яваскрипт. А сделать обычные кросдоменные запросы через пост у меня так и не получилось.
-
Я вообще ни черта не понял чего надо. А ещё вам молчанка на три дня за мат.
-
Ну не совсем так. Я разрабатываю средство для быстрого создания сайтов своими руками. Пока я не планирую ничего распостранять, а у клиентов отрезаю функционал до миниума, чтобы не лезли своими шаловливыми ручками куда им не положено. Я разрабатываю скорее фреймворк, чем CMS.
-
Это всё понятно. Я просто хочу сделать так, чтобы этим было удобно пользоваться. Может, я неправильно подхожу к задаче, но мне нужно сначала увидеть результат, чтобы понять чего я именно хочу, а только потом сформулировать техтребования.
-
Заполнение из экселя — не проблема, я это делаю. Задача стоит не в том, чтобы заполнять его из админки, а чтобы создать некий универсальный скрипт, который будет подходить для любого интернет-магазина с любыми товарами. То есть чтобы создать сайт надо было бы выполнить следующие действия: 1. Поставить собственно скрипты и создать БД. 2. Заполнить основную информацию о свойствах, их типы, возможные значения, категории, чтобы это смог сделать самый нубский нуб. 3. Сверстать шаблоны. 4. Запустить в жизнь. То есть один и тот же набор таблиц и шаблонов управления мог бы работать для любого магазина. Посмотрю «Битрикс» для начала, да.
-
В общем мне надо реализовать интернет-магазин. Хотя, скорее, не столько собственно интернет-магазин, сколько каталог товаров. Как реализовать программно — тут вопросов нет — придумаю. А вот как реализовать максимально удобный интерфейс — вот тут затык небольшой. Итак, что надо: 1. Можно добавлять категории. Должна быть вложенность, она может быть неограниченной. 2. Можно добавлять свойства для товаров. Эти свойства могут быть как «статичные», так и выбором из списка у конкретного товара при заказе. Свойства могут влять на цену, а так же могут меняться в зависимости от категории, к которым этот товар относится. 3. Можно добавлять собственно товары со всеми этими свойствами и категориями. 4. Всё это делается исключительно через «админку» — никакого залезания в код, БД и т.д. Есть ли что-нибудь среди готовых решений (CMS, просто какие-то скрипты), где это всё реализовано на самом высочайшем уровне, чтобы можно было скачать, установить и посмотреть? Ну или хотя бы попробовать в демо-версии. Буду очень признателен.
-
А вот и неправда. Я не знаю ни одной CMS и ни одного фреймворка, но сайты делаю быстро. Программист на PHP должен в первую очередь хорошо знать синтаксис PHP, а так же, как и любой другой программист, должен быть знаком с теорией алгоритмов и структур данных и уметь применять свои знания на практике. Ещё часто получается, что надо кроме этого надо уметь работать ещё и с СУБД.
-
192.168.1.24 — локальный IP и из внешней сети работать, само собой ничего не будет. Судя по данным хуиза DNS-сервера у вас находятся вот тут imena.com.ua — там, наверное, и надо править.
-
Клавиатура не та — мне с нампадом нужно и клавиши т.н. «островного типа». Ну, собстсвенно, видео я смотреть всё равно не буду, так что как-то пофиг
-
А что не так с турионами? Я вот себе такой девайс планирую — использоваться будет для работы — то есть только текстовый редактор и браузер. Выбрал из-за невысокой цены, матового экрана и отличной клавиатуры. Есть такие же с феномами и атлонами, но дороже, заразы. В чём я потеряю, если зажму денег и возьму его, а не такой же, только с феномом?
-
Не холивара ради, а интереса для. А почему не AMD? Я вот просто пользую феномы на десктопах и на серверах и, в принципе, всё устраивает. Ноут себе хочу с турионом прикупить. Они чем-то плохи или просто тут ситуация такая?
-
Ну поставьте XAMPP — может, он заработает?
-
Вот это написано у «Яндекса». Весьма неконкретно, к сожалению. А вот это у «Гугла». Не правда ли «имеет основную тему и подпункты, ее развивающие» означает единственность h1?
-
А при чём тут спецификация? Простой и здравой логики недостаточно? Ну вот, например, легковые автомобили делают с четырьмя колёсами. Колёс может быть сколько угодно, но все делают четыре и никакая спецификация не нужна. Так же и тут — есть какие-то нормы, негласные договорённости, логичные размышления. Пусть спецификация позволяет делать автомобиль с пятью колёсами, но делают-то все четыре
-
Ну логика такая у меня — ничего с ней не поделать. Вначале было слово, как говорится... Ну должно быть что-то одно, что объединяет всё остальное. И вот это что-то имеет название. И оно хранится в h1. Не вижу ничего нелогичного. Надо как-то человеку объяснить что на странице это происходит — вот для этого и нужен h1 — обобщающий, краткий, понятный. А то вот зашёл человек на страницу и видит заголовок «Пирожки с повидлом». «О! Страница о пирожках с повидлом!» — думает читатель и начинает читать. А тут внезапно «Пирожки с яйцом», а потом и вовсе «Пирожки с вермишелью». И вот теряется пользователь, не понимает о чём страница. А непонимания бы не возникло, если бы на странице был один всего заголовок «Разные пирожки», а всё остальное было бы второстепенными заголовками. Вот такое обоснование.
-
Считаю, что h1 должен быть один. Title не все замечают, а вот заголовок — видят. И он должен быть один. Я так думаю. И SEO не при чём. Надо больше заголовков — h2 к вашим услугам.
-
Это не textarea, а iframe с designMode.
-
А, понял. Ну тогда делаем картинке id="captcha" и на онклик document.getElementById('captcha').src='...';
-
this — сам элемент, то есть «a». А src надо менять у img. Так что ставьте onclick на img и будет вам счастье, пока не вылезет следуюший косяк, если сами не догадаетесь его исправить