Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-02 Thread Curtis Maloney
On 3 March 2015 at 03:57, Marten Kenbeek  wrote:

> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
> provide a quick overview of the features I propose.
>
> I'd like to:
> - Allow matching based on request attributes such as the subdomain or
> protocol, and business logic such as the existence of a database object.
>

There was a "continue resolving" sort of exception proposed/implemented
that would obviate this, allowing the logic to remain in views [or view
decorators]... a much simpler solution, IMHO.


> - Make middleware configurable for a subset of views. It should be easy to
> add, reorder or replace middleware at any level in the (currently
> recursive) matching algorithm.
>

This has certainly been on the "wanted" list for many years now, however I
expect it would require the middleware re-design that so far has proven too
invasive to land.

That said, providing the "new" middleware-as-wrapper interface around url
patterns lists could be a good stepping stone to eventually removing the
existing middleware API.


> - Provide conventions for common patterns, such as an easy-to-configure
> URL router for all generic Model views. For generic views, this should be a
> one-liner. For custom views and other non-default options, this should
> still be relatively easy to configure compared to writing out all patterns.
>

Are you talking about pre-cooked url patterns for the various CBV?  Or
plugin routers for groups of CBV?  I'm certainly in favour of some tool
that makes it easier to express "common" regex matches [satisfying the
"protect from the tedium" rule of frameworks]


In the process, I'd like to formalize some classes used in the dispatcher.
> Currently, the RegexURLPattern and RegexURLResolver classes provide most of
> the functionality of the URL dispatcher. By abstracting these classes, and
> factoring out the loading mechanism and some other internals, I hope to
> provide an extensible dispatching framework for third-party apps.
>

