Доброго дня, уважаемые специалисты вебдизайна!
Ситуация такова. Делаю интернет-магазин. Товар свой (делаю свечи), дизайн тоже сделала свой. Нужна программная начинка, чтобы поставить сайт на рельсы. И вот тут встал вопрос что делать. Насколько я понимаю мне нужен движёк, т.к. магазин у меня достаточно простой и индивидуальный пхп код ему не нужен (права ли я?). Насколько это трудно и реально ли в краткие сроки (ну месяц пусть) поднять эту тему самостоятельно с нуля, разобраться и дорастить сайт на базе движка в магазин? Или не стоит и заморачиваться, сразу обращаться к специалисту? Тогда вопрос бюджета? Я так прикинула расценки очень разные от 250 долларов до 4000 долларов (то, что я нашла в русском инете). Сколько это может реально стоить?
Предвижу вопрос а почему бы мне не воспользовать шаблоном и не сделать типовой магазин на базе движка. Не хочу из принципа. У меня очень индивидуальный товар и для него нужен мой продуманный дизайн (верстку страниц уже завершаю, делала я и художник).
Структура магазина типовая: галерея товара - страница описания товара - корзина - выбор оплаты - выбор доставки. Оплата кредиткой и пэйпэл.
Да, и ещё, для установки оплаты кредиткой нужно ПО от банка?
Короче, я в запарке
Спасибо большое заранее!

Стоимость будет зависеть от того что у вас уже есть. Вам нужна не только программная начинка, но и дизайн, как я понимаю. Поэтому сразу стандартные вещи - логотип и фирменный стиль есть или нужно будет так же разрабатывать? Всё остальное может быть вполне стандартным и будет стоить не очень дорого. Вы можете принимать оплату кредитками через PayPal, тогда вам не нужно будет заворачиваться с ПО банка. Если интересно - обращайтесь в личку или по почте, сделаем вам предложение.

Если товар специфический, смотрите, что бы движок поддерхивал атрибуты товаров

если вы сделали СВОЙ дизайн и верстку, привязать всё это на готовый движок интернет-магазина не получится (там ведь своя логика в страницах и структуре). Правда я не видел вашего дизайна, поэтому ответ субъективный... Вам с нуля вряд ли за месяц это все освоить, лучше искать тех кто разбирается.

Что бы назвать реальную цену, надо побольше информации, в идеале скиньте свой дизайн на емайл и напишите четко что должно быть сделано, тогда могу назвать конкретную цену. Биллинг прикрутить вобще не проблема, если знать какие способы оплаты вам нужны, есть фирмы которые предлагают всё пакетом, вплоть до оплаты по счёту.

фигня, привязать можно практически что угодно к чему угодно, тем более в шопе ничего нового не придумали - список категорий, список товаров, вот и весь шоп :)

возьмите любой движок магазина и накатайте на него свой дизайн, к примеру oxid shop, за месяц точно разбиретесь, ну а если нет, то за 150-200 евро можно найти специалиста который это сделает
без пхп не получится, вам же карзина и заказы нужны

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

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

Вы сами это не осилите.
Тут без perlа или php не обойтись. Я уже молчу про MySQL, хотя, на первых порах можно и без неё.

Сделать магизин без PHP и MYSQL нереально. На движках без PHP делают визитки, блоги, но чтобы магазин - не встречал. Сами вы за месяц не сможете освоить ту же Joomla на уровне программера. На уровне юзера вполне. Но юзер не выйдет за рамки и не сможет доработать код так как вам нужно. Ну разве что мозги прокачаны и не будут закипать после принятия очередной дозы знаний. Знания тоже неупорядочены. Обучающих курсов очень много и нужно их всех пересмотреть, хотя бы ознакомиться, чтобы взять нужное. В общем вам нужен спец. Будут обращаться - спрашивайте готовые примеры.
Что касается ...не хочу "воспользовать(ся) шаблоном и не сделать типовой магазин на базе движка.", то любой движок можно доработать, но за те же деньги (4000) вам напишут новый.

Теоретически можно, чисто на JavaScript, уже встречал в сети движки на джаве, без пыха. Вопрос лишь в том что этот магазин не будет работать у части посетителей с отключенной яваскрипт в браузере.
А вот на пыхе без мускула, сделать простенький магазин точно можно, хоть на текстовых или xml файлах, если хост не поддерживает не каких видов баз.

Абсолютно верно.
Только нужно читать не пых, а пых или перл.

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

Зато перл быстрее и без дырок.

Расскажи нам про дырки в пхп и про актуальное сравнение скоростей.
Пруф!

Да ну? Ты про жабоскрипт или может хотел про жабу сказать?

