Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Re-Thinking Apphooks (3.0 Feature Proposal) #1498

ojii opened this Issue Nov 1, 2012 · 7 comments


None yet
4 participants

ojii commented Nov 1, 2012

So I had this idea on how we can make apphooks suck less. A way we can kill the dreaded "restart server on apphook change".

Here it goes.

Instead of attaching an apphook, which potentially adds menu nodes, why not attach views to pages? And instead of creating menu nodes, an apphook creates pages.

We'd provide an easy way to sync models with pages.

Apphooks tell which parts of the URL we should pass to the attached views.

It could look a little like this:

class AwesomeTeamApphook(Apphook):
    def setup(self):
        page = self.attach('myapp.views.index')

When the apphook is attachd, it attaches the view 'myapp.views.index' to the page the apphook is on. It gets no extra arguments. It creates a page under that page for each published TeamMember. When the page is called, it extracts the slug from the last bit of the URL. When a TeamMember is saved/deleted, it creates/removes pages accordingly and attaching the myapp.views.detail view to them.

On rendering, maybe instead of {% placeholder %} there could be a {% view_content %} or similar tag to render the bits from the view. Or alternatively it just uses the view to render the page.

I have no idea whether this is feasible, just wanted to share a crazy idea I had.


ojii commented Nov 2, 2012

One issue that will arise with this system is that reversing is a bit tricky. The URLs never really get included using this method. As a result the CMS urlpatterns need to have a custom resolver which when the reverse method is called, does a DB/cache/localcache lookup for a page with the URL name that is being reversed. This should be possible (in a multithreaded/multiprocessing way), but won't be trivial and potentially has performance implications.


ojii commented Nov 2, 2012

Updated OP to have a better example.

Blog posts would probably not generate menu entries, so they'd not use the new 'sync-pages' system. Meaning we'd still need an alternative way of handling this.

OR if our system can handle huge page trees, it'll still create page entries, just with in_navigation=False.


ojii commented Nov 2, 2012

Pages with a view attached would be drag'n'drop-able, but only within one level (as in, they are enforced to have the parent set by the apphook as parent). This allows something that wasn't possible before: Mixing cms pages and apphook-pages on one menu level, with the order defined by the user.


ojii commented Nov 2, 2012

Proof-of-concept dummy playground app: https://github.com/ojii/new-apphooks


stefanfoulis commented Nov 7, 2012

An added benefit of this approach would be, that cms page permissions could extend to the apphook urls.
E.g a blog that is only viewable to logged in users.


digi604 commented Jun 24, 2013

How about we change the page to have a "content" model... a Page base class where others can extend similar to cmsplugin. If you create a page you can choose what kind of content model it has. Then this page can do all the crazy shit and render views or whatever. The only problem i see is with reverse as well... but would 1 DB query or 1 cache hit be sooo bad?

@digi604 digi604 added this to the 3.X milestone Feb 10, 2014


evildmp commented Oct 19, 2015

This is fixed in 3.2

@evildmp evildmp closed this Oct 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment