А зачем собственно топтать 1С?
Я смысла не особо наблюдаю.

Uzhast писал(а) 15. Октября 2007 :: 08:46:


В Sap е активно продвигают Web-интерфейс как основной для работы с программой.
Вроде бы это считается более передовым, чем интефейс а-ля XP. Смысл ( пишут в документации) -
в объединении в одном интерфейсе не только базы данных, но всех бизнес-приложений.
Хорошая идея.

kiruha писал(а) 15. Октября 2007 :: 09:22:

А я согласен со Спольски в том, что веб-интерфейс ущербен от рождения. Он просто не имеет достаточного количества возможностей.

fez писал(а) 15. Октября 2007 :: 09:26:

Зато как удобен в плане "инсталляции"! Зато какая кроссплатформенность! Ну и, смотря какой веб-интерфейс. Можно, например, заложиться на FireFox и его XUL. Там уже очень близко к толстому клиенту.

kms писал(а) 15. Октября 2007 :: 10:15:

А все давай (Но, желательно, с налетом благородного безумия )

kms писал(а) 15. Октября 2007 :: 10:15:

Сдается мне, здесь все-таки придется поработать ручками. Такой простой вариант, как хотел сделать steban, уж очень много ограничений имеет...

kms писал(а) 15. Октября 2007 :: 11:32:


Хмм... Тогда какие еще есть варианты?

P.S. Uzhast, по изложенным вариантам в душе я с тобой   Только как девелопер я никакой

fez писал(а) 15. Октября 2007 :: 14:45:

Эээ... tcp/ip это сетевой протокол, а dcom это грубо говоря набор стандартов для взаимодействия различных объектов, в том числе и на разных компьютерах. Так что сравнивать их как то не того

Если делать что-то свое со связью по tcp/ip, то это будет конечно мегапроект... Но сколько потребуется на это времени и усилий...

