Concept of partial views to be resolved from other views or template tags

[Stephan Herzog]

Hi all,

I am wondering if the following is considered a bad practice and might lead to issues. I think it provides a useful pattern, for example for creating template tags or simple ajax use cases where the rendered result of a partial will get frequently updated.

# partials.py
class SomePartial(View):
    """ A view providing partial content. """
    def get(self, request):
        # related views logic like lookups ...
        return render(request, 'patterntests/_partial.html', {})

# views.py
class SomeView(View):
    """ Including the partial by calling get on `SomePartial`. """
    def get(self, request):
        someview = SomePartial()
        res = someview.get(request)
        ctx = {
            'partial_content': mark_safe(res.content)
        }
        return render(request, 'patterntests/test.html', ctx)


class AnotherView(View):
    """ Including the partial by resolving its view. """
    def get(self, request):
        rev = reverse('patterntests:somepartial')
        view, vargs, vkwargs = resolve(rev)
        vkwargs['request'] = request
        res = view(*vargs, **vkwargs)

        ctx = {
            'partial_content': mark_safe(res.content)
        }

        return render(request, 'patterntests/test.html', ctx)

My main question is about the following two lines in SomeView. Does that have serious flaws (edge cases, performance, security)?

class SomeView(View):
    def get(self, request):
        # ...
        someview = SomePartial()
        res = someview.get(request)
        # ...

I like that approach because it leads to any partial being a separated piece of logic that can be tested and developed on a dedicated url. If necessary it can be wrapped in a templatetag, which makes it easy to use from the template layer. On top of that, by implementing something like a format='json|html|xml|...' attribute it could be further improved to allow for more advanced ajax use cases. However, since I've not seen it being used that way I think that this might be for a good reason. (-:

Would appreciate your feedback,

Regards,

Stephan

[Javier Guerra Giraldez]

On Sat, Apr 25, 2015 at 3:11 AM, Stephan Herzog <sthz...@gmail.com> wrote:
> I like that approach because it leads to any partial being a separated piece
> of logic that can be tested and developed on a dedicated url. If necessary
> it can be wrapped in a templatetag, which makes it easy to use from the
> template layer.

you might be interested in ESI (edge side includes, (partially)
implemented by Varnish [1]) or SSI (Serve Side Includes, as done by
Nginx [2]). they allow you to describe the 'assembly' of HTML in the
front end, using several fragments retrieved from the backside server
(Django), each one cached independently.

not only you get modularity of code and testability as you describe,
but also avoid the overhead of assembling everything in Python. you
get more URLs and each request could potentially multiply by a sizable
factor, but you get to easily cache complex pieces that stay constant
even if other parts are more variable, or constant on a different
variable...


[1]: https://www.varnish-cache.org/docs/3.0/tutorial/esi.html
[2]: http://nginx.org/en/docs/http/ngx_http_ssi_module.html

--
Javier

[Stephan Herzog]

Thanks for your reply. We are actually using ESIs in one place or another and one of the projects I have in mind for refactoring currently uses ESI to achieve something similar. Varnish however is an additional layer on the server that in many of our cases is not really necessary (as in either not easily available, not maintainable or simply not justified for the amount of traffic). But more than that I think it is not suitable as a default when developing something with reusability in mind. I feel that users of a package are still free to include the partials through ESI or SSI, if their stack provides that option. But if not then maybe (or maybe not) the outlined code would be an option.