> Какие фэйлы допускают молодые создатели е-магазинов с нуля?

вот такие:

Чужие движки использовать не желаю

> Какие технологии тем не менее лучше использовать, даже если пишешь с нуля?

spring, hibernate, ejb, jboss, ну и конечно же velocity.

> Какие ошибки следует избежать при создании вышеописанного?

нужно изначально делать упор на безопасность. XSS и прочее.

Какие технологии тем не менее лучше использовать, даже если пишешь с нуля?

Doctrine + какой-нить Kohana || Yii || DooPHP (Yii даже лучше). ну и при желании можно прикрутить к ним Smarty.

При чем здесь технологии для JAVA?
Донской северный или трололо?

> Какие фэйлы допускают молодые создатели е-магазинов с нуля?

никакая хакероустойчивость же

если будешь использовать своё решение, то и претензии все будут к тебе, а не к создателям движка магазина

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

если ты юзаешь чужой движок, то бережешь себе нервы и форму торца

претензии все будут к тебе

Полюбому все претензии к исполнителю.

>если ты юзаешь чужой движок, то бережешь себе нервы и форму торца

Не-а. Перед заказчиком всё равно ты отвечать будешь. Хотя бы за то, что «такое дерьмо порекомендовал». Другое дело, что популярные отработанные движки часто ряда детских болезней лишены. Но и, наоборот, наличие в них дырок ищется хакерами тщательнее и легче :)

> Перед заказчиком всё равно ты отвечать будешь. Хотя бы за то, что «такое дерьмо порекомендовал».

мы когда пилили «интернет-магазины», в договоре был пункт, пространно объясняющий, что заказчик понимает, что мы _интегрируем_ магазин, а не создаем его, поэтому а) к взломам магазина отношения не имеем вообще никакого б) стоимость сайта делится на три части: стоимость создания кастомного функционала, стоимость магазина, и стоимость интеграции нашего функционала с их магазином

>в договоре был пункт

Заказчики бывают разной степени вменяемости :) Но - да, если такое оговорено явно, то проблем меньше. Останется только потом убедить заказчика, что взлом произошёл именно в компонентах магазина, а не в частях адаптации :)

>При чем здесь технологии для JAVA?

Донской северный или трололо?

в первой версии поста не было ничего о php =)

юзай готовые свободные движки:

opencart, oscommerce

p.s. если сам хочешь писать, то я бы посоветовал фреймворк Ruby On Rails; правда в этом случае придется забыть php и учить ruby

В 13:59 уже было, а сообщение про Java - это 14:05 :)

man сарказм

man каламбур

>> Какие технологии тем не менее лучше использовать, даже если пишешь с нуля?

spring, hibernate, ejb, jboss, ну и конечно же velocity.

Достаточно spring и hibernate :-)

>> Какие фэйлы допускают молодые создатели е-магазинов с нуля?

вот такие:

Чужие движки использовать не желаю

ППКС.

>Какие технологии тем не менее лучше использовать, даже если пишешь с нуля?

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

Какие ошибки следует избежать при создании вышеописанного?

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

* Перегруженность интерфейса (prestashop, например, вгоняет в ужас даже опытного пользователя в первый раз). Желание сделать всё максимально настраиваемым через гуй - порочно. Всё равно половину вещей должен настраивать тот человек, который это всё понимает, и разумный минимализм очень нужен. А значит стоит делать для редко изменяемых вещей удобные текстовые конфиги.

* Дикие тормоза. Это проблема многих магазинов. Большинство проблем идёт от кривых рук (тут ничего не сделать) и от плохой архитектуры. Например для универсального магазина с разными товарами сложно обойтись без EAV-структуры в БД. А она может разрастись до жутких размеров, из-за тех же кривых рук (встречал по 80 строк на один товар с 10 свойствами). Тут на помощь могут придти NoSQL решения, но они тоже имеют свои особенности.

* Плохой API. Сколько не встречал «сверхуниверсальных» магазинов, заказчики вечно хотели того, что эти магазины даже с плагинами не могут. Приходится писать своё. И тут начинается ад, некоторые движки надо почти полностью переписывать, ибо какая-нибудь скидка забита в основном коде в самой глубине.

Или хуже того, например в прекрасной системе б*трикс надо было реализовать групповую наценку на кучу товаров. Вот скидку он может, отрицательную скидку - нет, а «наценка» у него только на один товар за раз ставится. И привет, пишем своё через кучу извращений, тратя кучу времени.

В идеале бы получить веб-фреймворк для магазина, который будет иметь часто необходимые вещи (дерево каталогов, товары с динамическими свойствами, API для экспорта во всякие яндекс-маркеты), но будет простым и быстрым, чтобы легко можно было дописать своё.

Чужие движки использовать не желаю

Движки одно дело, но лучше воспользоваться готовым фреймворком. От себя рекомендую Yii.

> никакая хакероустойчивость же

Для магазинов с небольшим количеством товаров можно порекомендовать все писать на js. Все что произойдет - будет на клиенте, в худшем случае XSS словит, на серверной стороне простая обертка над файловой системой/базой, дабы читать/сохранять значения, строк в 30 можно уложиться. Меньше кода - меньше места для ошибки.

Да, одно время я сильно фапал на сайты из 1 страницы, в том числе только из статики, правда до реализации мегавелосипеда дело так и не дошло.

> на серверной стороне простая обертка над файловой системой/базой, дабы читать/сохранять значения, строк в 30 можно уложиться.

так есть еще всякие электронные платежные системы и кредитные карточки... не всё ж наложенным платежом отправлять

> Достаточно spring и hibernate :-)

можно еще добавить пару щепоток GWT, для свистелок.

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

> Платежные системы как правило сами дают скрипты для установки, интегрировать зачастую можно копипастой. Я не считаю это программированием.

ты про хорошие платежные системы.

а у плохих вообще ничего нет, кроме сниппета на похапэ, который по их аффтаритетному мнению должен скорее работать, чем нет. И если упаси бох глянуть на код этого сниппета, то ВНЕЗАПНО оказывается, что все данные там передаются плейнтекстом, ошибки не обрабатываются, а при малейшем косяке все полимеры могут улететь к порнокорям с Ямайки.

у совсем плохих вообще нет никакого интерфейса для коммуникации, его надо придумывать за них.

> Платежные системы как правило сами дают скрипты для установки, интегрировать зачастую можно копипастой. Я не считаю это программированием.


расскажи мне больше. расскажи мне, как ты будет «интегрировать копипастой» какой-нить PayPal Express Checkout. ну или SagePay/HSBC. ну т.е. любой более-менее современный пеймент с callback и многоходовым выполнением транзакции. я уж не говорю про прикручивание 3D secure.

ах да. совсем забыл. про PCI DSS слышал? так вот, очень скоро PCI DSS сертификация будет обязательна для имплементации background пейментов в магазинах.

> какой-нить PayPal Express Checkout

у них вроде бы есть какое-то подобие недоSDK плюс доки, плюс в гугле можно чонить нарыть и откопипастать

/world_web_master mode off

> у них вроде бы есть какое-то подобие недоSDK плюс доки

да, у них есть довольно неплохая документация. но это совсем не «интеграция копипастой», там интеграция довольно нетривиальна.

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

> oscommerce

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