Ну, вот вам идея, правда, вроде как бы и не совсем безумная.
Берем 1С dbf.
Вроде как бы работа с "родными" таблицами в dbeng32 расковыряна уже, в плане перебора таблиц, работы с индексами и тп.
(смотрим http://www.infostart.ru/projects/811/)
Присовокупляем к этому SQLite, и с помощью механизма виртуальных таблиц отображаем 1Сные дбфки в базу SQLite, можно сразу с человеческими именами. Ну и далее соответственно, движок SQLite даст возможность писать нормальные запросы к этим дбфкам, безо всяких прокладок в виде VFP драйверов и ADO, причем и в монопольном режиме. Мне сейчас этим недосуг заниматься, да и не очень актуально это для меня, но вот для контор с 15-30 юзерами, сидящими терминально в дбф, было бы неплохо.

kiruha писал(а) 17. Октября 2007 :: 07:20:

Вообще, да. Вот тут у меня есть примерчик: 3Гб база DBF, 50 юзверей, дохловатый по сегодняшним меркам терминальный сервер. Не то, чтобы летает, но более-менее работает. А для SQLite есть такие примеры? Вот что интересно было бы, так это Oracle или Postgre.

kms писал(а) 15. Октября 2007 :: 10:15:

А что в первую очередь ожидается от "сервера приложений"? Выполнение методов 1С объектов на сервере? Или что? Например, чем не достаточно двух 1Сов, взаимодействующих через TCP/IP? Может, немного конкретнее опишешь, как ты представляешь себе сервер приложений?

Видимо не все меня правильно поняли.
Нет речи о замене дбф-движка на SQLLite.
SQLite здесь предлагается использовать как SQL-обертку над dbeng32, позволяя писать нормальные запросы через родной дбф-движок, что позволит в отличии от FoxPro работать и в монопольном режиме.
И не надо говорить, что FoxPro для запросов быстрее. Слаб он, и индексами как-то странно пользуется, вернее не пользуется.

Phoenix писал(а) 17. Октября 2007 :: 07:26:

А есть живые люди, на которых производились испытания этого продукта?

orefkov писал(а) 17. Октября 2007 :: 07:30:


Откуда информация что Fox слаб?

Отчет продажи за год, разворот по всем документам, сейчас 30 пользователей, база 1Гб :
Цитата:


А здесь приблизительное сравнение на 2 операции SQLLite и Fox :
http://www.1cpp.ru/forum/YaBB.pl?num=1191570663/30

Здесь использование индексов :
http://www.1cpp.ru/forum/YaBB.pl?num=1184317705/0

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

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

Z1 писал(а) 17. Октября 2007 :: 07:58:

Любопытственно
Z1 писал(а) 17. Октября 2007 :: 07:58:

Кстати, идея. А если пойти не через ковыряние dbeng32, а через создание собственного варианта ODBC-драйвера для MSSQL. 1С будет думать, что она работает с MSSQL, а мы через свой драйвер уговорим ее работать с чем-нибудь другим?

Z1 писал(а) 17. Октября 2007 :: 08:11:

Ну да. Только почему бы чуть дальше не пойти? Сделать драйвер с открытым API с возможностью подключать к нему небольшие модули, обеспечивающими работу 1С с другими БД. В отличие от dbeng32 информации по созданию ODBC-драйверов куда больше.

В принципе orefkov прав в том, что драйвер Fox мог бы и догадаться,что если стоит условие

WHERE ID=' ZSD     ' 

и есть индекс по выражению ID+STR(Date,8) ,
то нужно использовать этот индекс, а не шерстить всю таблицу.

Вот идея подправки драйвера наверно было бы cool

И насчет сервера приложений - если он может оптимизировать нагрузку, тоже cool.
Во всяком случае - для SQL и при большом количестве пользователей  рекомендуют его иметь.

Uzhast писал(а) 17. Октября 2007 :: 07:26:

Красивую модель сейчас на трезвую голову не нарисую - много думать надо.
Но вкратце, как-то так:

На клиенте существует объект - "ПроксиОбъект".
Некоторой командой инициализации мы создаем объект на сервере и сопоставляем его прокси-объекту.
Дальше мы можем вызывать методы и использовать данные прокси-объекта, переадресуя вызовы объекту сервера.

Примерно так:

_сервер =СоздатьОбъект("Сервер");
// установка параметров авторизации, безопасности, адрес сервера и т.д.
_сервер.Подключить();

_о =_сервер.СоздатьОбъект("КлассОтчетОстаткиТМЦ");
_результат =_о.ПолучитьОстатки();
 

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

_склад =_о.ПолучитьГлавныйСклад(); // справочник.элемент
Сообщить(_склад.Наименование);
 

Короче, такая модель.
Вполне двусторонняя, т.к. если можно получать данные, то ничто не мешает их передавать и обрабатывать на сервере.
Вполне масштабируемая, т.к. можно не ограничивать возможность подключения одним соединением - соединенй может быть много.
Режим получения данных может быть как синхронным, так и асинхронным.
Создал 10 подключений к филиалам, раздал всем команду "ПодготовитьОтчет", собрал в кучу, когда будет готово.

Для локальной сети - кроме балансировки нагрузки получаем еще и непосредственную типизацию результата в родной формат.
Например на сервере можно вернуть "ЗначениеВСтрокуВнутр(тз)", а на клиенте - развернуть, и это будут родные данные.

Ну, а о проблемах на этом пути... потом как-нибудь подумаем...
Их примерно еще на два листа (это те, о которых я знаю).

kms писал(а) 17. Октября 2007 :: 16:52:

А ведь похоже, что такую хреновину (прокси для CBLContext) сделать не так уж и сложно Наверное, сложнее всего будет сделать некий головной модуль, удерживающий пул одинэсов и распределяющий запросы между ними.

kms писал(а) 17. Октября 2007 :: 17:03:


Миш, пример того что тебе надо можешь выложить скриншот? я восьмерку не наю

kms писал(а) 17. Октября 2007 :: 17:03:

Показалось что-то У панели команд ведь может быть ну очень много кнопок. И каждая с картинкой или текстом. Плюс какие-нибудь дополнительные атрибуты. Боюсь, что может стать не наглядно. Будет здоровая куча кода, с которой сложновато работать. Но, как говорится, на безрыбье и это сойдет. Но вот как бы было здорово, если бы удалось еще расковырять редактор форм для Конфигуратора?...

Блин, я от этих вентиляторов скоро на стену полезу  С 7.0 еще тянутся

kms писал(а) 17. Октября 2007 :: 17:22:

Как раз для этой ветки
Надо будет поспрашивать trdm'а насчет хорошего встраиваемого опесурсного редактора форм. И настропалить metaeditor'а встроить этот редактор вместо одинэсного (опыт, типа, есть, все дела...)

kms писал(а) 17. Октября 2007 :: 17:18:

Во!

Берём
1. "Революцию возможностей"
2. Справочники кнопок, панелей, форм, и т.д.
3. Общие.Форма.Привязка

И вполне можно сбацать v8taskbar.

---

А! Ещё
0. перехватчик, ессно.

Uzhast писал(а) 17. Октября 2007 :: 17:29:

А пожалуй, что и правда, нормальная идея.
Тогда что, надо, выходит, делать новый конфигуратор?
Ничего себе неделька начинается...

Миш, такой тулбар нормально реализуется через активикс MSComctlLib.Toolbar

Arta писал(а) 17. Октября 2007 :: 17:48:

А он разве не в восьмерке по самые ... эээ... по пояс, короче?

Arta писал(а) 17. Октября 2007 :: 17:46:

Пока вижу у этого контрола один недостаток: он (вроде) не хавает картинки из библиотеки картинок. Вообще, может быть можно извлечь какую-то дополнительную пользу от более тесной интеграции с 1С? Например, более удобное управлением событиями? Или еще что-нибудь?

Uzhast писал(а) 17. Октября 2007 :: 17:56:

У контрола много недостатков.
1. Иногда проблема с видимостью, пока не наведешь мышку. Этим грешат все микрософтовские активиксы.
2. При активном пользовании тулбара иногда вылазит ошибка загрузку картинок.
3. Еще много чего
Несмотря на это:
1. кол-во цветов у картинки выше.
2. Реагирует при наведении мышой на кнопку
3. Возможность штатных дополнительных выпадающих меню у кнопки
4. И самое главное - динамическое изменение кол-ва кнопка в коде. Для меня это было основополагающим при переходе с обычных кнопок на тулбар.

Какую пользу извлечь - хз, каждый свою пользу найдет
Управление событиями как обычно - ButtonClick, ButtonMenuClick

Но у всех активиксов есть заметная задержка появления на экране (инициализации) при первом использовании. Никто этого не замечает, а меня бесит

Или тоже самое, только с текстом.

P.S. Это у меня багзила для юзеров внутри 1С

Arta писал(а) 17. Октября 2007 :: 18:42:


и кто на этом рисунке сможет опознать интерфейс 1С

красиво

trdm писал(а) 17. Октября 2007 :: 18:52:

Да не расстраивайся ты так Люди согласны на счастье частями, а то цельный 2С слишком долго ждать Да и так даже лучше. Больше шансов, что сделанная работа не пропадет: мало ли что будет с 2С? А так сделанную запчасть можно использовать уже здесь и сейчас. А после небольшого допиливания эту запчасть можно и к 2С приделать. Так что люди фактически делают твой 2С, а ты тут слезу пускаешь

Или такой?
Обычно поставляется как плагин и можно встраивать, вот пример:
http://www.anyqsoft.com/download1?Lang=Rus

Arta писал(а) 17. Октября 2007 :: 18:42:


Красиво.... А нельзя в репозиторий кинуть или ссылку как сделано ?

Arta писал(а) 17. Октября 2007 :: 19:38:

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

Arta писал(а) 17. Октября 2007 :: 17:46:

А неплохо, вполне покатит.
Твои картинки нравяцца

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

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

И еще концептуальный вопрос: на подобные контролы есть какая-то документация или принято осваивать интуитивным спобосом?

Сегодня, на свежую голову, вспомнил чего мне не хватало на v7++, пока не попробовал v8.
1. Возможность описать приватный класс прямо в тексте модуля. Описывать такие классы с помощью дефцлс слишком накладно. Такая возможность сильно бы повысила консистентность кода.
2. Пользовательские атрибуты классов. Про них я уже как-то писал. Меня, кстати, сильно удивляет что никто про них не вспоминает. Удобнейшая вещь!

зы: про гуи не вспоминаю [противно  ], думаю, ничего путного все-равно не выйдет.

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

trdm писал(а) 18. Октября 2007 :: 07:04:

У меня только цитрикс, TS, и Netop (типа радмина). Все фунициклирует.

Цитата:

Лукавишь, Палыч. У нас сейчас есть возможность вообще классы на лету создавать. 

Цитата:

Вопрос спорный. Прежде всего все те активиксы которые ты сможешь подцепить на v8, можно использовать и на v7. А другой момент, немаловажный, восьмерка со всей ее красивостью имеет тяжелый интерфейс, который перерисовывается дольше на тонком канале, если работать в терминальной сессии.

JohnyDeath писал(а) 18. Октября 2007 :: 06:53:

ИМХО, не надо от него плясать

Uzhast писал(а) 18. Октября 2007 :: 07:56:

Так работает sqlite.
Независимо от того, есть в тексте параметры или нет, запрос всегда подгатавливается, потом выполняется.
Метод ВыполнитьЗапрос внутри себя так и работает.
Ну, если это напрягает, можно запрос.Подготовить убрать, а в цикле поставить
запрос.ВыполнитьЗапрос("insert into test values('sdjfhdjfh', 12)");
Кроме того, в sqlite если параметр не изменяется, то между вызовами Выполнить его можно не переустанавливать.
Плюсы: в будущем возможность работы в монопольном режиме.
возможность работать в :memory:
Выгрузку из ТЗ во временные таблицы можно реализовать единым методом на С++, тогда вообще порвет по скорости.

orefkov писал(а) 18. Октября 2007 :: 08:05:

Для ДБФ? Как ты это представляешь? Вообще, все эти тесты производительности делаются для нативной базы SQLite. А с 1С разве такой результат будет? Или у тебя уже есть наработки по переводу 1С на SQLite? Или ты это к разговору, что могло БЫ быть, если БЫ перевести 1С на SQLite?

orefkov писал(а) 18. Октября 2007 :: 08:05:

В Фоксе именно это и используется. Но получается в два раза медленнее. Хотя я на старой компоненте тестирую.

orefkov писал(а) 18. Октября 2007 :: 08:05:

Для OLE DB это тоже можно сделать без проблем

Uzhast писал(а) 18. Октября 2007 :: 08:09:


Вот вариант с "честной" параметризацией.
Буду благодарен за цифры.

хехе, первый ребеночек лукаво проведенного мозгового штурма ))))
люблю такие ветки, вечно что-то рождается, неожиданное, полезноЕ....
ПС. Судя по размеру dll Лайт внутри, если конечно не дебуг..
ПС2. Жаль, не могу пиво выставить на эту вечеринку, да и клиент едет, но все равно, я с Вами..

Nick писал(а) 18. Октября 2007 :: 08:34:

А так и сравниваю. Табличка берется в памяти. А там что в монополе, что нет - один хрен. Проверял

Uzhast писал(а) 18. Октября 2007 :: 08:36:

Что значит в памяти?

orefkov писал(а) 18. Октября 2007 :: 08:05:

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

Нужно учитывать, что в случае с sqllite работа идет напрямую с движком, а для vfpoledb через провайдер.

Uzhast писал(а) 18. Октября 2007 :: 08:16:

Идем на http://www.sqlite.org/lang_createvtab.html
Читаем. Теперь представь, что я в своей ВК делаю sqlite3_create_module, и регистрирую модуль, ну допустим dbeng.
Далее юзер выполняет запрос

create virtual table Товары using dbeng("Справочник.Номенклатура")

Теперь SQLite позволит составлять запросы с использованием таблицы Товары, а за данными из этой таблицы и для поиска в ней будет обращатся к моему модулю. А я уж через dbeng32.dll буду все это делать. Естественно, и в монопольном режиме.

Uzhast писал(а) 18. Октября 2007 :: 08:16:

А как на Фоксе в памяти работать? Не покажешь примерчик?
Просто я с OLEDB мало работал, а в ODBC такого не было.