> 1) Being able to create redirects (which seems to already be on the
> todo-list)
Creating temporary 302 redirects are currently possibly right now. The
TODO is for being able to specify both 301 and 302 redirects through
the admin.
> 2) Being able to specify extra kwargs to pass to a view so that it would be
> possible to change the functionality of a view without adding a new model to
> store the different options (or have to change the urlconfig and push new
> code every time).
You can still specify additional urls in urls.py as the framework
allows you to do normally; django-urls simply appends to that list of
urls. There is also a TODO for adding the ability to edit views
through the Django admin using the same editor GitHub uses. These
should cover the use cases you describe.
On Sat, Dec 15, 2012 at 11:52 PM, Sam Solomon <
sss...@gmail.com> wrote:
> Yeah, I agree, as it is, I can't see any reason why I would use it, but I
> could see it being useful with some modifications such as:
>
> 1) Being able to create redirects (which seems to already be on the
> todo-list)
> 2) Being able to specify extra kwargs to pass to a view so that it would be
> possible to change the functionality of a view without adding a new model to
> store the different options (or have to change the urlconfig and push new
> code every time).
>
> Until those things are implemented (which allow for things that could
> probably be implemented in more straightforward/non-dev-user friendly ways),
> it seems like a bad idea to store infrastructure in the database (I can only
> see it causing problems when you have developers working from a different
> urlconf than the production server is using).