Скрипты в java.js перестают работать.
 

Добрый день, друзья!
У меня порядка 6-10 простеньких калькуляторов, некоторые из которых с зависимыми селектами. В будущем размещаться калькуляторы будут на одной странице, а скрипты к ним размещаться в "java.js".
Столкнулся с такой проблемой:
Когда все скрипты положены в одном файле("java.js"), зависимости перестают работать.
В чем может быть дело? И вообще правильно ли так делать?
Возможно в моем случае лучше выкладывать все скрипты к калькуляторам в отдельный файл или может вовсе прописывать в той же form-е?

У всех калькуляторов нет совпадающих id и name, на которые ссылаются скрипты.

Сейчас: общий файл "java.js" и отдельные html-страницы(калькулятор1, калькулятор2).
Что бы работал: делаю отдельный файл "js_cal1.js" для определенного калькулятора, поскольку из общего файла не работают корректно.

Прошу помощи:help: .

Кашпировский отошел от практики.

Зачем вообще вам эти файлы? Постите скрипты в хтмле сразу после хтмля и не парьтесь кактусом.

oneplus,
нужен код

oneplus,
забыли бы вы о кодировке 1251 было бы проще, освоили бы консоль было бы ещё проще

где на вашей странице bsize_sel = document.getElementById("ban_size_id"), элемент с таким id? строка 43 пост 6

А, понятно, это эпическое продолжение усилий хардкорного РА наладить сайт по наружке.

Так делают колхозники не бывавшие в Смольном:

switch (a.lb_surface.selectedIndex) {
    case 0: surface=1030; break;
    case 1: surface=2120; break;
    case 2: surface=660; break;
    case 3: surface=0; break;
    case 4: surface=1090; break;

Так делают люди на заводах:

<option s="1030">Лабуда1</option>
<option s="2120">Лабуда2</option>
<option s="660">Лабуда3</option>
<option s="0">Лабуда4</option>
<option s="1090">Лабуда5</option>

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

Затем вместо switch (a.lb_surface.selectedIndex) пишут

var surface = a.lb_surface.options[a.lb_surface.selectedIndex].getAttribute('s');

И все. То есть не все, а вот если все переделать нормально, то роня проронит слезу.

Это калькулятор баннера, а страница хтмл(5 пост) - это калькулятор широкоформатной печати (пока калькуляторы отдельно по страницам).
6-ой пост это общий файл "java.js",
5-ый пост страница хтмл "широкоформатная печать" и скрипт к печати, который корректно работает только если поместить отдельно в java.js в единственном экземпляре. В сборе со всеми скриптами не работает.

После удаления на странице: <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
Теперь широкоформатная печать с чекбоксами работает.

Не прописанная кодировка на хтмл странице критично?

Удалил кодировку на всех неработающих страницах, по прежнему не работает Световые короба. Не удаляется селект. Тот самый)

С отдельным фалом js работает.

Кроме того есть json и при желании сделать все без привязки к элементам заводские делают так:

foo={
    surfaces:[1030,2120,660,0,1090],
    /* тут вся остальная бд */
};

var surface=foo.surfaces[a.lb_surface.selectedIndex];

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

Так и делают. Забивают хтмл данными и забирают их по обстоятельствам и по выбору. Либо в пресловутые data- теги, толку с которых как с козла сгущенного молока, либо в любые не занятые атрибуты как это делает всеми любимый JQuery кстати.

Ну вам же человек roni написал что надо открыть консоль скрипта и увидеть там ошибки обращения к несуществующим элементам.

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

Впервые слышу getAttribute('s'), обязательно учту, и рад бы написать "неколхозный" код, да не бывает все сразу.

Это полная жопа, конечно, а не программирование и теперь уже автор положивший столько сил на эту задницу никогда не решится переделать нормально. Нормально, по самому простому, делается примерно так:

