Календарь

  • Автор темы Автор темы JohnLemon
  • Дата начала Дата начала
Baneslaer, берёшь, удаляешь свою базу, потом берёшь ресурсы, допиливаешь её до состояния своей базы (кстати, а с чего вы взяли что резервация делается для людей из АК?), и получаете теже 90% вьюх, которые у вас есть, и, опятьже, думаете как в графическом виде показать почасовую занятость по койкам в разрезе неделя/месяц/3месяца/год, т.е без шага вперёд делаем несколько шагов назад (+ полный выход по внешнему дизайну от всего комплекса ЭДО, работы с ОС и т.д.)
Уже знаю следующее предложение, делать резервацию используя стандартную, соответственно можно использовать шледулер для графики. На самом деле, этот момент обсуждался вот тут https://codeby.net/threads/54120.html. Также по следам обсуждения по ссылке могу сказать, что на данный момент
1) колонка с иконками провалилась. Причин несколько. а) не более 10-ти иконок в столбце (получается либо 3-ри колонки чтоб показать одни сутки, либо делать бешенное кол-во специализированных иконок, для своего случая, я насчитал около 64-рёх (одна иконка перекрывает 3-ри часа с 2-вумя статусами на каждый час + бешенный рост кол-ва иконок, если надо добавить пол проживающего и т.п. а это 100% будет в будущем, не первый год делаю базы, и прекрасно знаю в каком направлении у клиента будут расти хотелки, а превращать программирование в рисовании нескольких тысяч иконок(хотя, в этом случае, уже имеет смысл, либо кодом рисовать, либо переключиться на формировании картинки) )) б) весёлое ограничение вьюхи. Оказалось что во вьюхе, при колве иконок более 4т (вроде 4тысячи, точно не помню) иконки перестают показываться.
2) идея с джавой отметена. Причина не совсем в даной реализации, а в том, что я попробовал апплеты ещё для одного момента (показ апплета в оутлайне, совершенно для другой задачи), и работа крайне не стабильная. Соотвественно переключаться на апплеты, для одной задачи, не интересно
3) выбран вариант с хпагесами (да-да, то что мне предлагали по ссылке, просто оказалось, что в хостеле стоят достаточно мощные машинки, и, вполне нормально, на них, можно поставить RTC клиента и не мучаться). Клиенту предъявлен счёт на данную реализацию, клиент сидит и думает, нужно это ему или нет (просто в самой реализации базы, есть поиск свободных коек, который по заданному промежутку времени, проверяет брони и показывает свободные койки+ информацию, если в данном помещении есть другие брони с отличным от текущего пола проживающего, то кол-во проживающих, которых придётся расселить).

в третьем варианте, реализация идёт за счёт рипит-контролов, достаточно легко и просто (а вопрос к "Джону", по тому что у меня подобная проблема, не более чем язвительный). простой прототип сделан, работает. Далее нет времени его доделывать, если клиент не будет платить (просто сейчас делаю базу ОРД(приказы, уставы и т.д. всего около 11-ти типов документов) за которую клиент платит, и она ему нужна + заказчик вменяемый(более 10-ти лет работает с доминохой), соотвественно в ТЗ нет "хочуусё в одном месте чтоб бибикало и вертелось!" Заказчик прекрасно понимает парадигму Доминохи, и отлично знает все её плюсы, и давит именно на них. Короче редкий заказчик... Помимо этого, ещё по 3-рём базам, аналитики, собирают инфу с клиентов. Т.е. нет времени на то, за что платить не будут. А в свободное время, потихоньку, переделываю веб интерфейс ХелпДеска под ХПагесы. Денег никто не платит, такой подарок ТехОтделу)
 
1. регистрация в АК, только для того, чтобы использовать стандартный механизм BusyTime.
Если не подходит такой подход, делайте по-другому и считайте сами часы и т.д. и сохраняйте в каком-то виде.

2. Как показать в графическом виде. Чем вьюха календаря с бронированием по определенному помещению не подходит?
Ну или сделать экселевский шаблон, который по данным в него выгруженным создаст понятные заказчику графики в любом разрезе + при необходимости, сводные таблицы.

3. Чем вводить миллион колонок в системе не проще ли сделать отчеты в разрезе потребностей заказчика? А кол-во колонок и вьюх должно быть небольшим и удовлетворять пользователя хотя бы на 90%.
 
