В продолжение темы про аксапту на PHP

[potential]

Цитата:

Сообщение от Polar

Желательно просматривать на экранах с большим разрешением, а то разметка вся не поместится, либо пользуйтесь клавишами CTRL +- для уменьшения увеличения страницы. В файерфоксе и експлорере не работает.

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

CTRL +- не помогает, какое должно быть разрешение? Сейчас 1440х900 Телевизора 4к 3840x2160 под рукой к сожалению нет
Какой вы функционал перенесли? пару справочников на 4 поля каждый?
Время отклика чудовищное, Один проц, 512 Mb - этого должно быть за глаза, такая конфигурация может держать десятки php сессий единовременно

[Polar]

Цитата:

Сообщение от potential

CTRL +- не помогает, какое должно быть разрешение? Сейчас 1440х900 Телевизора 4к 3840x2160 под рукой к сожалению нет
Какой вы функционал перенесли? пару справочников на 4 поля каждый?
Время отклика чудовищное, Один проц, 512 Mb - этого должно быть за глаза, такая конфигурация может держать десятки php сессий единовременно

Все спроектировано, чтобы использовать ресурс клиентской машины, код выполняется в браузере. Если у вас что-то тормозит, то это ваш комп виноват.

Функционал не переносил, попробовал как он переносится. Я же инструмент хотел сделать, типа замены access, чтобы кроссплатформенно, быстро кастомизировать. Вот чтобы сделать вебформу достаточно создать таблицу и написать несколько строк кода.

[mazzy]

Цитата:

Сообщение от Polar

Все спроектировано, чтобы использовать ресурс клиентской машины, код выполняется в браузере.

1. Все чаще и чаще для серфинга используются планшеты и телефоны.
2. деплой скриптов на клиента тот еще геморрой. особенно, если есть модули.

думаю, что стоит подумать еще раз над этим.

[Ace of Database]

Посмотрел рынок приложений ZoHo.
Что-то у всех приложений 0 оценок. Или я неправильно смотрю.
https://marketplace.zoho.com/Extensi...tegory_tid=All

[ax_mct]

Цитата:

Сообщение от Ace of Database

Посмотрел рынок приложений ZoHo.
Что-то у всех приложений 0 оценок. Или я неправильно смотрю.
https://marketplace.zoho.com/Extensi...tegory_tid=All

Странно, да. Но 3500 сотрудников и 25 млн пользователей.

Цены на управление складом такие такие что конкурировать как бабушке с супермаркетом
От $ 29 per organization / month
P.S. Удалил ссылки на Zoho, а то ведь Product Placement )

Цитата:

Есть у меня стойкое желание отгрызть чуток профита от zoho.

Как автор темы хочет откусить от Zoho? Вернее чем?

[Polar]

Цитата:

Сообщение от ax_mct

Как автор темы хочет откусить от Zoho? Вернее чем?

Zoho - это Saas.
1. Ты платишь постоянно.
2. Твои данные и приложение тебе не принадлежат.
3. Перестаешь платить - лишаешься своих данных и возможности работать.
4. Сделать что-то сложное в приложении стоит много денег, т.к. нет доступа к коду.

Достоинства
1. можно работать на любой ОС
2. можно работать из любой точки мира.
3. Простота создания приложения.
4. Есть готовые решения.

Вот я собираюсь оставить достоинства и убрать недостатки.
Для этого нужен простой фреймворк, который работал бы на самом дешевом хостинге. Кастомизировался на основе метаданных, а не языка PHP, обладал простым, но мощным API, был максимально прозрачен для быстрого дебага.
А насчет Zoho так посмотри сколько людей уже ищет ему альтернативу, чтобы слезть с этой иглы. Стоимость владения моим фреймворком будет не больше чем оплата за хостинг в месяц. Я вот нашел за 1 евро. (у zoho 25$ плюс оплата за каждого пользователя). У меня пользователей будет неограничено.

ЗЫ. Буду продавать исходники и ставить их на хостинг клиента. Возможно допиливать за денюжку.

[ax_mct]

Цитата:

Сообщение от Polar

Zoho - это Saas.
...
А насчет Zoho так посмотри сколько людей уже ищет ему альтернативу, чтобы слезть с этой иглы. Стоимость владения моим фреймворком будет не больше чем оплата за хостинг в месяц.
...
ЗЫ. Буду продавать исходники и ставить их на хостинг клиента. Возможно допиливать за денюжку.

SugarCRM, SuiteCRM и еще с десяток слонов.

Если у тебя получиться создать активное сообщество вокруг то да. В основном то размер слона определяется количеством программистов в сообществе конкретного фреймворка.

Стоимость владения твоим фреймворком это не только хостинг. Это еще и разработка и поддержка.

Вот я программист PHP создающий бизнес-приложения под заказ. Чем возьмешь меня? Мне нужно чтобы фреймворк 1) был проверен временем 2) был полным. 3) помогал в моей карьере и маркетинге.
Дешевизна хостинга - не волнует.

Вот я владелец бизнеса. Мне нужно некое подобие ERP и CRM. Чем возьмешь меня? Дешевый хостинг? OK. Но мне не нужно сэкономить 10 долларов в месяц, а о примерно такой экономии идет речь если сравнивать с альтернативами.
Мне нужно чтобы ПРОДУКТ 1) был бесплатен 2) надежен 3) нужный фунционал
4) приемлимый хостинг.
Фреймворки вообще не интересны.

То есть на форуме программистов можно набрать актив и уникальный фреймворк пойдет. Особенно сейчас когда Аксапта на PHP смеха не вызывает потому как похороны АX в старом ее виде.
Предположим есть на форуме десяток другой программистов которые воспринимают "Аксапта на PHP" как вполне себе логичный вариант.

Но дешевый хостинг как аргумент для программистов?
Метаданные, простота и прочее? И што такого еще нет?
В чем твой маркетинг для целевой аудитории программистов?
Ты очень молодец, интересный проект, но ты же хочешь не просто одобрения но и сообщество?

[ax_mct]

Цитата:

Сообщение от Polar

Все спроектировано, чтобы использовать ресурс клиентской машины, код выполняется в браузере. Если у вас что-то тормозит, то это ваш комп виноват.

Функционал не переносил, попробовал как он переносится. Я же инструмент хотел сделать, типа замены access, чтобы кроссплатформенно, быстро кастомизировать. Вот чтобы сделать вебформу достаточно создать таблицу и написать несколько строк кода.

То есть это не продукт, a PHP framework для создания бизнес-приложения.
И выбирать его надо не за бизнес-фунционал, а за некую привлекательность.

Чем он привлекательней чем такие лидеры как Symfony, Laravel и Yii?
Ну и еще пары десятков других
https://en.wikipedia.org/wiki/Category:PHP_frameworks

Я помню что вам не нравится классические MVC и ORM паттерны.
Но я не верю что нет уже популярного фрэймворка на PHP который бы уже не решал проблемы MVC и ORM. Либо такой есть либо проблемы надуманные.

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

Как выбрать PHP фреймворк?
https://habrahabr.ru/post/305626/
https://opensource.com/business/16/6...work-right-you

[Bobkov]

Цитата:

Сообщение от Polar

Все спроектировано, чтобы использовать ресурс клиентской машины, код выполняется в браузере. Если у вас что-то тормозит, то это ваш комп виноват.

Аскетично так выглядит, мне понравилось

Вижу в девтуле, что используется какой-то язык запросов к БД.
Например:

filterscount:0
groupscount:0
pagenum:0
pagesize:25
recordstartindex:0
recordendindex:25
table:address
addfilterdatafield0:entitytype
addfiltercondition0:EQUAL
addfiltervalue0:0
addfilterdatafield1:type
addfiltercondition1:EQUAL
addfiltervalue1:0
addfilterdatafield2:entityid
addfiltercondition2:EQUAL
addfiltervalue2:1
fieldset:id,address,address2,city,postcode,comment
addfiltercount:3

