Overthinking urls.py?

I'm going to type out loud for a little bit.  I'm hoping
to better
define the problem so we can think about solutions more
clearly (or go
find ones as solved by other frameworks).

Django has the concept of an application, a reusable chunk
of
functionality which can be reused in many different
projects.  A
project is a collection of applications.

A project is responsible for defining which apps are
available
(INSTALLED_APPS), and what URL the app can be accessed
under, e.g.,
(r'^admin/',
include('django.contrib.admin.urls.admin')).

== Problem ==
If application Foo wishes to link to application Admin, it
must know
how the Project has 'mapped' the Admin application (e.g.,
starts with
/admin/).

This leads in to the original topic of the thread, which
centers around
encasulating URLs;  gathering their RE and their
'parameters' into one
class for reuse.

== Problem ==
If application Foo wishes to link to application Admin, it
must know
how the URL is constructed.


So what does the solution look like?

== 1 ==
Application Foo should be able to use a Class, function,
whatever,
supplied by the Admin application, to obtain a URL it can
draw in an
HTML page.

== 2 ==
The Admin application should know something about how it has
been
deployed by the project to that it can correctly construct a
URL to
itself.


== v0.01 Solution ==
INSTALLED_APPS = (
    ('django.contrib.admin', 'admin',),
    ('cpt.app.foo', 'foo',),
)

When the framework/project installs an application using
this
configuration, it could add a well known variable to the
django.contrib.admin package called 'DEPLOYMENT_PREFIX'.

I don't have a proposal on how to get that variable into
the urls.py
module under the project.  I haven't thought it through and
would
rather skip it for now.

As far as encasulating URLs inside an application, the
convention might
be to have a urls.py module which could hold Classes
defining URLs.  A
URL class might look like this:

class StartWorkflowURL:
    """Defines a bogus URL for testing.
    """

    _RE = r'^workflows/foo/(?P<init_param>\d+)/'
    _init_param = 0

    def __init__(self, init_param=0):
        """URL to a workflow.
        """
        self._init_param = init_param

    def RE(self):
        return self._regex

    def url(self):
        return '%s/workflows/foo/%d/' %
(DEPLOYMENT_PREFIX, self._bar)


The Class RE method allows the RE to be included in
urlpatterns:

urlpatterns = patterns('',
    (StartWorkflowURL().RE(), 'start_workflow'),
)


I know that this definition could be improved upon (it may
not even be
valid Python).  There's probably a more 'pythonic' way
(I'm a Java guy
who thinks in classes still).  But the idea is that if you
want to link
to the Admin application, you ask the Admin application to
tell you
how.

All right.  That's enough for now.  Don't know if anyone
is interested
in dissecting this, but I thought I'd get it out there as
an idea.  Not
a proposal, suggestion, or anything else.  Just an idea.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

I'm not sure if this was earlier missed or ignored by
people [nobody
explictly ruled it out], I can't help but think Django's
URL handling
will either drift towards re-implementing Routes:
http://routes.groovie.org/
 or staying as it is.  (note the lastest
version has a nice feature where you can pass in a function
to do
pre-processing or whatever you want to args and such before
creating a
Route or matching it).

I'll end my broken record impression now, won't mention it
again...


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On 3/30/06, ToddG <tdgrmsngmail.com> wrote:
>
> I'm not sure if this was earlier missed or ignored by
people [nobody
> explictly ruled it out], I can't help but think
Django's URL handling
> will either drift towards re-implementing Routes:
> http://routes.groovie.org/
 or staying as it is.  (note the lastest
> version has a nice feature where you can pass in a
function to do
> pre-processing or whatever you want to args and such
before creating a
> Route or matching it).

I hate to say it, but Routes and most of the other schemes
presented
_do_ feel over-engineered.  The current URL patterns system
is fast
and clean.  The get_absolute_url() pattern is simple one,
and yes it
might break the "perfect Model seperation", but
Django makes no qualms
that it absolutely has to follow MFC or PCMEF or whatever
else, but
instead keeps in mind a good idea of what is
"pragmatic".

I would only suggest that renaming to perhaps
get_canon_url() might be
somewhat less confusing, in that it refers to a canonical
URL rather
than the preferred URL or every URL. (For example, my most
common
problem is the objects that have many different URLs in the
same
project based on semantic differences (ie, same object to
admin,
different object to user).  In some cases get_absolute_url()
points to
the canonical URL that fits 85% of the cases and that view
will do
semantic redirects if necessary.)

The ABSOLUTE_URL_OVERRIDES tool is a handy convenience to
fix this
seperation problem, and with it you can do all sorts of
crazy things
(thanks to the pythonic ability to pass around functions)
like
implement your own project-specific mini-routes or whatever
(see my
previous post on the subject).

--
--Max Battcher--
http://www.worldmaker.net/

All progress is based upon a universal innate desire on the
part of
every organism to live beyond its income. --Samuel Butler

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

> I hate to say it, but Routes and most of the other
schemes presented
> _do_ feel over-engineered.  The current URL patterns
system is fast
> and clean.

I actually agree 100%.  And my earlier post indeed smacks of
overengineering.  And in my current smallish project I
don't intend to
do any of that kind of encapsulation.

