I'm trying to remove the date, time, and multiselect fields from the wagtailstreamforms Admin page, such that they can't be used in any form site-wide.
I've tried calling register('<field_name>', None) to get rid of it, but this doesn't work:
# wagtailstreamforms_fields.py
from wagtailstreamforms.fields import register
#register('date', None)
#register('time', None)
#register('multiselect', None)
And creating an AppConfig to manually purge the wagtailstreamforms.fields._fields dict of the entries, but that doesn't seem to work either. I've made sure that this AppConfig is part of an app that loads after wagtailstreamforms.
class UpdatedConfig(AppConfig):
name = 'my_new_app'
def ready(self):
from wagtailstreamforms.fields import _fields
_fields.pop('date')
_fields.pop('datetime')
_fields.pop('multiselect')
for x in _fields.keys():
print('{}: {}'.format(x, _fields[x]))
Is there any way to do this, hacky or otherwise? I'm using Wagtailstreamforms 3.1 and Wagtail version 2.2.2.
Im the author of wagtailstreamforms and came across this. The ability to restrict what default form fields are loaded from the package is a great idea.
What I propose is to not load them from the the register method but to load them from a settings dict ie:
WAGTAILSTREAMFORMS_DEFAULT_FIELDS = {
'singleline': 'wagtailstreamforms.fields.SingleLineTextField',
'multiline': 'wagtailstreamforms.fields.MultiLineTextField',
'dropdown': 'wagtailstreamforms.fields.DropdownField'
}
the defaults being all the internal fields. This way it can easily be overridden. We will leave the register decorator in place as to not break anything.
https://github.com/AccentDesign/wagtailstreamforms/pull/110
Please leave any comments / suggestions on the pr or the open issue. If you are happy with this will update docs, merge, release then can amend this as an answer.
Cheers, Stu.
One way would be to override this template: https://github.com/wagtail/wagtail/blob/master/wagtail/admin/templates/wagtailadmin/block_forms/stream_menu.html
{% for child_block in child_blocks.list %}
{% if child_block.name != "date" and child_block.name != "datetime" and child_block.name != "multiselect" %}
<li><button type="button" class="button action-add-block-{{ child_block.name }} icon icon-{{ child_block.meta.icon }}"><span>{{ child_block.label }}</span></button></li>
{% endif %}
{% endfor %}
We were able to get what we needed by putting following code in the app's wagtailstreamforms_fields.py
# wagtailstreamforms_fields.py
from wagtailstreamforms.fields import _fields
if _fields.get('date'):
del(_fields['date'])
if _fields.get('datetime'):
del(_fields['datetime'])
if _fields.get('multiselect'):
del(_fields['multiselect'])
So I guess you can say its a mix of the above 2 methods. It might be obsolete in the near future, see Stuart George's answer and its linked PR.
Related
I have an app with a Restaurant model. I'd like to understand what is the best way to put together a view that displays the list of restaurant objects, but also has a search form above that a user could enter parameters to filter the results displayed. If no parameters are entered, all the restaurants should be shown. I'm already using haystack and have a search form, but currently it is on a standalone search.html template. I also have an ListView on a separate template, and I guess I'm looking for an end result that combines these.
I did some reading on line and it's unclear what the best way to do it is:
using just listview from Django with some queryset filtering
combining haystack SearchView with django class based views?
this is my best bet so far - creating a customized version of SearchView from Haystack
ideally, ultimately the search capabilities would include things like allow autocompleting the user's inputs, and dynamically filter the results as the user types.
any thoughts on what the best way is to go about this and any examples out there?
There probably is out there some package that gives you everything automatically, displaying the queryset list and allowing simple adding of a search bar and so on (like the admin site). But I take it you are still a beginner to web development, so I'd strongly suggest you drop the listviews, drop haystack, drop everything, and do it all yourself.
See, they're not bad approaches or anything, but they're like shortcuts. And shortcuts are good only if they shorten the original way, which in your case isn't all that long.
To give you an example, here's a simple approach to displaying a list of items:
views.py
def restaraunt_list(request):
restaraunts = Restaraunt.objects.all().order_by('name')[:100] # Just for example purposes. You can order them how you'd like, and you probably want to add pagination instead of limiting the view number arbitrarily
context = {'restaraunts': restaraunts}
return render_to_response('index.html', context)
index.html:
<ul>
{% for rest in restaraunts %}
<li>{{ rest }}</li>
{% endfor %}
</ul>
That's it. Now it displays it in a list. Now to add a search filter all you need to do is this:
index.html (add this anywhere you want it)
<form>
<input type='text' name='q' id='q'></input>
<input type='submit' value='search!'></input>
</form>
When a user sends the data from 'q' it is sent through GET, and then on server side you add this:
def restaraunt_list(request):
restaraunts = Restaraunt.objects.all()
# filter results!
if request.method == 'GET':
q = request.GET['q']
if q != '':
restaraunts = restaraunts.filter(name__contains=q)
# ordering is the last thing you do
restaraunts = restaraunts.order_by('name')[:100]
context = {'restaraunts': restaraunts}
return render_to_response('index.html', context)
Now, this will work, but from what you wrote I understand you want the search to be live the moment a key is pressed. For that, you'd need to use AJAX (go learn how it works, I'm not gonna delve into it here). As for autocomplete, you should check out jQuery UI.
But, like I said, before jumping ahead and using all those stuff, I suggest you first learn the basics. Go through the django tutorial (if you haven't already), and use the amazingly detailed django-docs every step of the way. When some specific things won't work and you're stuck, come here to Stackoverflow and someone will surely help you. good luck!
I'm working on a project in Django.
Earlier today, I discovered the new (Django >= 1.4) assignment_tag. I immediately decided that it was just what I needed EVERYWHERE and threw some logic into one that executed a very simple query against the database and returned the resulting queryset. The function I wrapped takes an argument that allows the invoking context to specify how many results to grab, directly in the template when I am using the template tag.
It is quite convenient - I don't have to update my view when I decide this list should have 5 items, not 3 - but it seems like one of those gray areas where we aren't supposed to tread (i.e. pushing application logic into templates) when writing good, maintainable Django code.
Now, a couple of hours separated from writing the code, I'm wondering if I should scrap the assignment_tag entirely.
Code:
models.py:
class SomeObject(models.Model):
is_active = models.BooleanField(default=False)
(...)
templatetags/myapp_tags.py:
from django import template
from myapp.models import SomeObject
register = template.Library()
#register.assignment_tag
def get_someobjects_list(max_results=0):
queryset = SomeObject.objects.filter(is_active=True)
if max_results == 0:
return queryset
elif max_results > 0:
return queryset[:min(max_results, queryset.count())]
else:
return None
templates/myapp/chunks/someobject_list.html:
{% load myapp_tags %}
{% get_someobjects_list as someobjects_list %}
# or {% get_some_objects_list 5 as someobjects_list %} ... flexible!
{% if someobjects_list %}
<ul>
{% for someobject in someobjects_list %}
<li>
<a href="{{ someobject.get_absolute_url }}">
{{ someobject.name }}
</a>
</li>
{% endfor %}
</ul>
{% else %}
<span>No someobjects exist</span>
{% endif %}
I was really excited to discover these existed - it's convenient for me in this particular case. Now that my excitement over finding a new feature has passed, it seems pretty clear that I'm misusing it. The example given in the Django docs seems like a better application of this - grabbing the string representation of current datetime, something that doesn't require a DB query. My worry is that I'm setting myself up for heartache if I start using this pattern regularly. Following the slippery slope all the way down: I'll end up not even bothering to pass a context to my templates and ALL my DB queries will be hidden away in template tags where nobody would think to look for them.
It seems the code would be cleaner if I just threw out this whole "great idea" I had when I discovered assignment_tags and created a custom model manager instead.
Are there other clean ways of accomplishing this that I am missing? Are manager methods the consensus best way among Django developers?
assignment template tags are especially helpful if you need to get some information into the template context for a few pages of a website, but don't want to (or can't) put the info into every view on the website, and don't want to or can't rely on a context processor.
they basically guarantee that your information will be available in the template.
How can I check placeholder content existence and make next trick? :
{% if placeholder 'Head_text' %} <--check here
<div class="in">
...
...
<h2 class="title">{% placeholder 'Head_text' %}</h2>
...
...
</div>
{% endif %}
I want to know, does placeholder have some content before rendering some special HTML-structure for it.
Thanks.
I was looking for a solution for this and I found a few alternatives instead of checking if the placeholder exists. Basically the idea is to use a different plugin instead that adds the extra html. There are a few packages you can install with pip. Now, after trying them I just did it myself and it was much more easier than using the packages.
cmsplugin-text-wrapper: It integrates to the existent django-cms default text plugin keeping the editor but adds a selector on top so you can select a wrapper. The wrapper contains the extra html you would like to add. It also has a nice CSS system to add classes. On the downside, I didn't want to make the editors life more difficult with the extra template selector.
cmsplugin-text-ng: This basically adds a new plugin. When you add the plugin to your placeholder, it display a selector with the available templates (that contains your extra HTML). What I really like is that you can add extra fields that you can use in your customized HTML. For example, you could add a title so the plugin displays an extra textfield for it. On the downside, the templates are store in the database through the admin!. That is an extra hit to the database and I really don't want to sacrifice it for something too simple.
Do your own plugin using the existent Text Model. Four very simple steps:
3.1 Basically add this to your cms_plugins.py:
from cms.plugin_pool import plugin_pool
from cms.plugins.text.models import Text
from cms.plugins.text.cms_plugins import TextPlugin
class WidgetPlugin(TextPlugin):
model = Text
name = _("Widget")
render_template = "widget.html"
def render(self, context, instance, placeholder):
context['instance'] = instance
return context
plugin_pool.register_plugin(WidgetPlugin)
3.2 Create your widget.html template in your templates folder:
<div class="in">
...
...
{{ instance.body|safe }}
...
...
</div>
3.3 Place your placeholder wherever you want:
{% placeholder 'Head_text' %}
3.4 Make the user use the new plugin adding the Head_text configuration plugin in the settings.py:
CMS_PLACEHOLDER_CONF = {
#...
'Head_text': {
'plugins': {'WidgetPlugin'}
},
}
I've had this problem before, and when I researched it (this might have changed since) there is no built in way to do this, so you have to write your own template tag to load the placeholder into a variable.
Here are some discussions on the django-cms mailing list:
https://groups.google.com/forum/?fromgroups=#!topic/django-cms/QeTlmxQnn3E
https://groups.google.com/forum/#!topic/django-cms/2mWvEpTH0ns/discussion
I have a 'live settings' app which I use to store certain global site settings. Certain pages of my site reference these settings, although generally they only use 2-3 at a time. I access these settings using a custom template tag like so:
{% settings site_name %}
Each time I use this tag, the model will retrieve the setting from the database, so if I had something like:
{% settings site_name %} {% settings num_articles %}
the database would get queried twice.
What I'd like to do is not hit the database more than once per page for the settings values, if I could get all the settings used on a page and then hit the database to retrieve them all, that would be much better.
I had a look through the documentation and it seems Django has no pre render signal which I could use to update any references to the settings, so does anyone have any suggestions how I could optimise this system? And yes obviously caching is the obvious answer but I'd still like to improve on this for when the page isn't cached.
Agreeing with Daniel that process_template_response is the hook you're looking for. I don't know how many settings you have, but it could also make sense to retrieve all settings once, and store them in some dictionary like structure, so you can access them anytime without hitting the database. You could retrieve them once either per request, or - even if your settings do barely change - when django initializes. You could additionally use django's signals to update your cached settings on delete or update.
If you have a look at django-dbsettings you will see it does a similar thing!
Django 1.3 includes the new TemplateResponse class, which allows you to modify the response later in the rendering process - eg in middleware. This looks like it might do what you want.
If you wish to stick to a scheme similar to what you already have, I'd implement a filter that takes in a list of keys and returns a dict with all the relevant values.
Example filter:
def get_settings(key_list):
# take values from conf.settings. In practice, can be from any source
return dict((k, getattr(settings, k, None)) for k in key_list.split(","))
register.filter("get_settings", get_settings)
Usage:
{# load multiple values with a single call #}
{% with "KEY1,KEY2"|get_settings as settings %}
setting values {{ settings.KEY1 }} and {{ settings.KEY2 }}
{% endwith %}
Note that I used a filter instead of a tag because the with builtin expects a single value before as.
New to python and django. Using the forms module and going through the errors one by one (so not just dumping them at the top)
I noticed this solution to be able to set a custom format for errors, in my case, it'd be:
<dd class="error">errstr</dd>
And more or less copying the example provided, I have the following:
forms.py ( I expanded it slightly just for my sake)
class DefinitionErrorList(forms.util.ErrorList):
def __unicode__(self):
return self.view_as_dd()
def view_as_dd(self):
if not self:
return u''
return u'<dd class="error">%s</dd>' % '<br />'.join([u'<span>%s</span>' % e for e in self])
main.py
from poke.forms import PokeForm, DefinitionErrorList
def create_new(response, useless):
if response.method == 'POST':
# They posted something, so collect it (duh)
f = PokeForm(response.POST, error_class=DefinitionErrorList)
if f.is_valid():
cd = f.cleaned_data
template for reference
<dt>A small message to remind yourself</dt>
{{ form.message.errors }}
<dd>
<span class="input_border" style="width: 75%;"> {{ form.message }}</span>
<span class="tooltip_span">{{ tooltip.message }}</span>
</dd>
The problem is is that with the above, if a field has an error, it still uses the default format (the ), and no matter what I try I can't get my one to be used. I'm pretty sure I missed something small or misunderstood some instructions.
Thanks for any help and I'm sorry if I forgot any information!
Edit: I'm using Django 1.1, if that helps any. And to make it (possibly) clearer, the errors are displaying fine, they just aren't looking the way I want them to.
there has been a long lasting ticket on this. http://code.djangoproject.com/ticket/6138
latest update says it's fixed. see if it works in trunk. if not, submit your bug. if it does, get the patch or wait til the next release. (although i thought the latest release was after the date of the last update on the ticket).