Конструктор интеренет магазинов - какие есть?

borisd, Джанга большое зло - поверьте:)

Конкретизируйте...

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

Поэтому, если делать самопис на фреймворке, то на ПХП я делать не буду (не хочу). Если на ПХП найдется подходящее (главное простое и гибкое) решение, то тогда возьму этот вариант. В принципе мне как конструктор Друпал 7 Commerce нравится, если бы не его вечные болячки. Глянул в сторону коммерса на Друпал8, но там вообще сырое всё ещё, а судя по тому, для Друпал7 множество необходимых модулей так и остались в альфа-бета-версиях, то перспективы выглядят нерадужными. Да и вот на днях пытался обновить все устаревшие модули на имеющихся проектах - фиг там, вылезают ошибки, поэтому обновил только уязвимые модули. Хотел свой модуль удалить, а фиг там - ругается на привязанное к ноде поле. Удалил это поле - ругается, очистил кэш и запустил крон - ругается, в итоге оказалось, что для полного удаления надо было крон раз 5-10 запустить... И вот такой фигней приходится постоянно с друпалом заниматься. Надоело...

Как ни крути, а админка говно-говном.

borisd, посмотрите в сторону Go. Компилируется, быстрый, простой, есть параллельность, GC, приятный синтаксис, каналы и горутины (что-то вроде легковесных (4кб)

тредов, которые рантайм расскидывает по ядрам). Собирается в бинарник, заливается на сервер, работает. У меня есть несколько проектов на нем. Один написал за 3 дня, другой забросил. В целом, никаких фреймворков и прочего не нужно. Но предупреждаю сразу, будет больно так как тут нету наследования, а есть композиция. Отсюда слегка непривычное ООП. Ну и плюсом будет то, что не нужно миллиарды абстракций чтобы начать работать.

Это конечно всё интересно, но как например в Go на лету создать Word/Exel/PDF документ? В ПХП и тем более в Питоне огромное количество библиотек и пакетов, что очень важно.

Google: "go language {NEEDED_FEATURE} library"

borisd, ну, начнем с того, что xls и Word это те же XML файлы. Но если это опустить, то есть либы. Вот примерный синтаксис того, чтобы записать в файл экспорт товаров.

package main

import (
	"fmt"

	"github.com/tealeg/xlsx"
)

type Product struct {
	ID   int
	Name string
	Skus []Sku
}

type Sku struct {
	ID    int
	Name  string
	Price float32
}

var products = make([]Product, 0)

func init() {
	products = append(products, Product{
		ID:   1,
		Name: "Чашка",
		Skus: []Sku{
			{ID: 1, Name: "красная", Price: 7.99},
			{ID: 2, Name: "зеленая", Price: 6.99},
		},
	})
}

func main() {
	file := xlsx.NewFile()

	sheet, _ := file.AddSheet("products")

	for _, product := range products {
		row := sheet.AddRow()

		row.AddCell().Value = fmt.Sprintf("%d", product.ID)
		row.AddCell().Value = product.Name
		row.AddCell().Value = fmt.Sprintf("%.2f", product.Skus[0].Price)
	}

	file.Save("./export.xlsx")

}

Но такую муть как PDF, XLS, DOC я бы выносил на Python. Само ядро можно описать на Go, где потом рефакторинг не будет вызывать жопную боль. Тут есть кастомные типы, которые очень удобны, например:

package main

import "fmt"

type Money struct {
	Currency
	Amount float32
}

func (m Money) String() string {
	return m.Currency.Format(m.Amount)
}

type Currency struct {
	Code   string
	Format func(amount float32) string
}

func main() {
	USD := Currency{
		Code: "USD",
		Format: func(amount float32) string {
			return fmt.Sprintf("$%.2f", amount)
		},
	}

	money := Money{USD, 7.99}

	fmt.Println(money) // $7.99 - уже отформатировано
}

У структуры Money есть метод String() который возвращает строку. Данный метод используется повсюду, где есть поддержка интерфейса Stringer (собственно, чтобы удовлетворять этому интерфейсу, нужно всего лишь реализовать метод String() string с нужной сигнатурой, сама имплементация неявна, не нужно писать implements и т.д.). В итоге, достаточно везде пихать Money и они будут форматироваться в зависимости от currency, которые включают в себя. Если доллары форматируются по стандарту со знаком доллара спереди, то рубли наоборот (к примеру).

Есть ещё теги, которые определяют ORM зависимости и JSON, XML сущности. Можно сделать так:

package main

import (
	"encoding/json"
	"os"
)

type Product struct {
	ID   int    `json:"id"`
	Name string `json:"name"`
	Skus []Sku  `json:"skus"`
}

type Sku struct {
	ID    int     `json:"id"`
	Name  string  `json:"name"`
	Price float32 `json:"price"`
}

var products = make([]Product, 0)

func init() {
	products = append(products, Product{
		ID:   1,
		Name: "Чашка",
		Skus: []Sku{
			{ID: 1, Name: "красная", Price: 7.99},
			{ID: 2, Name: "зеленая", Price: 6.99},
		},
	})
}

func main() {
	enc := json.NewEncoder(os.Stdout) // пишем в stdout, можно и в http.Response, и в файл, и куда угодно
	enc.SetIndent("", "    ") // красиво отформатируем

	enc.Encode(products)
}

И получим

[
    {
        "id": 1,
        "name": "Чашка",
        "skus": [
            {
                "id": 1,
                "name": "красная",
                "price": 7.99
            },
            {
                "id": 2,
                "name": "зеленая",
                "price": 6.99
            }
        ]
    }
]

danforth, приятный синтаксис, надо будет ознакомиться, но это потом, сейчас надо на чем то более привычном сделать (Python/PHP).

Кстати, как Go по скорости?

---------- Добавлено 02.07.2017 в 23:29 ----------

В общем пока склоняюсь к Django Oscar. Сейчас нашел инфу по его тормозам:

Т.е. в режиме отладки (а демоверсия работает только в нем) скорость значительно ниже - составляет 17 к 120 запросам в сек., а при включении кэширования шаблонов 17 к 140, т. е. демоверсия по определению очень медленная и надо пробовать на полноценной исталляции. В общем попробую установить оскар по нормальному и тогда посмотрю. Из коробки он имхо превосходит OpenCart, но под капотом у него джанго и API-конструктор интернет магазинов, плюс я еще Wagtail задействую с Elasticsearch. Если со скоростью будет все нормально, то вероятно на нем и остановлюсь.

По части админки WP делает всех - вопросов нет. Но в МодЭксе она настраивается под менагеров достаточно легко.

(Имхо, ТС всех троллит :))

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

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3

Ну а так, это собственно, одна из причин, почему выбирают Go - скорость.

17 versus 120 значит 17 - с debug = true; и 120 - с debug = false; это не отношение 17 к 120. Или я вас не правильно понял.