Первая же ссылка в Гугле: http://www.internet-technologies.ru/articles/article_416.html
И таких вещей - куча!
А про скорость, тут очевидно. ЛЮБАЯ надстройка (а ПХП есть надстройка над Перлом) медленнее оригинала ...

за 2006 год?

А сейчас в РНР нет ни одной дыры?

Постить ссылку шестилетней давности, это бред.
Но даже в твоей собственной ссылке указывается, как настроить виртуальный хост, чтобы за его пределами никакой файл нельзя было прочитать. Это не проблема PHP, это проблема Apache. Я точно так же при отсутствии ограничения на доступ к файлам только в DOCUMENT_ROOT прочту перлом любой доступный всем на чтение файл.

Ты наркоман? 14 лет назад PHP переписали на C.
Что касается скорости, то лично у меня нет однозначного ответа. CGI скрипты на Perl тормозные, FastCGI или mod_perl - будет по скорости близко к php, если рассматривать Apache.

Ты заявил, что в PHP полно дыр, ты и выясняй. От детских болезней в PHP избавились. Чего-то, что позволит массово сайты взломать из-за языка ни в Perl, ни в PHP сейчас нет.

А мне и выяснять не надо.
Твой РНР и рядом с Перлом не стоял.
По поводу Си, не знал.
Но один хрен, над чем РНР надстройка, над Перлом или Си.

Правильно, зачем что-то выяснять.
На форумах так принято: если ты что-то утверждаешь от балды, то тебя просят показать доказательство. Ты сказал, что в PHP полно дыр. Где они?

Кроме тебя никто и не знает, что PHP это надстройка над чем-то. Сам-то понял, что написал?

Ты утверждаешь, что в РНР нет сейчас ни одной дыры?
Если да, то готов потратить своё время и доказать свои слова.
Твой РНР обращается напрямую к процессору? Это низкоуровневый язык программирования?
Тогда вопросов больше нет.

Как ты заметил, я написал "Теоретически", это значит не 100%. Я это подвёл к итогу, так как пару лет назад видал движок на чистом JavaScript( на HTML основе естесно, иначе не как ), с админкой. С чем он там работал, с мускулом или какой другой базой, или текстовыми файлами.., не помню, меня он не интересовал, пробежался лишь поверхностно по описанию. От сюда и мои доводы, о том что можно на JavaScript сделать, а как там в реали, не скажу, я в JavaScript почти ноль, разве что по готовому коду пробежаться да параметры подправить.
А так по поводу дискуссий что лучше - перл или пых, то чего спорить то, каждый юзает то что ему нравится. По мне, так перл своё отжил, просто навсево.

чисто на JavaScript нельзя сделать никакого шопа, все данные и их обработка в любом случае должны производиться на сервере, а это уже php, perl, C#, Java или что угодно + база данных. Вы же надеюсь понимаете что JavaScript это только то что в браузере + запросы на сервер, сам посибе он никаких данных хранить не может.

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

php это скриптовый язык используемый в 99.9% для веб страничек, накой там доступ к процессору и низкоуровнивое программирование ) это же бред. Он отлично справляется в своей отрасли о чем свидетельствует куча сайтов на нем написанных.

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

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

Мой - скорее перл, я на нём за последние десять лет кода накатал побольше чем на пхп. Оба языка транслируют исходники в байт-код, который потом интерпретируют, заметного преимущества у кого-то перед оппонентом нет.
Опять подмена понятий. У тебя каша в голове. Исходный посыл был про скорость Perl vs PHP в вебе. Во-первых, сразу без конкретики уточняющей веб-сервер и в каком виде используются Perl и PHP, за скорость сказать нельзя вообще ничего. Есть три основных типа использования серверного скриипта: в режиме CGI, в режиме хэндлера и в режиме FastCGI. Есть куча веб-серверов и есть куча акселераторов, кэширующих байт-код, значительно ускоряющих время выполнения.
Проблема со сравнением заключается в том, что нет симметричных сравнений одинаковых технологий при использовании обоих языков. Плюс, с Perl вообще непонятно, что быстрее: mod_perl или FastCGI, чтобы взять однозначно самую быструю технологию. Плюс, сюда накладывается, будем ли мы сравнивать отдачу статики или динамики.
Я не видел вообще ни одного грамотного симметричного сравнения производительности в сети. Оба языка можно использовать для написания высокопроизводительного веб-сервиса.

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

данные то где хранятся? js напрямую в mysql ломится? а авторизация как происходит? не нужно путать интерфейсную часть с целым шопом, если жаваскрипт рисует кнопочки и формочки это совсем не значит что весь сайт на нем функционирует

http://www.dimarina.ru/articles/jquery-eshop/ глянь сам, мне лень разбираться