var CalcBanner=function(opts){

   var bframe_sel = document.getElementById("ban_frame_id"),

   /* все остальное по тексту */

   /* Теперь надо вернуть что-то важное для взаимодействия функций */
  return {
    foo:foo,
    bar:bar,
    baz:function(){return baz}
   };
};

Теперь все такие функции можно спокойно положить в кучу и подключать через шаблон на всех страницах.

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

<script>calcbanner=CalcBanner({foo:bar,baz:975}) </script>
</body>
</html>

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

На словах пишется страшно, на деле в парадигме js - все очень просто. Это мля не php, тут вообще лафа с такими вещами,

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

(function(){

   var bframe_sel = document.getElementById("ban_frame_id"),

   /* все остальное по тексту */
})();

Из такой функции можно вернуть в window какие-то глобальные переменные если прямо внутри нее присвоить явным образом window[foo]=1060; Или такая функция может работать как тот самый контроллер по событиям на которые она навешала своих методов.

Это микроскопическая толика вариантов, js максимально аморфный и у каждого программиста для той или иной задачи есть свой стиль и свои решения.

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

По простому делается еще проще. Для каждой страницы есть свой специфический код, так? И каждая страница может юзать нечто общее как минимум для двух страниц, или заведомо общее, даже если пока что заюзано только на одной. Надо уметь обощать и сегрегирвать. Отделять мух от котлет в общем. Собрав в кучу все общие места, вы подключаете такой файл на всех страницах, одновременно подключая на каждой ту часть кода, которая ей именно нужна.

Это просто проще некуда.

Посмотрите как устроена страница гугля изнутри. Кто-нить после изучения внутренностей сайта дизайн.ру - гуглю под юбку заглядывал?

То есть страница на которой ровно 1 поле поиска - именно ее посмотрите.

Там стиль, скрипт, стиль, чуть-чуть хтмля, скрипт, стиль, скрипт, стиль, чуть-чуть хтмля, скрипт, стиль, конец страницы.

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

Забейте нах на все эти линк рел и скрипт срц - врубайте все прямо в боди там где оно именно надо и именно то, что надо и никаких проблем такого рода не будет.

Или вы думаете зафигом придумали атрибут scoped ?

Действительно, проще некуда:)
Спасибо за советы, прислушаюсь.
Проблему с некорректной работой калькулятор понял)
Думал яваскрипт просто читается по функциям, и что нужно используется, не смотря на то, какие элементы присутствуют или отсутствуют. Поэтому и не сразу понял какое отношение имеет отсутствующий "bsize_sel = document.getElementById("ban_size_id")".
:thanks:

Думаю так и надо поступить, меня сбило то, что все мной просмотренные примеры(большинство) по калькуляторам на сайтах (скрипты) лежали в отдельных файлах:)

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

Единственная проблема в этом - ваш хтмл должен быть безупречен. Достаточно пропустить где-нибудь " и парсер наедет на тег <script> всей своей мощью и такого там накомпилирует, что уссышься.

Это зависит от технологии. Если вы вручную собираете хтмл и ресурсы типа стилей и скриптов, то, конечно, в стопицот раз проще будет складывать все в большие файлы и врубать один раз на все случаи, иначе чтобы поправить скрипт или стиль вам придется править хтмл (шаблон например).

Если же хтмл делается скриптом на php, то и все остальные ресурсы php туда засунет как миленький из тех самых _отдельных_ файлов. Щас покажу

<style><?php $this->assets('css','catalog_promo.css');?></style>
<div class="promo">
<div class="promo-m"><?php echo join($items);?></div>
<div class="promo-o" t="Открыть"></div>
<div class="promo-b"><?php echo join($dots);?></div>
<div class="promo-bn"><i class="fa fa-chev-d"></i></div>
<div class="promo-bp"><i class="fa fa-chev-u"></i></div>
</div>
<script><?php $this->assets('js','catalog_promo.js');?>Promo();</script>

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

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