Возникли вопросы:
1) Этот язык запросов к БД вы сами придумали или взяли какой-то имеющийся? Какой?
2) Вижу, вроде используются только однотабличные запросы к БД. А с джойнами можно запросы делать?

Мне кажется, будет полезно сделать возможность отправлять несколько запросов к БД одним http-запросом. Это сильно сократит время получения данных с сервера в случае множества запросов.

[Polar]

Цитата:

Сообщение от Bobkov

Аскетично так выглядит, мне понравилось


2) Вижу, вроде используются только однотабличные запросы к БД. А с джойнами можно запросы делать?

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

Вот так выглядит Absence registration в базе.


Поля employeeid, cause_of_absense, unitofmeasure это ссылки на другие таблицы. Чтобы вытащить значение в форму надо через двойное подчеркивание написать имя поля в связанной таблице. Например employeeid__first_name. Движок сам все делает.
Код формы Absence registration можете посмотреть правой кнопкой на форме и "Просмотр кода фрейма". Также можно посмотреть код любой формы, все открыто.

[Polar]

Насчет языка запросов, то пришлось придумать. А то в реквесте браузера нельзя передавать некоторые символы
Вот придумал язык:

switch ($filtercondition)
				{
			case "CONTAINS":
				return "LIKE";
				break;
			case "DOES_NOT_CONTAIN":
				return "NOT LIKE";
				break;
			case "EQUAL":
				return "=";
				break;
			case "NOT_EQUAL":
				return "<>";
				break;
			case "GREATER_THAN":
				return ">";
				break;
			case "LESS_THAN":
				return "<";
				break;
			case "GREATER_THAN_OR_EQUAL":
				return ">=";
				break;
			case "LESS_THAN_OR_EQUAL":
				return "<=";
				break;
			case "NULL":
				return "IS NULL";
				break;
			case "NOT_NULL":
				return "IS NOT NULL";
				break;
			case "IN":
				return "IN";
				break;
			default: return "UNKNOWN";				
}

[Bobkov]

Спасибо за пояснения, стало понятнее.

Цитата:

Сообщение от Polar

Насчет языка запросов, то пришлось придумать. А то в реквесте браузера нельзя передавать некоторые символы

Вроде, в теле http-запроса в качестве значений можно передавать любые символы, для этого в браузере используется функция window.encodeURI, а на сервере – обратная ей. Или я не понял проблему, что за символы и в каком месте запроса не получилось передать.

Вообще, люди уже довольно потоптались на этой теме и родили стандарт ODATA - текущая версия 4.0 - http://www.odata.org/, который вроде как реализован в продуктах Microsoft, SAP, 1C, IBM, а также других, менее известных организаций. Мне кажется, даже частичная совместимость с этим стандартом как минимум украсила бы ваш продукт, если конечно нет каких-то противопоказаний его использования.

Цитата:

Сообщение от Polar

Надо, чтобы на хостинге разместить можно было, а хостеры нервничают, если долгие запросы. Поэтому пришлось оставить только simple SQL.

Со вводом данных более-менее понятно. А как вы видите реализацию отчетов, в том числе больших и сложных? Тут без долгих запросов не обойтись, наверное.
Мне видится, что реализация примеров отчетов (одного простого и одного сложного) была бы логичным шагом развития вашего прототипа.

[Polar]

Цитата:

Сообщение от Bobkov

Со вводом данных более-менее понятно. А как вы видите реализацию отчетов, в том числе больших и сложных? Тут без долгих запросов не обойтись, наверное.
Мне видится, что реализация примеров отчетов (одного простого и одного сложного) была бы логичным шагом развития вашего прототипа.

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

С отчетами есть 2 варианта, либо на сервере обрабатывать информацию и выдавать в готовом виде на PHP, либо выкачивать информацию на клиента (возможно с группировками и суммированием) и делать расчеты на клиентской машине на JavaScript в браузере. Смотря что будет быстрее. Например на рабочей станции будет стоять мощный проц и дофига памяти, тогда лучше запросить справочники и расчитывать отчет на клиенте, а не издеваться над сервером.

PS На форме Employee есть кнопки в названии Print. Можно нажимать.