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

[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. Можно нажимать.