Паттерн - стиль-хтмл-скрипт - самый оптимальный. Загрузив стили браузеру вы сокращаете итерации - получив хтмл браза уже знает как что рендерить. Ну а скрипт и должен быть после, чтобы все, что он начнет щупать - уже было в DOM'е

Метод $this->assets() - обычный загрузчик кеша с фичей минимизации текста. Открыл файл, сравнил даты, если исходник свежее - минимизировал, записал и выдал в буфер текст. По опции может возвращать текст - что важно для рендера объектов через __toString();

Кстати вот

t="Открыть"

а в css

promo-o:before{
   content:attr(t);
}

Как видите атрибут может быть любым.

Про атрибуты.

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

Все трефовые атрибуты, то есть которые браузер нипонял - никуда не деваются, они общедоступны через стандартный метод getAttribute(name); Если указанного имени нет, вернется null, или "", не помню, от браузера еще зависит.

Что-то я о подобном не слышал. В jQuery есть метод data(), который умеет читать и писать данные в атрибуте data-, но чтобы в любые "не занятые" атрибуты, это не. Конечно быдлокодер может придумать свой атрибут, например s и записать туда всё что угодно, но тут уже не в библиотеке дело.

И последнее, где рендерить. Варианты: сделать запрос к бд или получить конфиг из массива и отпостить его в браузер json'ом - по полученным данным все нарисовать. Или нарисовать на сервере со всеми атрибутами и выдать в браузер.

Разница в том что создав элемент вы сразу получаете его как таковой. Его не надо искать и проверять есть или нету такого в доме. Не надо думать про id и кучу атрибутов не надо поднимать. Созданные элементы втыкаются в тот же полученный из json объект и автоматически связываются со связанными данными. Теперь все что вам нужно от созданного элемента - его value, или там индекс, чтобы взять нужные значения из нормального ассоциативного массива или как на js - объекта. Следовательно у вас всегда нормализованные данные, а рендер может быть любым. Сегодня это select options - нажали кнопку в браузере - получились ul li.

Все шиколадно за исключением собственно геморроя с рендером в js. Во-первых туда все равно надо положить html, иначе будет чудесатая иерархия профтыкания дерева - html это же иерархическая структура. Если описывать хтмл на месте, задолбают непонятные интерпретатору переносы в скалярх. Либо придется писать все в одну строку - типа вручную минимизировать, либо дробить строку на куски с конкатенацией.

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

То есть нихера не проще если серьезно подходить, те же яйца вид сбоку.

Потому что вы никогда не читали документацию на JQuery. Мне за вас почитать и процитировать?

Это будет двойной фейл, потому что я не польуюсь JQuery.

Значит быдлокодеры и написали JQuery.

Быдлокодеру. Что такое HTML вообще? Это попсовый XML, DTD которого называется спецификация от консорциума. То есть для всего народа сделан DTD с некоторыми девиациями по разным причинам и земшарное сообщество спокойно юзает этот тип не задумываясь о преобразованиях - браузер преобразует однопенисуально для всех. Более того, разница в преобразовании вызывает бурю негодования, особенно в отношении такого сказочного долбо...а как IE.

Преамбула ясна? А что такое тогда XML? Это абсолютная свобода в рамках простой иерархии из тегов и отношений в атрибутах. Теги могут быть любыми, атрибуты могут быть любыми.

Так вот все что отвечает DTD по тегам и атрибутам в HTML, браузер как бы должен но не обязан зохавать, пережевать и выдавать в клювик программисту. А все что не отвечает DTD - не обязан рендерить и компилировать, но выдавать AS IS - обязан.

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

Понятно где быдлокодеры, а где слаще морковки ничего не ели?

ЗЫ Ну а чтобы свои атрибуты и теги рендерились как-то и компилировались куда-то, вам всего-навсего нужно сделать свой DTD например на языке XSL чтобы получить HTML, иначе браузер ничего не поймет. В своем собственном приложении вы можете рендерить XML вообще как угодно.