As mentioned elsewhere, I would very much like to see a resolver system
based on the "parse" library [essentially, the inverse of str.format -
https://pypi.python.org/pypi/parse], and to do so would indeed require some
formal analysis / documentation of the existing resolver architecture.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSBaPz%2BJJs-CGLbZzdbpvSRo3vjpeWnpcxhVVq_tfs4gaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-02 Thread Marc Tamlyn
A collection of thoughts:

I think allowing the url dispatcher to inspect the database for the
existence of certain objects is potentially somewhat dangerous. However,
good support for a view raising a "continue resolving" exception along the
lines of https://github.com/jacobian-archive/django-multiurl might be
interesting. Related to this, a check for potentially conflicting url
mappings could be interesting.

Middleware currently has complex and unintuitive behaviour in the event of
exceptions. You talk about the middleware/decorator split, but not how to
make either make sense.

Supporting generic sets of views has some logic, although in my experience
it is extremely rare that you can sensibly use a generic view with no
alterations at all - it almost always needs extra context or some other
tweaks. I'm not really convinced that a one liner to get CRUD for a
particular model will actually be that useful in the wild - you're likely
to end up changing too many things. I don't find the "one line in a urlconf
for each view" convention to be particularly problematic, however writing
all the regexes is potentially more prone to problems.

If you are intending on introducing alternative URL resolvers, some example
ideas would be needed. The lack of a consistent way to reverse a slug for
example is a good idea to address, but we need to establish how.

How are you intending to support different resolvers in the same project?
It seems to me that it is rather inefficient in large projects to loop
through all resolvers for all urls.

Namespacing urls is currently over complex for the 90% use case, and the
docs are hard to understand as a result. Alternative designs in this area
could be interesting.

Overall there are lots of interesting starts of ideas here, but I feel one
or two dead ends. It's a potentially very varied project and the crux of
the proposal needs to focus on ensuring that some specific tasks are well
designed and achievable, with others being extensions later on.

Marc

On 2 March 2015 at 17:14, Tim Graham  wrote:

> Hi Marten,
>
> I think it would be helpful to motivate this with some pseudocode of
> specific use cases you are aiming to solve. Have you looked into whether
> there are any related third-party projects related to your ideas from which
> you could draw inspiration?
>
> Tim
>
>
> On Monday, March 2, 2015 at 11:57:24 AM UTC-5, Marten Kenbeek wrote:
>>
>> Hey all,
>>
>> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to
>> provide a quick overview of the features I propose.
>>
>> I'd like to:
>> - Allow matching based on request attributes such as the subdomain or
>> protocol, and business logic such as the existence of a database object.
>> - Make middleware configurable for a subset of views. It should be easy
>> to add, reorder or replace middleware at any level in the (currently
>> recursive) matching algorithm.
>> - Provide conventions for common patterns, such as an easy-to-configure
>> URL router for all generic Model views. For generic views, this should be a
>> one-liner. For custom views and other non-default options, this should
>> still be relatively easy to configure compared to writing out all patterns.
>>
>> In the process, I'd like to formalize some classes used in the
>> dispatcher. Currently, the RegexURLPattern and RegexURLResolver classes
>> provide most of the functionality of the URL dispatcher. By abstracting
>> these classes, and factoring out the loading mechanism and some other
>> internals, I hope to provide an extensible dispatching framework for
>> third-party apps.
>>
>> The full, yet incomplete proposal can be found at
>> https://gist.github.com/knbk/325d415baa92094f1e93 if you want more
>> details. It currently contains a slightly more in-depth discussion of the
>> current dispatcher and the proposed features, and a start on the redesign
>> of the dispatcher.
>>
>> I'm mostly looking for some feedback on the general direction of these
>> features, though any feedback is welcome. I'm still working on it, so
>> details might change based on new insights.
>>
>> Thanks,
>> Marten
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/34ebf9ed-9961-4b33-9f49-5e6a4f9c6469%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are 

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-02 Thread Tim Graham
Hi Marten,

I think it would be helpful to motivate this with some pseudocode of 
specific use cases you are aiming to solve. Have you looked into whether 
there are any related third-party projects related to your ideas from which 
you could draw inspiration?

Tim

On Monday, March 2, 2015 at 11:57:24 AM UTC-5, Marten Kenbeek wrote:
>
> Hey all,
>
> I'm working on a proposal to extend the URL dispatcher. Here, I'd like to 
> provide a quick overview of the features I propose. 
>
> I'd like to:
> - Allow matching based on request attributes such as the subdomain or 
> protocol, and business logic such as the existence of a database object.
> - Make middleware configurable for a subset of views. It should be easy to 
> add, reorder or replace middleware at any level in the (currently 
> recursive) matching algorithm. 
> - Provide conventions for common patterns, such as an easy-to-configure 
> URL router for all generic Model views. For generic views, this should be a 
> one-liner. For custom views and other non-default options, this should 
> still be relatively easy to configure compared to writing out all patterns. 
>
> In the process, I'd like to formalize some classes used in the dispatcher. 
> Currently, the RegexURLPattern and RegexURLResolver classes provide most of 
> the functionality of the URL dispatcher. By abstracting these classes, and 
> factoring out the loading mechanism and some other internals, I hope to 
> provide an extensible dispatching framework for third-party apps.
>
> The full, yet incomplete proposal can be found at 
> https://gist.github.com/knbk/325d415baa92094f1e93 if you want more 
> details. It currently contains a slightly more in-depth discussion of the 
> current dispatcher and the proposed features, and a start on the redesign 
> of the dispatcher. 
>
> I'm mostly looking for some feedback on the general direction of these 
> features, though any feedback is welcome. I'm still working on it, so 
> details might change based on new insights.
>
> Thanks,
> Marten
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/34ebf9ed-9961-4b33-9f49-5e6a4f9c6469%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Extending the URL Dispatcher (GSoC 2015 proposal)

2015-03-02 Thread Marten Kenbeek
Hey all,

I'm working on a proposal to extend the URL dispatcher. Here, I'd like to 
provide a quick overview of the features I propose. 

I'd like to:
- Allow matching based on request attributes such as the subdomain or 
protocol, and business logic such as the existence of a database object.
- Make middleware configurable for a subset of views. It should be easy to 
add, reorder or replace middleware at any level in the (currently 
recursive) matching algorithm. 
- Provide conventions for common patterns, such as an easy-to-configure URL 
router for all generic Model views. For generic views, this should be a 
one-liner. For custom views and other non-default options, this should 
still be relatively easy to configure compared to writing out all patterns. 

In the process, I'd like to formalize some classes used in the dispatcher. 
Currently, the RegexURLPattern and RegexURLResolver classes provide most of 
the functionality of the URL dispatcher. By abstracting these classes, and 
factoring out the loading mechanism and some other internals, I hope to 
provide an extensible dispatching framework for third-party apps.

The full, yet incomplete proposal can be found at 
https://gist.github.com/knbk/325d415baa92094f1e93 if you want more details. 
It currently contains a slightly more in-depth discussion of the current 
dispatcher and the proposed features, and a start on the redesign of the 
dispatcher. 

I'm mostly looking for some feedback on the general direction of these 
features, though any feedback is welcome. I'm still working on it, so 
details might change based on new insights.

Thanks,
Marten

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1555e45b-8a98-4d36-bc7b-00c7136e782d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.