Shitbox2Не боюсь... Пусть даже экземпляры создают. Нафига тогда нужны абстрактные классы и статические методы? На практике-то они для чего применяются?

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

«Совершенно оболванен
от таких серьёзных тем,
Тихо ахнул поселянин:
«„Вот же круто!.. А зачем?“»

Представим одну и ту же работу виполненую с помощью статических переменных/методов и без них.
Итак, есть у нас класс животные, а в нём переменная "количество ног"=4. А что будет, если мы создадим 1000 000 животных с четырмя ногами, а они в один момент вдруг должны стать прямоходячими?
Мы должны отыскать все 1000 000 экземпляров (хорошо, если это массив, а если нет? ) и поменять аттрибут "количество ног"=2.
ИЛИ
если наша переменная "количество ног" будет статическая, а в методах класса мы будем обращаться именно к ней (Zhivotnoe::$nogi) то изменив эту переменную, мы моментально поставим всех на 2 ноги :)

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

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


А абстактные классы вообще отношения не имеют к этому. Скажем мы создали класс Жизнь. В этом классе описываются аттрибуты присущие всему живому: длина жизни, тип организма, список органов и куча всего другого (сорри, не биолог :) ). А от этого класса наследуем классы грибы, животные, одноклеточные, растения и т.д. Так вот, мы можем создать экземпляр любого животного, растения... НО МЫ НЕ ДОЛЖНЫ иметь возможность создать экземпляр класса Жизнь (так как сам класс не является завершённым описанием чего-либо). Вот тогда мы и делаем класс Жизнь абстрактым.

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

Shitbox2,

Начнём с того, что является очень плохим тоном делать свой класс зависимым от внешнего мира. Скажем, а что если я не могу по какой-либо причине использовать GET запросы при передаче параметров (например мне нужно передавать информацию об экшене постом). Вот и первая проблема, надо все геты отлавливать и менять на пост (хотя и быстро, но делать так не надо). Во вторых, почему бы не использовать классы полноценно? А если мне надо будет картинку уменьшить, конвертировать и создать к ней аватарку? Трижды создавать одни и те же ресурсы и всё такое?
А я бы создал ресурс картинки при создании экземпляра класса, записал бы этот ресурс как атрибут объекта и орудовал бы с ним (и так же поступил бы с другими переменными). С классом Image разобрались (то есть лучше делать его не абстрактным).
Класс album как я уже говорил лучше сделать независимым из вне, ну и так же полноценным (без разных там static методов). А ещё бы я создал файл конфига, который позволял бы выбрать библиотеку для обработки картинок, и другие параметры.

вообщем как и обычно, я не вижу смысла в статике вообще :)

Shitbox2Ок. Заменил. К каким еще мелочам можно прикопаться? Как бы такую штуку построил крутой кодер? А суть штуки в том, чтобы облегчить разработчикам работу с картинками (аватарки, форумы, комментарии, посты в блогах и проч.), открытый же проект делаю, елки-палки :)

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

Всё остальное (размер аватар, размер сохраняемых картинок, исходящий формат, библиотека обработки и т.д.) в конфигах. любой параметр может быть изменён установкой соотвествующего параметра класса.

В данном случае, класс должен просто предусматривать флаги convert, resize, avatar. А функция обработки одна (например make() или process(), понятно дело подгружающая 3 приватных метода). Тогда ресурс вообще хранить не прийдётся. Инициализировал, задал параметры, обработал, удалил.

И Вам легче, и программеру, который юзать бибилиотеку будет.

Я не крутой кодер, но моё видение задачи именно такое :)

P.S. Ах да... забыл... ещё он не должен менять обычного поведения скриптов. То есть, не хорошо делать например move_uploaded_file, так как после Вашей обработки картинок, может последовать следующая (уже не Ваша), а это приведёт к ошибке (так как в _FILES будет записано, что такой файл был загружен, а физически он уже не там).
Нельзя жёстко привязывать, что клиентский скрипт должен обязательно отправить данные именно в Ваш серверный скрипт. Просто часто надо до сохранения файлов провести какие-нить валидации и типа того (например когда аватарку может только зареганый пользователь создавать), иначе сервак любой желающий загадить сможет.
Можно было бы выделить отдельный файл для валидации, но если модуль встраивается в Yii например, начнутся проблемы с его подгрузкой.

Но это опять же не критично... а просто хорошо бы.

РенатПрограмёр,

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

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

Shitbox2Насчет «размер аватар, размер сохраняемых картинок, исходящий формат, библиотека обработки и т.д. в конфигах» А если библиотека используется несколько раз с разными целями? Например, для создания аватарок, потом для обработки фоток в комментах, получается конфиги нужно переписывать?

Второе сообщение, вообще, темный лес для меня. Как сделать без move_uploaded_file?

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

