Django будет хорошим выбором для основанного на полномочиях веб-приложения?
Я не вижу, чтобы вы использовали расширение с задержкой. Итак, либо отключите его с помощью setlocal DisableDelayedExpansion в начале вашего командного файла, либо просто удалите его, удалив строку setlocal EnableDelayedExpansion.
Однако, если вы хотите сохранить его, выполните:
@echo off
SetLocal EnableDelayedExpansion
rem Code above (^^) if exists.
Setlocal DisableDelayedExpansion
set "folder=%~1"
set "count=0"
for /R "%folder%" %%G in (*) do (
set "fullpath=%%~fG"
set "fileExtension=%%~xG"
call :processFile
)
goto end
:processFile
echo "fullpath = %fullpath%"
echo "fileExtension = %fileExtension%"
ren "%fullpath%" "temporary_filename_500%fileExtension%"
set /a "count+=1"
echo/
goto :eof
:end
echo "%count% files processed."
pause
setlocal EnableDelayedExpansion
rem Your code below with active delayed expansion:
Обратите внимание, что:
- Вы всегда должны указывать имя переменной и значение в
setкоманда какset "var=value"и вset /aкакset /a "var+=1"и т.д .; см.set /?для получения дополнительной информации. - Чтобы точно найти полный путь к файлу / папке в цикле
for, используйте модификаторf, например%%~fG. - Упомянутый Мофи здесь : не используйте
echo.; используйтеecho/для лучшей практики.
См. Также Фазу 5 (Задержка расширения) из этого ответа о том, как интерпретируются командные файлы.
5 ответов
Если я считал Ваши обновленные требования правильно, я не думаю, что существующая подлинная система Django будет достаточна. Это кажется на необходимость в настоящей системе ACL.
Этот предмет подошел неоднократно. Попытайтесь гуглить на django+acl.
Случайные выборки...
было Лето проекта Кода несколько лет назад, но я не уверен, где они добрались до. См. http://code.djangoproject.com/wiki/GenericAuthorization
существует новый билет по djngoproject.org, который мог бы быть интересным:
на dumpz.org существуют некоторые интересные надрезы кода:
- http://dumpz.org/274/ models.py
- http://dumpz.org/273/ signals.py
..., но существуют нулевые документы.
Удачи!
Можно также хотеть взглянуть на детализированные полномочия monkeypatch: http://code.google.com/p/django-granular-permissions/
Это добавляет полномочия уровня строки к системе разрешения django.
Система разрешения Django полностью управляет. Каждая модель имеет набор по умолчанию полномочий. Можно добавить новые полномочия к моделям, также.
у Каждого Пользователя есть ряд полномочий, а также составов группы. У отдельных пользователей могут быть отдельные полномочия. И они наследовали полномочия от своего состава группы.
Ваши функции представления (и шаблоны) могут легко проверить присутствие отсутствия тех полномочий на любом уровне гранулярности, которую необходимо использовать.
И если это не достаточно для Вас, дополнение Профиля дает Вам еще больше опций для определения "Пользователя" и их возможностей, полномочий, ролей, обязанностей, и т.д.
И если это не достаточно для Вас, можно определить собственные схемы аутентификации.
<час>то, Что важно, не должно пытаться определить группы, которые являются фактическими подмножествами пользователей, не небрежно определенные заголовки или роли. Вы никогда не должны "устанавливать полномочия для подмножества группы". У Вас должны быть меньшие группы. Группы определяются вокруг подмножеств людей.
полномочия Django по умолчанию вокруг доступа модели, не доступа строки в рамках модели. С другой стороны, Ваша проблема о подмножествах строк в нескольких моделях: Клиент, Хранилище, Сотрудник, менеджер.
Вам будут нужны основной набор FK среди этих объектов и некоторые фильтры к подмножеству строки. Вы можете испытать затруднения при выполнении этого с администраторскими страницами по умолчанию. Вам, возможно, понадобится Ваша собственная версия администратора для использования специализированных фильтров.
<час>, Если Вы не можете сделать этого с системой разрешения Django, необходимо заново продумать варианты использования. Серьезно.
[Интерфейс Django-REST, однако, является другим зверем полностью и требует некоторого ухода и питания.]
объекты ModelAdmin имеют has_add_permission, has_change_permission, has_delete_permission и queryset методы, которые могут использоваться для осуществления полномочий вокруг того, что зарегистрированный пользователь видит и изменяет - Вы могли создать подкласс, который использует их для осуществления безотносительно полномочий, Вы хотите реализовать и зарегистрировать все Ваши модели в admin приложение с помощью подкласса.
Однако все это зависит, как точно Ваша система полномочий будет работать - каковы строгие требования, которые падают из Ваших мелкомодульных полномочий? Чем больше Вы переезжаете от того, что admin приложение было разработано, чтобы сделать, тем больше работы потребуется, но существует много рычагов там, которые можно использовать для реализации пользовательских требований. Вот сообщение в блоге от Завода Luke , который дает примеры части подстройки, можно обойтись без необходимости вырыть слишком глубоко.
это абсолютно имеет для базирований вокруг admin приложение? Универсальные представления и ModelForms может заботиться о большом количестве утомительных битов, вовлеченных в реализацию CRUD, таким образом быть осторожным из получения слишком одержимого настройкой admin - это - почти традиция Django для запуска путем становления одержимым admin приложение и что это может и не может сделать, первоначально думая, что Вы никогда не будете иметь для написания любого кода снова ;)
Я только что нашел http://bitbucket.org/jezdez/django-authority/ , это выглядит многообещающим.