Вот это на клиенте по его словам и это только часть магазина. На сервере всё равно есть: админка, список товаров, платёжка.

Скорее всего, там в каждой странице уже весь набор товара и при выборе клиентом нужно, отправляется емейл на адрес продавца.
Интернет-магазин прошлого века.

ну я ж говорю - вопрос с том, что считать "настоящим" магазином. если не нужна админка, платежка и т.п. что должно храниться на сервере, то магазин на яваскрипте очень даже имеет право на существование

А тебе, Фантомас, я потом отвечу.

данные хранятся в переменных

Не важно, как они хранятся. Смысл в том, что весь Интернет-магазин загружается юзеру в одну страницу. Нет интерактива.

ой ли... ты про кукисы слышал?

В каком смысле?
Если честно, мне не интересно разбираться в технологиях прошлого века (я про инет-магазина на ЯваСкрипте, а не про куки).
На скриптах, оно и удобнее и абсолютно не дороже ...

JavaScript не может слать email. Максимум что можно это по mailto вызвать стандартный емэйл клиент юзера и передаь туда адрес, тему, и до 2000 знаков. Не большой список артикулов товаров конечно проканает, но в купе со всеми товарами зашитыми намертво в html код, без склада, выйдет очень бестолковый магазин, хотя для очень маленьких шопов возможно даже пойдет, если заказ раз в месяц, то чекнуть мыло продвцу не составит труда.

ну не интересно и ладно, незачем тогда писать всякую муть

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

я бы не называл это решениями, это костыли, и давольно кривые
с чего вы взяли что этих решений много, даже тот один, что по ссылке - и то без сервера не обходится, на js лишь клиентская часть, так что магазины на жаваскрипте не более чем плод чей то больной фантазии либо решения прошлого тысячалетия. Хостинг с банальным php стоит копейки, где смысл изобретать веосипед....

Мы говорим о том, что только клиентским яваскриптом, как раз, сделать в принципе невозможно магазин. В твоей ссылке сам автор пишет, что идёт отправка формы на сервер, т.е. есть серверная поддержка. У него задача, почитай внимательно, на яваскрипте написать определённый функционал. Что касается примитивного: статическая html-страничка с товарами и ценами, и яваскрипт, который формирует mailto-урл и открывает его, то это не магазин, а порнография. Больше указанного без серверной поддержки сделать просто нельзя.

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

кокретно другой, это отправка заказа по mailto, либо вывод заказа на принтер и отправка обычной почтой письмом, врядли набурутся клиенты с такими требованиями

Как уже писал до этого, я в JS не спец, но пробежав сейчас по быстрому по гуглу, нашёл такую вот фичу - XMLHttpRequest. И судя по тому что она позволяет делать, а именно считать содержимое текстового файла лежащего на сервере, то реализовать простенький магазин всё же думаю можно. Если в файлах записаны отдельные товары, их данные и описание, то считав это и выведя на страницу, дальше решить проблему покупки товара можно уже через куки.
Но это опять же теоретически..., так как такой магазин будет работать лишь у едениц, из за разных проблем.
А вообще.., кому нужный эти грабли на чистом ява скрипте, магазин должен работать заведомо у всех и без проблем, а значит не должен быть привязан к клиентской стороне. А тут, либо РНР либо ASP.NET, а ява скрипт как решение динамической визуальности и дополнительного удобства интерфейса.

Поздравляю, теперь ты знаешь, что такое AJAX.
Нет, оно ничего не меняет. Ты только получаешь возможность перенести загрузку информации на потом, после загрузки страницы. На сервере ты по-прежнему ничего не можешь поменять. Нет ни админки, ни пользователей, ни нормальной отправки писем, ни платёжки. Это НЕ магазин.

Ну.., что такое AJAX я знаю давно, это связка жабы с пыхом, точнее работа вместе. Но вот конекретно по жаба скрипту не разу не чего не узнавал и не кодил, если не считать того что по книжке делал давно, поэтому всех тонкостей и не знаю. Я можу на пыхе+мускул кодить, а жаба скрипт только чужие наработки методом тыка использовать, благо таковых хватает.
Что касается того движка якобы на чистой жаба скрипт, то по всей видимости либо афтар чего то перегнул, либо не упомянул пыха в своём движке.

ох уж ети пхп кодеры.... а как связка с Java или с С# и т.д. AJAX уже не катит? )) AJAX это и есть XMLHttpRequest, в простонародии асинхронный жаваскрипт, связвать можно с чем угодно, там же просто посылка данных по урлу и ожидание ответа, за последние лет 20 ничего нового...

Нет, это асинхронные запросы JavaScript + XML, к PHP отношения не имеет совсем.