1) про это говорил, нет необходимости регистрировать в системе пользователя, который на сутки заехал
2) она покажет только тот момент, что помещение занято, а у меня, как-то, параметров занятости поболее(первое приближение бронь/заезд, далее, параметры будут расти, уже сейчас, маячит "пол", дополнительно нормальные/беженцы с украины, далее спец подстветка оплаты и т.д. шледулер это показать не сможет...).
3) никто не говорит о миллионе колонок. одна сводная вьюха по 100-та документам, ну да, если брать недельный разрез, это 21-на колонка(по иконкам, на данный вариант я давно отбросил).
Я так посмотрю у вас приверженность выгрузки в эксель. Что будете делать на лялихах, или огрызке (на джаве лопатить выгрузку в эксель?)? хпагесы, вполне решают данную проблему.
 
>>Я так посмотрю у вас приверженность выгрузки в эксель

Давай-те смотреть правде в глаза. Рано или поздно им будут нужны отчеты. А отчеты большинство предпочитает смотреть в Excel или его аналоге. Или вы думаете заказчику не нужны будут выгрузки никогда?
Судя по остальным вопросам, насколько я понимаю, у вас нет никакого ТЗ, а только отрывочные требования. С таким подходом эту базу вы будете делать вечно и заказчику вечно в ней не будет чего-то хватать.
Посоветовал бы сначала согласовать требования с заказчиком, а уже потом делать.
 
Поставил библиотеку Extension Library, inotes calendarвыглядит так (во воложении). Может кто подсказать что с ним еще можно делать кроме как смотреть на него ), есть ссылка или может кто объяснит как данные к нему прикрутить ???
 

Вложения

  • 123.png
    123.png
    10,1 КБ · Просмотры: 515
так, для справочки, я уже не первый год замужем. ТЗ по базе делалось в мой отпуск, т.е. без меня (еслиб делалось ос мной, то выглядело-бы по другому. Вообще ситуация весёлая, вроде с той стороны есть люди которые в гостиницах до этого работали, но у меня есть мнение, что они там наволочки меняли. То тз, которое есть, вообще не учитывает дофига моментов, но на данный момент, базу вообще нужно запустить, чтоб они, тупо, привыкли к лотусам, а не к раскрашиванию портянки в экселе во все цвета радуги).
Отчёты, сотрудникам хостела не нужны, т.к. их деятельность, легко смотриться по вьюхам ("голова" сидит в другом офисе, и с лотусами работают не первый год, им не нужны отчёты по кроватям, им нужен денежный поток. Далее, этот денежный поток, уже, вливается в центральную базу ДДС, где ведутся все расчёты, да и база делалась как "облегчаловка" для сотрудников, но не хостела, а именно центрального офиса, вроде народ работает с кроватями, а, реально, вбивают поступления, тем самым ситеметизируя данный момент + контроль ошибок со стороны работников)
Вообще отчёты делаются, но мы умеем убеждать клиентов, что они им не нужны, и им реально нравиться (проблема достаточно простая, делаешь отчёт, значит твоя система не достаточно удобная, вывод данных за пределы базы это 1) возможность утечки информации(а половина клиентов на этом сильно помешана, некоторые, на такой фигне попадали неоднократно) 2) не актуальность данных (с утра сделали выгрузку, а вечером, когда кто-то начал читать эксель, в базе уже 100500 раз всё поменялось) 3) не актуальность данных, очень часто было с "распечатками" (начальство смотрит, делает планы, а тут херакс! а бумажка-то за прошлый месяц) 4) тупая подделка данных (для того чтоб колоночки сходились, народ, в экселе, тупо цифры меняет, уже столько скандалов с этим было, просто ужас) ) ;) Реальные отчёты, только "внешние". Ну для строителей идут их кварталки в мерию (когда идёт отчёт по строительству, сколько денег получено, договоров заключено и т.д.), для других компаний, к примеру, есть спец отчёты для банков, когда банки, для кредитов, требуют свои отчёты. Но такие отчёты единичные.
Ещё про ТЗ много историй могу рассказать (в т.ч. про 22-ве перпендекулярные линии). Обычно, когда пишутся первые ТЗ у клиента, они Лотуса вообще не знают (только папки и эксели), и не могут принять её парадигму. После первых 2/3-рёх баз, народ, уже, понимает что это такое, с чем его едят, и ТЗ идут более нормальные, с внятными желалками (иногда такие желалки выдают, что не понимаешь, почему сам не додумался). К примеру делали ХД для банка, ТЗ переписывалось раз 20-ть, база делалась около 3-рёх месяцев (хотя по плану было около 2-вух недель). Там тоже отчётов было много. Срались очень долго, когда сделали им один из отчётов по реальным заявкам, народ понял, что это крайне неудобно (в ексель переносить дерево ответов, это трындец, а без него никуда). Когда начали оптимизировать, когда поняли что им нужно, тупо сделали простую вьюху, где в разрезе некоторых классов задач видно сколько они делались. Управление было счастливо, поссорились с админами (т.к. когда была видна их работа, они таких люлей получили. Но, потом, они сооринтеровались, по их заказу базу подправили (т.к. по базе, они смогли увидеть в реале из-за чего они сами просирают), и стало видно из-за чего у них тормоза (зависимые задачи), тогда начали получать люлей другие отделы)
Вот как-то так, а вы эксель...
 
