alex_anderr

Вот ччерт. Значит я от него уходил и к нему пришел ) Чтож, значит использую его. А по таблицам все верно понял?

Выскажу свое мнение: 1. Сайт сильно черный. Как будто на Патайе кто-то умер. Да и черный с темно-темно серым на фоне второго совсем не видно многим у кого плохо настроены мониторы. 2. Фотографии лучше делать больше, т.к. с таким форматом атмосферу передать сложно. Как в контакте, даже хуже. Подписи к фото можно сделать на самом фото или под или над. Не так заметно. Кому надо - прочтут. 3. Play, Previos, Next, photo 1 of 13 = Слайдшоу, Предыдущая, Следующая, Фотография 1 из 13. 4. Оранжевый с белым и синим жуть как рябит на черном. Цвет текста хотя бы поменять. 5. !! - два восклицательных знака. 6. Стрелка nextpage не обязательна. Либо сделать прокрутку при наведении, либо в две строки фото. Во втором случае основное фото лучше делать сверху или сбоку, чтобы все не съезжало. Сейчас пользователь путается что делает эта стрелка. Вроде как должна к следующей фото, а не переходит. 7. Фиолетовый на черном. Подумайте над вариацией цвета. Пока рябит как ультрафиолет в клубе. Больше на сайте ничего нет, поэтому здесь критика заканчивается Воспринимайте меня как отзыв посетителя.

Довольно много прочитал про EAV, и довольно много минусов с ним в дальнейшем начиная от чудовищной производительсноти и закачивая тяжелыми запросами. Плюсы тоже есть. Поэтому и ищу нечто среднее. А почему нельзя пару "хар-ка - значение" писать в строку, а не в столбец? Ну будет в этом случае при 100 000 товаров число строк умноженное на количество характеристик, 20 например. Получается 2 млн строк, но при поиске по индексу проблем не должно возникнуть. Джойны меня не пугают, меня настораживает обслуживание. Все равно одной админкой сыт не будешь при сложных проектах. Еще раз: 1. Рубрика и подрубрика 2. Подподрубрика 3. Характеристики и значения 4. Товар (айди товара обязательно, айди пользователя обязательно, доп. характеристики обязательны). Думаю, что без этой таблицы я не обойдусь. 5. Пользователи. Это мой вывод из всех выше написанных сообщений. Вроде все верно. Единственное, что можно убрать таблицу 2, но мне с ней пока что удобней ) Итого 4-5 таблиц, не меньше. Все так?

Я логотипами уже 6 лет занимаюсь, такого наслушался. Я теперь много где вижу жопы, писюны и ядерные грибы вместо деревьев Мышку же можно и не по фрейду нарисовать. Если хотя бы 10% людей видят это, то это это и будет, вопрос времени ))

Второй. Только писюн слева уберите. Не люблю блоги с писюнами, и никто не любит ) Не надо бояться делать лого без "картинки". Можно обойтись типографикой и узнаваемыми элементами страниц.

Файл лежит в папке images и не лежит в images/adverts/8 )

1 и 2 уже поздно ) Но в переделках учту. 4 и 5 задумывалось, что характеристики для нормализации будут уникальными значениями (У различных товаров есть, например, ширина). Но запросы оказались довольно жесткими для восприятия, поэтому вариант объединения вполне адекватный. А в товарную планировалось добавлять минимум: номер товара, номер пользователя его добавившего, и доп. пару столбцов вроде показа/скрытия товара с общих результатов поиска пользователем сайта.

А еще можно вопрос? Как лучше делать таблицу с товарами (последнюю №7)? Как правильней может быть? Вариант раз: вбивать в нее всю информацию из остальных таблиц. В этом случае будет огромная таблица со всеми видами товаров. И запросы для вывода будут по полям этой таблицы. Вариант два: Вбивать в эту таблицу данные первичных ключей из остальных таблиц. Здесь, как я представляю, запросы для вывода товаров будут сложней, но не будет лишних "дублирующихся" значений.

Да, этот момент тоже оценил. Вариант change предпочтительней в моем случаев.