пару лет назад видал движок на чистом JavaScript( на HTML основе естесно, иначе не как ), с админкой.
------
Интересно, как можно видеть движок и не понять что и где? В смысле - не увидеть разницу в клиентской и серверной части?
я в JavaScript почти ноль
------
Хммм... может тогда надо по-осторожнее в суждениях быть?

Серверный js -- это в настоящий момент только node.js
------
Не только.
Элементарно в IIS делаешь расширение JS, ассоциируешь его с ASP-процессором и указываешь в качестве языка Javascript.
Все работает. Лет шесть назад у меня была задачка в суппорте... и ей было немало лет.

так что магазины на жаваскрипте не более чем плод чей то больной фантазии
------
Скорее - ограниченности тех, кто рассуждает об предмете не имея достаточных знаний...
JavaScript не может слать email.
------
Могут, причем оба - клиентский и серверный. Есть отличия и спец.требования, но не суть...

Хрен там.



Когда это станет возможным, наступит новая эра в рассылке спама и организации ддосов.

Хрен там.
------
Есть отличия и спец.требования, но не суть...
=====
Т.е. смотришь в сторону CreateObject() и припоминаешь, что в Винде .NET идет стандартным компонентом со всеми вытекающими...

а ну это костыли, так можно вспомнить и про ActiveX а там если владелец разрешит можно чорта лысого запустить

на последнего.
Народ, ну вы наваяли аж на три страницы! Всем огромное спасибо за дельные советы! Что делать определилась.
ЗЫ. Я не имела ввиду полностью отказаться от ПХП. Имела ввиду, что под мой стандартный магазин не нужно писать всё с нуля, а можно воспользоваться готовыми решениями (по крайней мере у меня сложилось такое впечатление). Против готовых дизайнов ничего не имею, просто не во всех случаях подходит элегантный минималистический стиль с обтекаемыми кнопками (а именно им сейчас "злоупотребляет" процентов 90 разработчиков, ну мода, тенденции и тд). Не спорю, есть очень красивые решения в таком стиле, но мне он просто не подходит ввиду особенностей товара. Согласитесь, что расписную хохломскую чашку не запакуешь в упаковку Икеи. Отсюда родилась мысль о создании своего дизайна, пусть немодного, но индивидуального и совпадающего по стилю с товаром.

Хорошо бы было еще понимать, что CreateObject() это и есть использование ActiveX...
Остальное - оговорено.

Victor! и voxel3d, я могу на пыхе с мускулом кодить, но я не кодер, это просто моё вынужденное занятие пока, поэтому всех тонкостей и не знаю.

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

угу, согласен, только на perl таки можно магазин написать, он же на сервере исполняется :)
тема конечно ушла в другое русло, но это тута часто бывает )

Да, в другое русло это хорошо сказанно :)))

уже выяснили что на чистой жаба скрит магазин не сделать
------
ТоварисЧа кодера, как Программист, Я специЯльно для кодерАв выше напИсал:
- об клиентском жабьем скрипте
и
- об серверном жабьем скрипте...
И заметьте товарЫЩа кодера - у программистов по эНтому вАпросу непонимания нЯ возникло...

Я не успел отписать.
CreateObject не нашёл. Есть ActiveXObject в JScript. А JScript это не JavaScript. На клиентском JavaScript магазин сделать нельзя.

чтоб не заморачеватца идите на ucoz там вам всё будет и магазин и гост.книга и т.д.

CreateObject не нашёл. Есть ActiveXObject в JScript.
------
Буковки Я мог и перепутать - клиентом Я занимаюсь крайне редко. Что Я не путаю - а не путаю Я это потому что это технология и когда-то Я ее использовал - на клиенте при определенных условиях можно создавать ActiveX объекты. Даже если не через CreateObject(), а описывать как <object > или еще как.
А JScript это не JavaScript.
------
Не совсем. Производителем (т.е. MS) заявляется что JScript есть мелкософтовская версия JavaScript.
На клиентском JavaScript магазин сделать нельзя.
------
??? - Я где-то утверждал обратное?

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

МС могут чё угодно заявлять, от этого их мусор яваскриптом не становится. И вообще, они и не заявляют, что это их версия JavaScript, они говорят, что частично реализовывают ECMAScript 3,4.

Ну, хорошо, на клиентском яваскрипте сделать smtp сервер нельзя.

на клиентском яваскрипте сделать smtp сервер нельзя
------
Опять таки - да/нет но... можно загрузить ActiveX SMTP... при определенных условиях.
Вопрос, пост 38, если не ошибаюсь, изначально был несколько другим - отправить майл используя жабийскрипт.
Отправить майл можно не только через СМТП - серверов с web-интерфейсами вполне достаточно, а ссылка на то, что это будет "сервер-сайд" не канает в виду того, что СМТП таки тоже сервер-сайд...