JohnLemon сказал(а):
Поставил библиотеку Extension Library, inotes calendarвыглядит так (во воложении). Может кто подсказать что с ним еще можно делать кроме как смотреть на него ), есть ссылка или может кто объяснит как данные к нему прикрутить ???
Нажмите, чтобы раскрыть...
Может по календарю подскажет кто ??
 
о, блин, похоже календарь-то работает с JSON-ом... Сложно будет делать...
Ссылка скрыта от гостей

Ссылка скрыта от гостей
 
>>1) возможность утечки информации(а половина клиентов на этом сильно помешана, некоторые, на такой фигне попадали неоднократно) 2) не актуальность данных (с утра сделали выгрузку, а вечером, когда кто-то начал читать эксель, в базе уже 100500 раз всё поменялось) 3) не актуальность данных, очень часто было с "распечатками" (начальство смотрит, делает планы, а тут херакс! а бумажка-то за прошлый месяц) 4) тупая подделка данных (для того чтоб колоночки сходились, народ, в экселе, тупо цифры меняет, уже столько скандалов с этим было, просто ужас) )

Вот это вы сказанули. Давайте по пунктам:

1. А если человек заберет всю базу(созданием копии/реплики ну или принтскринов наделает). Чем не утечка информации?
2. Для этого в самом экселе при выгрузке пишут дату и время выгрузки, чтобы у пользователя они были перед глазами. И было понимание на какое время актуальны данные.
3. смотрите п.2
4. а после выгрузки заблокировать книгу Excel от изменений и поставить на нее пароль слабо чтоль? И подделок не будет
 
Ty3uK сказал(а):
о, блин, похоже календарь-то работает с JSON-ом... Сложно будет делать...
Нажмите, чтобы раскрыть...
Можешь сказать это куда девать ))
Код: 
{
"@timestamp":"20120311T171603",
"@toplevelentries":"3",
"viewentry":
[
{
"@unid":"37F0330979C04AF2C12579BE004F5629",
"@noteid":"32E1A",
"@position":"1",
"@read":"true",
"@siblings":"3",
"entrydata":
[
{
"@columnnumber":"0",
"@name":"$134",
"datetime":
{
"0":"20120314T100000"
}
},
{
"@columnnumber":"1",
"@name":"$149",
"number":
{
"0":119
}
}, etc...
 
1) копирование/репликация запрещена. От скриншотов никто не защищён, но это не повод ложить большой болт на безопасность.
2) делали, не помагает, человеческая невосприимчивость к датам (отчёт за такое-то число, такое-то время, такой-то формировал... пофик, никто эти поля не смотрит, пока не накричаться, и только после "разноса": "упс, а с каго спрашивается, данные за вчера?")
4) ээ.. а вот до этого не додумались. ;) (как меня задолбало, я, блин, что, единственный кто у нас в фирме думать будет?)
 
Харе в тему спамить ) подскажите лучше куда это деть ???
Ссылка скрыта от гостей

