if – else if – else

[laimas]

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

Предупреждайте, делайте как знаете, мне в общем то без разницы.

[Besprizornik]

laimas,
в зачем приводить количество дней к текущему месяцу в форме для ввода/выбора? чтобы показать пользователю сколько дней в месяце и тем самым заставить перейти к выбору месяца а потом опять вернуться к выбору числа и добавить ему лишней мороки?

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

[laimas]

Besprizornik, у вас какая-то логика не понять.

Если бы было нечто, что само по себе догадалось, что дата некорректная и раз alert("Ты че?"), это было бы без затратным решением. Но такого нет, для того чтобы сообщить что есть ошибка, нужно все проверить и выдать сообщение. То есть хотите вы того или нет, вы обязаны каждый ввод проверять.

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

Оба этих подхода вынуждены будут выполнять одни и те же действия, только первый пугает сообщением, а второй исправляет ошибки.

У меня нет времени чтобы писать подробности, но список дат можно формировать динамически, можно прятать лишние дни, можно блокировать доступ к лишним дням. Все это решения, но они вас просто пугают, либо вы не понимаете о чем речь.

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

[Besprizornik]

laimas,
что непонятного в моей логике?
объясни мне такую вещь, ну привели мы количество дней к текущему месяцу, допустим февраль-28, и что получилось?
приблизительно ситуация выглядит так посетитель нажал на селект с числом и видит 28 опций, он хочет ввести 31 марта, но не может этого сделать из-за отсутствия 31ой опции, ему придётся перейти к селекту с выбором месяца а потом вернуться к выбору числа, или есть какие то варианты прочесть мысли посетителя и в нужный для него момент показать 30 опцию для ввода 30 апреля а в тот момент когда он захочет ввести 31 мая добавить 30ую и 31ую опции

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

[laimas]

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

Хорошо, примем понятие "логика" как понятие философское, ну или по вкусу, как кому нравится. Но сначала давайте вообще о понятии дата/время.

Вы в своей программе вы вряд ли даже станете задумываться над тем, что это такое вообще. Да, вы держите в уме два календаря, но только лишь всего. А между тем, дата/время это особенный тип данных, имеет множество представлений и может возвращаться в разных языках программирования величиной соответствующей контексту запроса. Время измеряется в количестве секунд прошедших с полуночи 1 января 1970 года по UTC (начало эпохи Unix). В Javascript это значение измеряется в миллисекундах, то есть помноженное на 1000.

Есть одна особенность объекта Date, его можно вызвать как функцию, без оператора new, и это всегда будет возвращать строку о текущей дате и времени:

alert(Date())

Но вызов объекта и как конструктора таким же образом выведет тоже самое:

1)

alert(new Date())

А теперь фокус:

2)

alert(new Date()*2)

А вот так будет неудача:

3)

alert(Date()*2)

А вот так добавим 30 дней:

4)

alert(new Date() + 1000 * 60 * 60 * 24 * 30)

Причем это будет работать даже если мы вызовем объекта как функцию, в отличии от 3):

5)

alert(Date() + 1000 * 60 * 60 * 24 * 30)

Интересно да? Все потому, что "внутри" объект понимает и знает этот тип данных во всех его деталях, и соответственно реагирует на запросы. То есть ему не составит труда исправить "ошибку". Но нужно все-таки оговорится - если вы привыкните к этому и будет думать, что это закономерность, то вас вполне может ожидать неприятный сюрприз.

Коли вы уж впряглись в веб программирование, то вполне можете оказаться и по другую сторону баррикады - на сервере. В зависимости от языка программирования на сервере, функций для работы с этим типом данных может быть различное множество, например их масса в РНР, есть готовые функции календаря для перевода дат из одного формата в другой. Основой этого календаря является исчисление с Юлианского дня.

А вот работая с базой данных, которая конечно же, также должна уметь работать с датой временем, вы столкнетесь с различным ее представлением в базе - типом. В контексте что вас "может ожидать сюрприз" возьмем тип TIMESTAMP. Этот тип есть временная метка в секундах, то есть тоже что и возвращает объект Date(), но в секундах. То есть внутренне представление этого типа, это число от 00000000000000 до макс. значения с которым может оперировать системное время (была когда-то острая проблема - начало нового тысячилетия).

