vittly: оптимизации js не существует. Есть мнение, что "Чем код короче, тем быстрее работает". Но это мифы. Быстрее загружается - да. Субъективно в целом страница работает быстрее - да.
kn1ght_t: Не могу. Я не понимаю конкретного примера, когда:
1. Событие onsubmit сработало.
2. Форма не была отправлена.
Или вы говорите о случае, когда форма отправляется без валидации на стороне клиента, а на сервере проходит валидацию и возвращается обратно ? Тогда это совершенно другая история и цель должна достигаться на странице, которая рендерится только после успешного подтверждения формы.
Дениска Кривощеков: В посте я вижу 3 вопроса. Два из которых - "как получить день и месяц из даты", третий - про то, как хранить. Причем, в заголовке - один из тех двух.
Ничего личного, но тут лучше посоветовать именно научиться гуглить и ставить правильные вопросы. Но таких советов здесь предостаточно
eldar_web: А какой смысл делать из сервиса - очередную прослойку перед документацией?
Не знаю, какие там планы у руководства тостера, но хотелось бы, что бы в них входило качественное развитие аудитории (как, например, задумано на stack`ах)
Сами подумайте, вы вот сейчас что-то "учите". Вам хочется через год остаться на том же месте или же узнать что-то новое, более сложное ? А когда Вы это узнаете, не хотелось бы расти дальше ? А для этого нужно так же задавать вопросы.
И вот если поощрять ответы, которые копируют документацию или просто ссылаются на нее -то на вопросы более высокого уровня вам никогда не ответят.
Зайдите в профили тех, что часто отвечает на вопросы, у кого большой рейтинг. И посмотрите, на какое количество своих вопросов они получили нужные ответы. Прискорбно.
kn1ght_t: так сформулируйте, что значит, "форма не сработала" ?
Если ограничений на отправку нет, то просто отправить форму эквивалентно нажатию на кнопку сабмита.
А еще это эквивалентно тому, что пользователь сам миллион раз перейдет на страницу результата в форме. Или отправит запрос через курл\вгет или аналоги.
В чем проблема? Каким именно образом форма "может не сработать", на ваш взгляд?
Да, это действительно плохо, но случается довольно часто.
Но представим, что со стилями проблем нет.
В любом случае, тот, кто будет интегрировать верстку, должен, получается, ориентироваться не только на классы, которые, в принципе, нагляднее, но и на конкретные тэги.
Не сказать, что это сильно отличается от того, что бы самому делать сементично - просто иногда можно немного меньше задумываться над уместностью тэга в том или ином месте.
Хотя, возможно, просто мне не встречались случаи, когда верстку можно скопировать, вставить и забыть.
sardor93: не стоит подавлять такие ошибки. Да и способ, на самом деле, не лучший - это так, перестраховаться. И если есть ошибка - это хорошо, быстрее заметите. Т.к. такая ситуация вообще не должна происходить.
Но и задачу вы решаете не лучшим способом.
Просто знайте, что такой способ есть, на будущее
Александр Борисович: так не в открывании дело. Открыть то догадался. А что, если бы кто-то хотел показать, как из этой каши сделать что-то более удобо-читаемое? Или просто хотя бы сделать сравнение с чем-то существующим? Забить или ручками все перепечатывать?
Евгений Романовский: принципиальной разницы нет, но grunt(gulp)-asset-pipeline идут как сторонние плагины и, видимо, не особо удачные.
Ну, смысл, по сути тот же, что вам посоветовали первым ответом - храните как удобно, собирайте как нужно. Просто есть проверенные решения, которые уже делают это за вас.
billybons2006: нет, от таких программ отказались на этапе планирования. Создать универсальное решение этой задачи - неподъемная проблема без рабочей группы поставщиков.
Даже на начальном этапе вы столкнетесь с тем, что нужно будет перепиливать под себя колоссальное количество задач. И это все не говорят о том, что решение нужно будет интегрировать непосредственно в ваш движок.
Что будете перепиливать под себя?
- доступ: http/ftp/email/соцсети...
- форматы: xls,xlsx,csv,xml (валидный, невалидный)...
- особые правила разбора каждого поставщика
- правила разбора поставщика, которые плохо вписываются даже в саму абстрактную модель
- Несоответствия артикулов и кодов по разным поставщикам, ручное приведение их к одному виду, связывание товаров по названию в конечном итоге
Это так, навскидку, те задачи - которые будут очень специфичны именно для вашего случая. И взяв любое готовое решение, вам сначала придется потратить деньги, что б обучить ему разработчиков, а после - потратить деньги, что б перепилить его под свои нужды.
Подобные программы выглядят очень многообещающе. Но уверен, что их основной заработок - это не 50 долларов лицензия. А техподдержка после того, как вы поймете, что все равно все нужно под себя делать.
Антон Иванов: ну, я к тому, что отметать вариант с симлинками просто, от того, что некошерно - не стоит. Видел одно довольно большой сервис. Правда. модели были разделены всего между двумя приложениями, но с симлинками проблем не было
Антон Иванов: например, может быть очень много неприятных моментов, если разные приложения на разных серверах используют один гит, но в одном из приложений вы по какой-то причине забываете обновить Gemfile.lock. А особенно, если всем рулит какой-нибудь CI. И если это еще и продакшн... :)
Тогда начнутся пляски не только с dev/prod окружениями.
Плюсов, конечно, у такого подхода, наверное, больше, но и осторожнее нужно быть чаще
То есть, если у вас заказали разработку сайта, вы его 5 лет делали, а заказчик по итогу, оказалось, ничего не шарит в бизнесе и смог заработать 0, то вам тоже нужно заплатить 0 ? :)
copal: она и не отдает картинки. Она отдает путь к картинкам (который хранится в базе и, следовательно, является данными), с учетом определенной бизнес-лоигики (сервер, путь, порт...)
Посмотрите carrierwave и paperclip
Это даже совершенно не тз на Розетку или Юлмарт.
максимум - магазинчик на бесплатном шаред хостинге