With that said, I do think that the issue has legs if you
were to pull
in 3 or 4 or 5 projects from different sources to create
some kind of
new all-encompassing proejct.  E.g., Admin, ShoppingCart,
Inventory,
and PayPayIntegration.  (Assuming those to be 3rd party
apps).

It certainly doesn't need to be solved for me to use
Django, though.

See?  As I promised, I've overthought this whole thing.  I
_must_ learn
to think more agile. :-(


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On Thu, Mar 30, 2006 at 03:07:01PM -0500, Max Battcher
wrote:
> I hate to say it, but Routes and most of the other
schemes presented
> _do_ feel over-engineered.  The current URL patterns
system is fast
> and clean.  The get_absolute_url() pattern is simple
one, and yes it
> might break the "perfect Model seperation",
but Django makes no qualms
> that it absolutely has to follow MFC or PCMEF or
whatever else, but
> instead keeps in mind a good idea of what is
"pragmatic".

Earlier this week I noted that I believe get_absolute_url
just does not
belong in the Models... period.  I suggested an alternative
that I think
would be easy to use, easy to implement, and would
"fit".

I didn't however, try to suggest the exact Django way to
describe it
since I was specifically trying to NOT get bogged down into
that
naming / implementation idea, rather to let the developers
mull on
it as one idea to consider.

But, it didn't seem to get any comments pro or con, so let
me try again:

I believe that the Model should have a common method used
to get a PART of a URL, the part that locates this object. 
That part
of the URL might be "place/<objectid>" or
"poll/<slug>".  But that
is not an absolute url.  It would then be up to the view (in
a generic
view, that should be handled by a dict entry) to pre-pend
something in
front of what the model provide to make it a URL.

perhaps:

In Models:    get_url()
  returns a string that can be used by the view to make up a
URL that
  uniquely identifies this object.

In urlsconf:
  add to "infodict" -- 'url_view': 'polls'

In the view:
  you form a url from:   URL_BASE + 'url_view' + get_url()
  ( URL_BASE might not even be needed )


-- 
Glenn

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

On 3/30/06, Glenn Tenney <gt-djangothink.org> wrote:
> But, it didn't seem to get any comments pro or con, so
let me try again:
>
> I believe that the Model should have a common method
used
> to get a PART of a URL, the part that locates this
object.  That part
> of the URL might be
"place/<objectid>" or
"poll/<slug>".  But that
> is not an absolute url.  It would then be up to the
view (in a generic
> view, that should be handled by a dict entry) to
pre-pend something in
> front of what the model provide to make it a URL.
>
> perhaps:
>
> In Models:    get_url()
>   returns a string that can be used by the view to make
up a URL that
>   uniquely identifies this object.
>
> In urlsconf:
>   add to "infodict" -- 'url_view':
'polls'
>
> In the view:
>   you form a url from:   URL_BASE + 'url_view' +
get_url()
>   ( URL_BASE might not even be needed )

Since I'm feeling vocal:  I saw that and I would suggest
that I'm -0
on the idea.  It is a decent idea, but it isn't so much a
framework
need than it is an application/project pattern need.  Sure,
people are
decrying that there is no "one way" pattern
right now, but I think
until one emerges that we can all agree on, there isn't
enough pain in
the current process of brokering between applications to
warrant the
effort of establishing that standard.

With that said, you are completely free to use the above
pattern, or
something similar to it, in _the existing framework_.  The
current
thing about the current framework functionality being that
it is a
simple minimum and it is reasonably powerful.  Here's what
you could
do:

Create your get_url() functions as you specified.  Then you
have a
simple enough get_absolute_url():

def get_absolute_url(self):
    return DEFAULT_URL_BASE + self.get_url()

That satisfies both you (you just care about the get_url())
and the
Framework (which, really, the only major Framework part that
uses
get_absolute_url() is contrib.shortcuts and contrib.admin,
and maybe
by now several template designers are used to it).

If you want a dynamic URL base you are even free to create a
get_url_base_from_view() function and call it from
ABSOLUTE_URL_OVERRIDES, like so:

ABSOLUTE_URL_OVERRIDES = {
    'myapp.mymodel': lambda o:
magic_get_url_base_from_view() + o.get_url(),
}

Again, zero changes to current functionality and you have
your custom
functionality that your end users (aka, other developers)
may or may
not thank you for when they set out to customize your
application, and
it shouldn't interfere with my (or the next developers) own
preferred
way of dealing with things (in some ways I'd heavily argue
that the
URL scheme is highly dependent on the type of application in
question,
anyway, and we aren't going to agree on a standard
pattern).

The only feature I could see a call for in this particular
case,
because you are going to have a strong, repetitive pattern
here in
your ABSOLUTE_URL_OVERRIDES, and that isn't very DRY, is
that maybe
you could use some sort of pattern matching in
ABSOLUTE_URL_OVERRIDES
like being able to use 'myapp.*' or '[myapp1,
myapp2].*'.

--
--Max Battcher--
http://www.worldmaker.net/

All progress is based upon a universal innate desire on the
part of
every organism to live beyond its income. --Samuel Butler

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---