Hardcoded links

[johnnie pittman]

Ok, so I've got two completely different issues and will fire them off in two seperate emails for discussion.  But to explain a bit, I thought about filing these issues as bugs.  They really aren't bugs but implementation details or I should say feature requests than real problems.  However, they do hinder easy integration of snapboard into third party projects like mine.  ;)

So the first thing I'm tripping up on is "snapboard" being hardcoded in the links coming out of both templates and views.  When I added a url entry for the snapboard app into my url:

    (r'^forum/', include(' webapps.snapboard.urls')),
    (r'^forums/', include('webapps.snapboard.urls')),

Initial links into the app worked great.  But then when I followed any other link inside the app, it was expecting:

    (r'^snapboard/', include(' webapps.snapboard.urls')),

and would error out.  I added the line above to my project urls.py just to get things working but that doesn't fall in with the url pathways I want to enforce.

I did some digging to find out if there was a way to rewrite the urls inside of templates or views dynamically.  In my case, I would want links that started with "snapboard" would return "forums" instead.  Turns out there isn't a way to do that directly.  From an implementation perspective, links inside the app would need to be one of two things:

 - relative, which makes it difficult to have any hierarchy url structure (like the way threads work currently)
 -  or you need some form of a top level variable specified in settings (or some app level local settings module) and a tag that read {{ top_level }}

The second approach is what's recommended in http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters and would seem to fit in directly with what's been implemented right now. 

Any thoughts?

[Bo Shi]

I've actually run into the same problem :P

I'm currently going through the templates and making modifications per
the second approach you described. Should be in trunk in the next few
days.

Regards,
Bo

[Bo Shi]

in examplesite/settings.py, svn rev. 97, the following comment was
added to describe the new changeable snapboard prefixes

# SNAPBoard specific OPTIONAL settings:
# The following are the defaults, so you only need to set them if you want to
# change them. Note the lack of trailing '/'
#
#SNAP_PREFIX = '/snapboard'
#SNAP_MEDIA_PREFIX = MEDIA_URL + '/media'

[Bo Shi]

Also, note the new context processor that must be included for things to work.

[johnnie...@gmail.com]

yeah, caught that after adding in the variables to the config file. I
hacked a couple of views to add it in, but I'll wait til you've
checked in more changes before I play with it. But those options
solve both my problems. I'll update the wiki with instructions.

On Feb 9, 7:23 pm, "Bo Shi" <bs1...@gmail.com> wrote:
> Also, note the new context processor that must be included for things to work.
>
> On 2/9/07, Bo Shi <bs1...@gmail.com> wrote:
>
> > in examplesite/settings.py, svn rev. 97, the following comment was
> > added to describe the new changeable snapboard prefixes
>
> > # SNAPBoard specific OPTIONAL settings:
> > # The following are the defaults, so you only need to set them if you want to
> > # change them. Note the lack of trailing '/'
> > #
> > #SNAP_PREFIX = '/snapboard'
> > #SNAP_MEDIA_PREFIX = MEDIA_URL + '/media'
>
> > On 2/9/07, Bo Shi <bs1...@gmail.com> wrote:
> > > I've actually run into the same problem :P
>
> > > I'm currently going through the templates and making modifications per
> > > the second approach you described. Should be in trunk in the next few
> > > days.
>
> > > Regards,
> > > Bo
>

[johnnie...@gmail.com]

Hey, so quick question about the new variables in the settings file.
Are third party folks using the app (like me) expected to add in the
snapboard_default_context processor for each of the views? So for
example:

return render_to_response('snapboard/thread.html',
render_dict,
context_instance=RequestContext(request,
processors=[login_context, snapboard_default_context]))

or are we expected to implement usage of the variable
TEMPLATE_CONTEXT_PROCESSORS mentioned in the docstring of
snapboard_default_context?

thanks

On Feb 10, 4:40 pm, "johnnie.pitt...@gmail.com"

[johnnie...@gmail.com]

my mistake. didn't read the settings file documentation completely.
Missed that as variable option. However, also interesting that
googling for it didn't pick it up either.

All's good now.

On Feb 11, 12:38 pm, "johnnie.pitt...@gmail.com"

[Bo Shi]

I found the (hopefully) last two cases of hard-coded URLs in thread.js
and have updated trunk so that autosuggest (for private messages) and
viewing previous revisions of posts works properly for non /snapboard
URL configurations.

(rev. 130)