Сейчас все отсылается одному скрипту с управляющими параметрами в GET. Имя скрипта нужно сделать в конфиге js, абсолютно согласен. А как быть с управляющими параметрами? Просто описать их в примечании, чтобы разработчик мог настроить свой скрипт? Лучше GET или POST их передавать?

P.S. Хотелось бы взглянуть на скрипты, приближенные к идеальным (особенно php), а то как-то плаваю сейчас

1. Поэтому и говорю, должна быть возможность менять поведение модуля заданием нужных атрибутов экземпляру класса... + в таком случае можно как-то покрутому соорудить загрузку конфигов (хотя не знаю. 10 конфигов - это как-то не круто). Ещё при этом (при возможности менять поведение) хорошо бы пакетную обработку сделать (или метод, который позволил бы эту картинку выгрузить и следующую картинку загрузить в этот же экземпляр для обработки).
2. Можно использовать например какую-нить copy.
3. Всё лучше отправлять одним методом (или пост или гет). В данном случае наверное POST (ведь файлы отправляются).
4. По поводу идеальных скриптов, даже не знаю что сказать... Под рукой таких нету :) Хотя в принципе любая модульная хорошая система так работает (только более глобально). Например тот же fckeditor (только js часть): строка инклуда, файл настройки, файл внешнего вида (в каких-то версиях в одном с настройкой), строка для замены textarea на продвинутые. в нём встраиваемый модуль ckfinder который грузит файлы на сервер. У него в конфигах по-моему предусматривается проверка переменных (своего рода валидация на серваке и всё такое).

Ренатможет я конечно не то понял, но черный ящик может все сам проверить и плюнуть exception в случае чего. Аргуент у него - имя темп файла (черному ящику то какая разница, тем файл с картинкой или нет? едиснвтено его надо проверить до черного ящика реально ли он загружен)


я не зареганый хакер (сидящий с динамического ip), который хочет убить сервак (занять например все ресурсы). Я знаю, что предпросмотр картинки невозможен без загрузки на сервак. нахожу, куда отправляется файл, винчу свою форму, в которую вкладываю файл. Отправляю его этому скрипту. Тогда скрипт проверив, что данный файл пришёл, сохраняет его в директорию для предпросмотра. человечек отрубается от сети, подрубается назад, и повторяет операцию. Что произойдёт на серваке через 30 минут - час? Правильно, никто уже не сможет отправить картинку со своим комментом например, так как места не будет уже.

Сайт конечно не убит, но работает с глюками.
так что такой простой проверки явно недостаточно. :) Ещё и хорошо бы картинку на серваке по определённому принципу именовать (это тоже должен быть атрибут класса). Тогда можно избежать засорения папки аватарками одного юзера, если при отправке дать программеру на серваке задать определённый шаблон имени (например id-юзера_avatar).

Так что нет... явно чёрный ящик тут не прокатит :) Он должен быть чёрным, но "с дырочками, ручками для переноски" и всё такое :)

Shitbox2Меняю входные данные на $param

Всего скрипт может получать 3 типа данных
$_GET['type'] (получает всегда)
$_GET['id']
$_POST['sort']

Как понимаю, в качестве $param лучше передавать что-то одно, например, POST, тогда все управляющие запросы так же нужно в POST запихнуть. Получится


Логика верна?

да. :)
кстати в таком модуле хотелось бы видеть возможность обработки ещё и серверных картинок (скажем, когда я ранее 10 картинок загрузил на сервак, а теперь из одной хочу аватар сделать). мне такая функция кажется востребованной... :) просто как предложение.

Shitbox2На счет хакера. Думаю, это забота движка, отслеживать, чтобы картинки могли только зарегистрированные пользователи загружать. Это в примере только все для всех. Т.е. для незареганного просто не подключится класс. Опять же, клиентский скрипт должен отслеживать это и выполнять колбек функцию исходя от типа ошибки сервера. Ух... Сколько работы-то
вот-вот... Это ответ Ренату, к тому, что надо отправлять не сразу в скрипт своего модуля, а в скрипт, который программер выберет (может он какой-нить контроллер фрэймворка туда укажет)... Тогда забота проверок падёт на него. Ты просто кода ошибок ему напиши(константы/переменные статические вбей например) пускай орудует и скрипту возвращает. Это вообщем на твоё усмотрение (вариантов уйма) )))

Shitbox2,

сорри, с обработкой серверных картинок ступил. :)

Shitbox2,

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

Shitbox2Еще... Если возникнет ситуация, что в системе уже будет класс Album или Image, как решить эту проблему? Такой вариант покатит?

action.php


lib/dg.php и lib/magickwand.php



лучше придумай своим классам какой-нить префикс нормальный (например Sb - взято с твоего ника), да и пиши классы SbAlbum, SbImage. Я пространства имён никогда в php не пользовал... Это походу менее удобно.