Код: 
{
"@timestamp":"20120311T171603",
"@toplevelentries":"3",
"viewentry":
[
{
"@unid":"37F0330979C04AF2C12579BE004F5629",
"@noteid":"32E1A",
"@position":"1",
"@read":"true",
"@siblings":"3",
"entrydata":
[
{
"@columnnumber":"0",
"@name":"$134",
"datetime":
{
"0":"20120314T100000"
}
},
{
"@columnnumber":"1",
"@name":"$149",
"number":
{
"0":119
}
}, etc...
 
JohnLemon сказал(а):
Можешь сказать это куда девать ))
Нажмите, чтобы раскрыть...
да никуда это не девать, по выхлопу видно что это одна запись в вьюхе. Это формат JSON. Для тебя будет слишком сложно, с пол-пинка это понять.
вот примерчик, создай xpages внутрь затолкай вот это:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xe="http://www.ibm.com/xsp/coreex">

<xe:restService id="restService2" pathInfo="/inoteslegacyjson"
preventDojoStore="false">
<xe:this.service>
<xe:calendarJsonLegacyService viewName="xview" var="entry" contentType="text/plain" colCalendarDate="CalDateTime"
colStartTime="StartTime" colEndTime="EndTime" >

</xe:calendarJsonLegacyService>

</xe:this.service>
</xe:restService>
<xe:calendarView id="calendarView1" jsId="cview1" type="W" storeComponentId="restService2"></xe:calendarView>

</xp:view>
сделай вьюху (обычную, название xview), в ней две колонки, одна называется StartTime, вторая EndTime, содеожание дата/время (соотвественно даты старта и даты конца). далее нашлёпай пару документов которые в этой вьюхе будут просматриваться, после этого можешь посмотреть что будет в хпагесе. Как видишь (надеюсь) стоит restservice он для календаря готовит данные (на основе вьюхе).
Далее, сам разбирайся ;) Вектор я тебе дал...
Ссылка скрыта от гостей
 
Далее, сам разбирайся wink.gif
Нажмите, чтобы раскрыть...
Да в том то и дело много не понятно я уже пытался по примеру делать с extantion liblary идет нифига, где то затык. Вьюшка обычная должна быть или календарь ? вот это с чем связано jsId="cview1" ?? var="entry" зачем ?pathInfo="/inoteslegacyjson" что за папка.
Вот мой конфиг
Код: 
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xe="http://www.ibm.com/xsp/coreex">



<xe:restService id="restService2" pathInfo="/inoteslegacyjson"
preventDojoStore="false">
<xe:this.service>
<xe:calendarJsonLegacyService viewName="xview" var="entry"
colCalendarDate="CalDateTime" colStartTime="StartTime"
colEndTime="EndTime">
</xe:calendarJsonLegacyService>
</xe:this.service>
</xe:restService>
<xe:calendarView id="calendarView1" type="W" jsId="cview1"
storeComponentId="restService2">
</xe:calendarView></xp:view>
Вью во вложении. Что не так то уже не пойму календарь пустой (

Добавлено: Как можно проверить что получает restservice

И самый главный вопрос как выделить день в календаре если просмотр сделать за год ))) ?????
 

Вложения

  • Безымянный.png
    Безымянный.png
    3,5 КБ · Просмотры: 602
  • Безымяннeqwый.png
    Безымяннeqwый.png
    14,9 КБ · Просмотры: 448
знаком с понятием программное имя колонки?
Дополнительно, я не уверен как будет работать функционал, когда пытаются показать одну минуту. + колонки отсортированны?
 
Ty3uK сказал(а):
знаком с понятием программное имя колонки?
Нажмите, чтобы раскрыть...
Нет не особо )
С тем разобрался показывает уже норм, подскажешь можно ли сделать что нибудь с календарем который на год отображает, хотя бы дни выделить) ?
 
что-то мне подсказывает что с помощью данного контрола не получиться... такое чуство, что на год вообще нифига не показывает ;)
Соотвественно, либо трясти "susinmn" как он делает с помощью dijit.Calendar, либо самому с ним разбираться, либо, как я говорил ранее, делать самостоятельно свой контрол (ка делать, вроде, уже говорил, используя рипитеры. для начала, советую попробовать с одним рипитером, который показывает дни в этом месяце (желательно, чтоб месяц был вынесен в переменную, потребуется позже, для "расширения"). Потом к данному рипитеру, подцепить документ, и посмотреть как с документом работает, далее, создать репитер по месяцам текущего года(внутри предыдущий репитер, в который будет передаваться месяц, который нужно показать)).
 
;) это один из основных контролов в XPages который называется Repeat.
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