И также как в JS, просто выборка даты из поля этого формата вернет строковое представление даты. Но мы то знаем, что внутреннем представление, это число. Но тем не менее, чтобы получить эту дату как метку времени, нужно явно указать в запросе это функцией UNIX_TIMESTAM(). В тоже время, SQL как и многие языки, в том числе и Javascript могут налету преобразовать один тип данных в другой. А кроме этого, SQL имеет и иные типы данных, которые являясь строковыми, во внутреннем представлении являются числами. Это типы ENUM и SET, которые по аналогии можно для простоты сравнить со списками, где первый тип, это список с одиночным выбором или связанная группа радиокнопок, а второй список с множественным выбором или набор флажков. Если тот и второй тип равен "первый,второй,третий", то запрос значения как есть вернет строковое значение - для первого одно из трех, что установлено, а для второго набор который установлен. Но если при запросе к полю имени прибавлять 0, то для первого вернет значение от 1 до 3, соответствующее установленному значению, а для второго битовый набор. И при вставке/выборке можно оперировать числами, а SQL все корректно сделает.

А как же с TIMESTAMP, о котором мы знаем, что внутренне представление этого типа тоже число? А вот так. Допустим есть в SQL функция BETWEEN, она позволяет описать проще выборку по условию A >= N AND B <= M. Если в запросе написать - BETWEEN N AND M, даже если в качестве N и M, мы укажем корректные метки времени, то запрос ничего не вернет. Казалось бы, все соответствует и должно, но тем не менее и тут нужно указывать явно что мы хотим, то есть BETWEEN FROM_UNIXTIME(N) AND FROM_UNIXTIME(M). Казусы могут быть и в JS, тут еще и браузеры различные свою лепту вносить в раздрай будут.

А теперь еще об одном касающегося типа дата/время, которое представлено строкой, хотя это не связано с тем, что это именно дата/время. Тем не менее - нельзя сравнивать даты как строковые значения, если дата не представлена в европейском формате, то есть "YYYY-MM-DD". Результат сравнения будет неверным, это следствие сравнения строк, содержащих в себе как цифровые, так и не цифровые символы. Что нужно отметить в этом случае, при сравнении строковых значений дат, то что возвращение верного результата сравнения дат при европейском формате обуславливается тем, что дата записана ее элементами от старшего (года) до младшего (дня). Это мы пока держим в уме.

В общем тип данных дата/время многогранен, вам как разработчику и нужно, и полезно знать такие вещи. Но только вам, пользователю они и не нужны, да и неинтересны. Их может заинтересовать только история этого типа данных, которая очень богата - почему в месяцах по 30 и 31 день, а в августе и сентябре по 31, а в феврале вообще то 28, то 29, календари и т.д. Вся кухня программная скрыта от пользователя, но...

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

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

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

Вот приложение календарь:

<input type="date" />

Его интерфейс при своей простоте удобен для пользователя, интуитивно понятен, выбор элементов управления есть предсказуемый результат, не позволяет ошибок при управлении через элементы управления. А ручной ввод не позволяет выбрать в нем введенную некорректную дату. Попробуйте найти в нем в текущем месяце день 31 марта чтобы выбрать его. Этого нет, ибо это нелогично, а значит и интерфейс приложения автоматически предоставляет пользователю дни только текущего месяца. Для выбора диапазона дат служат сдвоенные календари или календари имеющие такую функцию.

А теперь извлечем из памяти европейское строковое представление даты. Как уже говорилось, корректность сравнения дат в строковом представлении европейского формата в представлении ее от старшинства элементов даты. Так и в календаре, если нужно выбрать март 31, то сначала нужно выбрать месяц март, и это вполне естественное действие к которому все привыкли. Это естественное и заложено в логику приложения, которое обеспечивает подобающий этой логике интерфейс. Разработчики этого приложения как раз ориентировались на предсказуемость поведения пользователя, а единственная возможная непредсказуемость, которая может возникнуть при ручном вводе даты, блокируется приложением. И заметьте, без сообщений, просто отмечая окно ввода красным, что уже дает понять о наличии ошибки, а при вводе корректной даты она будет выбрана в календаре.