Это убирает пару лишних строчек и одну функцию из кода. И за это спасибо.

Круто. Думал конечно, что иначе будет работать, но получается, что для того чтобы выбрать селект на него нужно кликнуть.

А если у меня данный select тоже подгружается аяксом, то dom его уже не видит. Вроде исправляется «.live», но ни в одной из части функций «.live» не работает.

Благодарю. Простенькая ошибочка была.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Untitled Document</title> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script> <script type="text/javascript"> $(document).ready() { $('#test').change(function() { switch($(this).val()) { case '1': $('#rubric3').html('Эмулируем аякс'); break; case '2': $('#rubric4').html('Эмулируем аякс'); break; default: break; } }); } </script> </head> <body> <select id="test"> <option value="#">Выберите раздел</option> <option value="1">One</option> <option value="2">Two</option> </select> <div id="rubric3">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum</div> <div id="rubric4">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum</div> </body> </html> В Фиддл работает. Локально нет. Странно или туплю?

Да, именно этот простой пример. Не совсем понимаю как, какие функции писать и их наследования. Изучаю, но стало понятней. Спасибо, то что нужно.

В хтмл: <select id="test" onchange="selectChanged(this.value);"> <option value="#">Выберите раздел</option> <option value="1">One</option> <option value="2">Two</option> </select> JavaScript $(document).ready(function(){ function selectChanged(value) { switch(value) { case 1: func1(); break; case 2: func2(); break } } }); Хочу вставить функцию "замены дива" на jquery аяксе в func1() $("#test").val('1', function() { $("#rubric3").empty(); $("#rubric4").empty().load("rubric_4step.php #last2"); }); Все осложняется тем, что selectChanged не работает. Да и как вставить функцию в case пока дается тоже с трудом В JS силен меньше всего, спасибо за помощь. Случай средней тяжести, т.к. приходится учиться быстро. С радостью приму любые ссылки, если не ответы.

реляц? в одной таблице? окай понял, спс. 1. Точно не будет. Это наименование товаров. А их сколь угодно много. 2. Мне тоже не очевидно пока А в каком виде лучше? EAV из поста выше? 3. Для каждого товара свой набор характеристик, а значит таблица будет сложнее для восприятия и опять же ссылается на себя. Возможно, но по мне не очень удобно. 5. Ввод-вывод подумал что может понадобится для сортировки и всяких пользовательских примочек. Но уже думаю, что все запросы строятся и без нее. Это мышление новичка в бд, что поделать... -- Почитал про EAV. Проблем выходит больше чем плюсов. Мой вариант сильно плох как аналог? -- Еще UPD: Я не совсем корректно объяснил свое представление таблиц. Таблица 3 будет как раз подподрубрикой.(рубрика "мобильная связь", подрубрика "смартфоны", подподрубрика "Андроид", например) И получается для того чтобы вывести запрос мне нужно будет обратится ко всем таблицам сразу. Или же создать как раз таблицу 7, для того чтобы храинть ключи со всех таблиц в одном месте и при запросе обращаться к одной таблице. Скажите где я не прав?

Всем привет. На сайте есть рубрики, у них есть подрубрики, у них есть товары, у товаров есть характеристики, у характеристики есть значения характеристик. Есть таблица пользователей, которые "управляют" этими товарами. Как лучше организовать структуру? И где могут возникнуть проблемы в дальнейшем? В моем представлении так. Таблицы: 1. Рубрика (id, name) 2. Подрубрика (id, name, fk_рубрика_id) 3. Товары (id, name, fk_подрубрика_id) 4. Характеристики (id, name, fk_товары_id) 5. Значения характеристик (id, name, fk_характеристики_id) 6. Пользователи (id, login, pass) 7. Таблица вывода товаров (id, fk_значения характеристик_id * кол-во характеристик, fk_пользователи_id) Здесь fk - foreign key, _блабла_ - на какую таблицу ссылка, id - на первичный ключ этой таблицы Получается что в этой пирамиде последняя таблица вырастет в геометрической прогрессии. Не лучше ли таблицу 7 разделить на кучку таблиц по количеству подрубрик? (их будет совсем немного). Спасибо, ребят