И самая мякотка что собственно для этого и был сделан XMLHttpRequset, чтобы получать XML и JS'ом его рендерить без геморроя с XSL. Народ и этого ниасилил и постит JSON.

Это было бы прекрасно. Есть метод attr(), который позволяет создавать атрибуты, записывать и читать из них данные, но чтобы jQuery на уровне ядра использовала "не занятые" атрибуты, о подобных чудесах я не слыхал :blink:

процетируй соколик, чай не переломишься с натуги.

Это не обязательно, современные браузеры и так позволяют писать любые теги и любые атрибуты, и это всё работает, правда валидатор w3c ругается на них, ну да хрен с ним. Тыкните меня носом в доки jQuery, где описано, как она использует "не занятые" атрибуты.

Меня эти быдлокодеры задолбали не только в РСФСР. Понимаете, когда начинаешь изучать новое, первым делом читаешь этих светочей, которые понапишут о канонах х знает что, ну, что по их мнению кошерно и обосрут все что не по нраву.

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

<body class="hp" onload="...

Это с гугля, с google.com, явный разрыв шаблона непрерывности. Кроме того онкликов там как гавна.

Ну и вот это что такое - jsaction="foot.cst">Settings</a>

То есть гуглю можно, а остальные должны сосать у светочей?

Вы вообще не понимаете о чем речь. Писать-читать это мастхэв само собой и ТС должен об этом знать чтоб такое гавно не писать. Пусть пишет data-, никакой разницы с d или s, если пользоваться только getAttribute() и ничем иным.

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

Для тех кто не в курсе - гугля пишется не в нотепаде++ и не в сраных IDE. Достаточно одного взгляда на их сырец, чтобы увидеть - все проходит через мощный дизайн-тайм компилятор. Ну и собственно я не утверждаю что у них тоже есть быдло, поскольку в одной странице может быть скомпилирован код сотни кодеров, и какие-то там есть и быдлы. Но практика просто доказывает что быдло - это правЕльные программисты.

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

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

Вспомнил чем оборачивается попытка заюзать компилированные атрибуты. Надо знать во что превращаются их имена в DOM'е. Если вы написали в html - maxlength, то в из дома должны ловить maxLength.

Вот накатал код:

<my-tag palevo='В Гугле одни быдлокодеры!' style='color:red;'>Я люблю корпорацию Гугл!</my-tag>  

<script>
var myTag = document.getElementsByTagName('my-tag')[0];
alert(myTag.getAttribute('palevo'));

</script>

В Хроме и Мозилле всё рендерится и исполняется, в остальных не проверял. Специально style добавил, чтобы было видно, что браузер умеет с этим тегом работать.
P.S. В Гугле одни быдлокодеры, jQuery тоже они написали, но слава Богу есть kostyanet, готовый в любой момент сорвать покровы с этих мракобесов! :cray:

Ему х объяснишь. Больше чем чтение-запись Сигизмунд ниасилил.

Впрочем, может еще раз? may-tag какого типа - блочный или инлайновый? каковы у него отступы и поля по умолчанию? может есть обводка или заливка каким-то цветом? Так понятно? Тогда если добавить атрибут palevo можно будет увидеть как поменялась обводка или заливка?

Естественно у кастомного элемента всего этого нет, это через css настраивается. Касательно атрибутов: что ещё с ними можно делать, кроме как писать/читать из них?

Блеат, ну так про то и был базар - чтоб оттудова читать, прежде записав.

Второе. Если категорически не прибегать к помощи DOM при чтении значений атрибутов, что выводит всю систему на единый паттерн, то какая разница какой там будет атрибут если он не из стандарта?

Потому что в стандарте появится такой и ему повешают какую-нибудь презентационную или поведенческую роль?

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

Я не против data-, но я и не против s или t. ПОтому что эквипенисуально оно.

Кстати стандартные глобальные атрибуты регулируют любой нестандартный тег в хтмл-5 браузерах.

Насчет вернуть из авто-функции в глобал, на самом деле вот так надо

(function(){window.google=

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