- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
try
{
return ($image = $this->row->image()->first())
? $image->{$this->imageAlias}
: dummyThumbnail($this->imageAlias)
;
}
catch(\Exception $e)
{
if ($e->getMessage() === 'Method [image] is not defined on the Query class.')
{
$val = parent::value();
return (is_string($val) and \Str::contains($val, 'http://'))
? $val
: $this->row->getImageSrc($this->name, $this->imageAlias)
;
}
throw new \Exception($e->getMessage(), $e->getCode());
}
Follow us!
Есть три способа хранения картинок в БД:
1) веб-путь (http://...)
2) имя файла (image.png)
3) id картинки в таблице uploads (это если много картинок привязывается)
Перед вами кусок кода, не знающий, каким образом она сохранена, который пытается получить путь к картинке, Если есть метод image() у объекта модели (хранится в $this->row), то это третий случай. Если его нет, то будет выброшено исключение, не имеющее кода, но имеющее сообщение 'Method [image] is not defined on the Query class.'.
Дальше должно быть понятно.
Только что обнаружил, что в случае 1 и 2 модель расширяет класс ImageModel, а в третьем случае - просто Base\Model. Можно строить на этом, но опять же существует риск, что кто-то придумает еще один класс, который не будет расширять ни один из двух вышеперечисленных, и тогда компонент сломается.
Мой же пример во-первых не оптимален в случаях 1 и 2 (сначала дело доходит до исключения и только потом выполняется нужный код), во-вторых, кто-то может изменить сообщение исключения, в-третьих кто-то может создать метод image() в классе модели, в-четвертых, как вы отметили, для понимания кода нужна как минимум степень бакалавра по специальности "шаман" :)
При создании объекта модель наполняется нужной инфой и аккуратно укладывается в БД до лучших времен.
Сложность в том что надо писать скрипт который пройдется по всем объектам и создаст записи в этой модели. Если появится новый способ хранения то надо будет править 1 класс.
Что-то я переработался с индусами, похоже... Забыл что некоторые люди умеют учиться. :) Твой ответ меня в ступор ввёл секунд на 10. 8-)
эникей/эникейщик — компьютерщик, выполняющий простую работу, не требующую высокой квалификации (переустановка windows, замена картриджей в принтерах и т. д.)
(close-thread :force)
Я думал, политкорректность, толерантность, Пиндостан, думал, kegdan что-то на ассоциативных связях построил.
СШП же напротив занимается всем профессионально и обычно потому что кроме него никто в это не разбирается. он может и жабу трахнуть гугловым ведром, и сайт на рельсы прокинуть, и на сях драйвер для usb девайса написать и все качественно. Такие люди обычно либо добровольно кодят все подряд (обычно мяготку, выкидывание на допил спецам пониже) либо сами ниче не кодят, но передают спец бесценный опыт и пиздюля
У нас в конторе работает такой.Ни разу не программист но блять лучше всех знает ,что да как, надо прожить и сколько надо времени для этого. Очень обижается будучи послан на хуй. Он дескать идею разрабатывает. Пусть кажды занимается своим делом я тоже могу странной рулить но не берусь же.
В маленькой конторе не получается сосредоточиться на чем-то одном :( Вот и получается и на сишке/крестах пилец, и на флешефлексе/пыхе/жс/пёрле/жабе/питоне срец, такой как я. Да еще и админ и техподдержка в одном флаконе (прощай "состояние потока", я буду о тебе скучать). Все вместе, и ничего на должном уровне.
> @kegdan: и все качественно
Та хуй там.
И в микро косяки т.к. тупо не надрочился рука не набита.
И в макро косяки, т.к. по началу слабо представляешь, как должна выглядеть кошерная архитектура в новых для тебя областях, а потом уже поздно что-то менять.
Так что СШП это далеко не всегда хорошо... Хотя, с другой стороны, интересно и моск не засохнет от постоянной работы с одной технологией.
а полезный - еще и ориентироваться в альтернативных мирах, будучи готовым провести своевременные параллели
поэтому сшп нужны чуть менее чем везде
>FIXED
но вот C\C++ ненавижу - там даже такая безобидная ошибка, как "ошибка на единицу"(например в циклах) приводит к системному segfault; и бррр, указатели и арифметика указателей. нахер не нужно.
посоны, не обращайтесь к недопустимым адресам, у меня от этого брат умер
а клиенту обычно этот стектрейс столь же интересен, как и "по адресу 0xДЖИГУРДА"
сколько раз случалась ситуация "локально(на тесте) все работает, а в продакшене (у клиента) - ошибка". и ищи ее как хочешь, у клиента же дебаггер не запустишь.
я 7+ лет отработал в том месте, где код писался на с/с++ без возможности удаленных отладок и прочих прелестей жизни для систем 24/7/365. Если бы в продакшене всё падало хотя бы раз в месяц, или хотя бы раз в квартал, ещё можно было бы поверить в твои сказки.
И факт в том, что отлаженный на с++ код работает в 10 раз быстрее жабьего, потребляя в 10 раз меньше системных ресурсов, а написать его не так сложно, как ты себе это представляешь - хотя, несомненно, чутка сложнее, чем на жабе.
не осилил посчитать границы массива? лезешь в сырые указатели, не понимая что с ними делать? - продолжай резать антрекот деревянной ложкой
вот RAII - это да, это уменьшает утечки по сравнению с GC
з.ы. мне нравится компромисс, который был достигнут в DMD D
ну а в с++ они аналогичным образом используются в виде перегруженных операций класса
например, в итераторе, ну или какой-нибудь smart ptr
но в жабе даже перегрузка оператора уже "слишком сложно" чтобы этим пользоваться, и поэтому "ненужно"
Если бы D не был таким сырым.
Это никакой не факт, а голословное преувеличение.
Разве что так было 7+ лет назад.
>>отлаженный на с++ код
Или речь о коде отлаженном дебагером сделаном на C++?
Плюс в жабе сборка мусора в отдельном потоке - то есть даже однопоточное приложение безо всяких усилий будет работать в несколько потоков.
Точнее наоборот - даже многопоточное приложение будет упираться в скорость гц работающего в одном потоке.
много где освещается вопрос, как правильно писать приложение, чтобы упростить жизнь мусорщику - например, повторное использование.
Ты наркоман или просто питонист?
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
а простейшему жабьему клиенту, открывающему соединение с БД, перерабатывающему 500кб данных раз в 5 минут и засылающему переработанное на SOAP - полгига
давайте про производительность жабы и её коэффициенте 1.1 в другом месте поговорим
>>jboss нужно
Это фатальный недостаток языка Java.
Я боюсь говорить сколько нужно ресурсов программам типа Adobe Photoshop написанных на С++.
1.1x другая крайность, как и 10х.
это всё к вопросу о необходимости стек-трейсов
клиент реально тупой как валенок, запущен в виде службы, работает безотказно уже месяцами
sql, List, Timer, TimerTask, ws, log4j да сгенеренные классы по wsdl
там, где java -server съела полгига, на с++ вышло бы целый мегабайт или даже три!
зато мышкой всё запрограммировалось за считанный час, это спасибо, думать над указателями не пришлось, а то вдруг ошибся бы на единицу
В жабе ошибаться на единицу чревато, равно как и в любом языке. Неправильный говнокод работающий месяцами, который не упадет сразу сегфолтом/исключением. Не знаю что хуже.
Хочешь аналог nginx-а? Или нацепи снаружу nginx, или ищи асинхронные фреймверки.
расскажи это жавоблядям, которые написали это решение
а нам доля поддерживать у заказчика
только где в моих постах проскакивало хоть что-то про статику?
на jboss лезет пара тысяч клиентов по comet (http long-polling), сервер каждому в течение минуты, получаса, часа, суток (насколько сдюжит - ибо т.к. в мире жабы всё пиздец как хуево с асинхронностью, то ынтырпрайз на деле означает 1 клиент = 1 тред на сервере) шлёт онлайн-данные мелкими порциями с непредсказуемыми интервалами - типа таким образом приходят на клиенты "события" системы
причем "события" фактически для каждого клиента индивидуальные - зависит от совокупности "каналов", на которые подписывается клиент
я не могу это в корне поменять на сервере, потому что там closed source
я могу лишь отмодернизировать клиенты (ибо там js) и написать на коленке свой сервер, например, на крестах, который с одной стороны будет выступать единственным клиентом для основного сервера на канале */*/* (т.е. жрать вообще все события, которые возможны), а с другой - раздавать тысячам модернизированных клиентов относящиеся к ним "события", только, например, по дуплексному веб-сокету (чтобы команды subscribe/unsubscribe не делать в виде отдельных http запросов)
nginx тут вообще никаким раком
именно об этой хуйне я и говорил на прошлой неделе
про белых людей, async и тяжкой доле раба-крестушка, которому приходится убирать говно за высокоуровневыми господами
"прогревается" ибо компилит на лету только часто исполняемые куски кода, остальное интерпретирует
все это конфигуриемо на уровне виртмашины, но спецов по тюнингу жвм под конкретную бизнесаппликуху можно по пальцам пересчитать.
* с чем это едят я не в курсе, ибо нуб
WPшникам трудно объяснить, зачем все эти анонимные функции, магические методы, композер, фреймворки и остальное придумали, потому что "вордпресс и так заебца работает без всех этих сложностей".