css3 знаю, но нет, может году в 2015 ) можно дивами сделать, но опять же динамика все портит ( -- UPD: Ладно, ребята, отбой. Решили делать вручную, но если кому интересно, то можно попробовать найти решение

Здрасте. Интересует верстка текста в три колонки на css. И возможно ли на css? И потребуется ли JS? Есть динамическая страница в которую периодически добавляются данные. Данные берутся из бд и вставляются в теги списков ul li. Можно ли сделать верстку как на картинке, чтобы при добавлении новых списков все сдвигалось по стрелкам? Понимаю, что требуется определенная высота блока в котором находятся эти списки, понимаю что для каждого списка нужно назначать float, но ес-но до конца добить не могу Пример можно глянуть здесь: ib-gallery.ru (по нажатию на "производители"). Один большой список возможен, но не желателен. Спасибо

А вот это уже хорошее решение. Пусть удаляются просроченные хэши при заходе на страницу.

Поверь, с практикой не лучше. Но понимать потихоньку надо по долгу службы Хотя я себе так и представлял, но лучше по безопасности уточнить. Для решения этой задачи можно сделать порно сайт Я ж к примеру. А вдруг что если, а что делать если так.. Вроде того. Спасибо. Второй раз помогаешь.

1. А сама страница с формой смены пароля доступна или она доступна по кукам должна быть только, которые выдаются после проверки? Ведь ничего же не мешает зайти на страницу /lostpass/formasmenyparolya.php и там сменить пароль. Хотя если данные проверяются на прошлой странице, то в этой форме будет доступно только поле "новый пароль", но что мешает на основе проверки формы сделать гетзапрос на эту страницу и автоматически подставить любое мыло. 2. Лучше конечно не ручками, знач будем писать дополнительную процедуру обслуживания. А если пользователей несколько тыщ, и половина вдруг забудет пароли каждую вторую неделю месяца. Нене, к черту. Весь мир переходит на автоматическую коробку передач. 3. Так я про подтверждение и говорю. Что без него никак. Иначе просто заспамят сайт и/или наступит интернет анархия на твоем портале.

То есть перейдя по ссылке на форму смены пароля и не выполнив условия форма должна послать его подальше еще раз пройти всю процедуру? То что он хранится определенное время и хотел узнать. Только time() же не удалит хэш из БД. Значит нужна простенькая функция с sql запросом на удаление его через некоторе время? Выслать новый пароль проще всего, но его тоже надо подтвердить. Так как человек может при вводе мыла ошибится и сменить пароль не себе И здесь, опять же, возвращаемся к истоку.

Здрасте. Хотел уточнить по технологии восстановления пароля. Я представляю его так. (В моей БД почта=логину) Итак: 1. вводишь свою почту в форму восстановления пароля. жмем сабмит (/lostpass/index.php) 2. скрипт проверяет если почта есть, то генерирует и отправляет письмо на твою введенную почту 3. данный скрипт генерирует код подстверждения и записывает его в БД в строку с указанным юзером (электропочтой) 4. в письме код подтверждения и почта. А также ссылка в которой хранится код подтверждения и почта соответственно (для удобства, например, http://mysite.ru/lostpass/lostpass.php?hash=9kzhrz3b34sb&md5&email=bububu@bu.ru) 5. на странице по ссылке проверяются данные кода подтверждения и почты и в случае совпадения идет переадресация на форму ввода нового пароля.(/lostpass/newpassword.php) 6. пользователь вводит новый пароль, подтверждает его и он шифруется и записывается в БД. Вопросы: 1. Каждый может, по идее, войти на страницу ввода нового пароля и сменить его не затрагивая всю процедуру? (/lostpass/lostpassword.php) 2. И если каждый пользователь хотя бы по разу "восстановит" свой пароль, то в БД в таблице пользователей будут как раз эти коды подтверждения, по которым злоумышленник запросто сменит пароли у нужных ему пользователей если БД попадет к нему в руки. Так? Или код подтверждения (хэш) тоже шифровать с солью пару раз? Спасибо за ответы.