OK I think you are talking about something like https://docs.djangoproject.com/en/dev/intro/tutorial02/#adding-related-objects where I could just insert a slider type of entry and then a text entry and so on. Is that it?
On Wednesday, 26 February 2014 14:49:55 UTC-8, C. Kirby wrote: > > It doesn't have to, I guess it depends on how involved the creation tools > are that you create. Quick and dirty idea off the top of my head: > If the authoring tools define post widgets (body, text, scroller, video, > etc) you could let authors drag and drop the elements as they wish. On the > model side, make all resources extend a base class of BlogResource type, > then for each blog post have a many to many through table that stores > ordering: > PostID(foriegn=blog) > ResourceID(genericforeignkey to blog resource) > OrderID(int) > > or somthing like that. > > Regards, > ~CK > > On Wednesday, February 26, 2014 4:18:14 PM UTC-6, Dennis Marwood wrote: >> >> Won't this force my blog posts to all be the same. i.e. Text then a image >> scroller? >> How would I handle the case where a blog post was Text, image scroller, >> text, image scroller? >> >> On Wednesday, 26 February 2014 13:35:01 UTC-8, C. Kirby wrote: >>> >>> It sounds like your implementation is a little skewed. >>> If a blog post is made of multiple resources (summary, body, multiple >>> image collections, etc.) You should probably have a model or models with >>> the appropriate fields/relationships. That way your template can house all >>> of the template language, and you build a single, user facing blog post >>> from the elements in the blog post model(s). >>> This also gives you the benefit of making the various resources >>> available in other ways (eg. Show all my image collections, share >>> collections, etc) as well as change your layout in the future without >>> having hard-coded template calls in your content. >>> >>> Regards >>> ~CK >>> >>> On Wednesday, February 26, 2014 3:18:54 PM UTC-6, Dennis Marwood wrote: >>>> >>>> Thanks. I look forward to trying this soon. >>>> >>>> I feel like I may be trying to swim against the current with this. Is >>>> this a problem with the way that I have decided to implement my blog or >>>> are >>>> these workarounds typical for django applications? >>>> >>>> On Wednesday, 26 February 2014 04:15:15 UTC-8, Tom Evans wrote: >>>>> >>>>> On Wed, Feb 26, 2014 at 5:29 AM, Dennis Marwood <[email protected]> >>>>> wrote: >>>>> > Thanks. I believe this is what I am looking for. However I am still >>>>> running >>>>> > into an issue w/ the fact that I am pulling my blog entries from the >>>>> db. >>>>> > This is causing the template to interpret the {% image_slider %} as >>>>> a >>>>> > string. >>>>> > >>>>> > From view.py: >>>>> > def blog(request): >>>>> > entries = >>>>> > >>>>> Project.objects.filter(destination="blog").order_by('-creation_date') >>>>> > return render(request, 'content.html', {"entries": entries, >>>>> > "page_title": "Blog", >>>>> > "description": >>>>> "Blog"}) >>>>> > >>>>> > And in content.html: >>>>> > {% for each in entries %} >>>>> > <p>{{ each.entry }}</p> >>>>> > {% endfor %} >>>>> > >>>>> > And a blog entry: >>>>> > Hello! Check out this collection of images. {% image_slider %} And >>>>> this >>>>> > collection! {% image_slider %} >>>>> > >>>>> > >>>>> > I don't want to hard code the inclusion tag in the content.html. >>>>> Instead I >>>>> > want to call it from the blog post. Is this possible? >>>>> >>>>> Yes. You will need to write a custom template tag to parse the >>>>> contents of the object as a template, render it within the current >>>>> context and return the generated data. >>>>> >>>>> Writing a custom template tag: >>>>> >>>>> >>>>> https://docs.djangoproject.com/en/1.6/howto/custom-template-tags/#writing-custom-template-tags >>>>> >>>>> >>>>> Rendering templates to string: >>>>> >>>>> >>>>> https://docs.djangoproject.com/en/1.6/ref/templates/api/#rendering-a-context >>>>> >>>>> >>>>> Your content.html would then look something like this, assuming you >>>>> called the custom tag 'render': >>>>> >>>>> {% for each in entries %} >>>>> <p>{% render each.entry %}</p> >>>>> {% endfor %} >>>>> >>>>> Beware the massive security holes if you allow users to generate >>>>> content that your site then renders as a template. >>>>> >>>>> Cheers >>>>> >>>>> Tom >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c2f6e17b-08eb-4aa5-8cb5-bee4169016ea%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