[laimas]

А что у вас представляет интерфейс. В общем ничего, его нет как такового, если учитывать его составляющие. В вашем приложении данные типа дата живут своей жизнью, а элементы управления своей. Текущая дата не обязательно соответствует набору элементов управления. Вы как бы переложили решение всех проблем на плечи пользователя. О каком удобстве и предсказуемости можно говорить в этом случае?

Ну допустим, ваш интерфейс, это по принципу "максимум возможного - кашу маслом не испортишь". А вы задавались вопросом - все ли наизусть помнят сколько дней в каком месяце? Если пользователь видит 31, а на самом деле в этом месяце всего 30 дней, то вправе ли он верить вам, что в этом месяце действительно 31 день? А если так, то это предпосылка к ошибочному действию пользователя, и эту предпосылку заложили вы и в логику своего приложения, и в ее интерфейс. Хотите сообщать пользователю о таких ошибках? А зачем их создавать, где же логика?

Ну допустим, все знают дедовский метод определения дней месяцев по косточкам пальцев. И пусть это, заставляющее пользователя перед выбором обращать взор на свой кулак, и уже говорящее о необдуманности логики и интерфейса приложения, примем как за фишку приложения, пусть смотрит на кулак, узнает сколько дней в месяце, а затем выбирает нужный последний день. Но встает вопрос о феврале - а сколько же в нем дней в текущем году? Разделить по модулю 4 текущий год? Многие уже умножать в уме разучились, а что такое деление по модулю и тем паче не знают. Но это еще пол беды, а беда в том, что високосные года, это не просто только те, что делятся на 4 без остатка, но также не делящиеся на 100, за исключением годов делящихся на 400. Нихилая математика для пользователя, не так ли?

Говоря об интерфейсе вашего приложения, нужно скорее говорить о непредсказуемости его, а не пользователей. Об удобстве пользования им и ожидаемом поведении вообще не приходиться говорить, это вообще отсутствует.

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

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

[Besprizornik]

laimas,
ну первое что я могу сказать, ещё раз спасибо, много нужного и полезного для меня ты изложил причём очень подробно, я конечно же учту в будущем..

второе, отступлю от темы и приведу пример из жизни, года полтора назад я оказался очевидцем, как мама учила писать и читать свою дочь-дошкольницу, вопрос это какая буква, ответ 'эн', а это какая, ответ 'а' а вместе, ответ 'незнаю', запомни 'на', потом с минуту вопросы по другим буквам алфавита, ответы правильные, дошли до 'н' потом 'а' вопрос а вместе, ответ 'незнаю' сцена продолжается минут 15-20 с одинаковым результатом...
наивно ведь полагать что первоклашка напишет сочинение для старших классов хотя бы на оценку 'удовлетворительно' и тем более уложится в 45 мин урока...

всему свое время, а теперь давай вернемся к первому посту темы...

[Besprizornik]

вот цитата

Есть строка

d = new Date(new Date()-X*24*60*60*1000);

где X это числом и может быть от 10 до 15, я понимаю что тут надо применить конструкцию if – else if – else, кто нибудь может объяснить на словах что сейчас нужно сделать, создать функцию? или массив? или переменную? или ещё что?

я попытался через операторы отобразить при каких условиях чему равно Х

просто на словах объясните что сейчас делать, что читать и что искать...

[Besprizornik]

попытаюсь объяснить на пальцах, что самым оптимальным вариантом было бы;

да надо создать переменную 'х' и присвоить ей разные значения при разных условиях, эту переменную так и оставить в строчке.

var x;
var ulDate=new Date(1600,1,9);
if (ulDate>=new Date(1582,9,15)&&ulDate<=new Date(1700,02,11)) x = 10;
else if (ulDate>=new Date(1700,02,12)&&ulDate<=new Date(1800,02,12)) x = 11;

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

[Besprizornik]

laimas,
а что если допустим сделать так, показать в селекте для выбора числа всегда 31 опцию, но выделить цветом лишние опции для текущего месяца если такие имеются, ну то есть если в текущем месяце 28, 29, 30 дней?