Widgy Site

class widgy.site.WidgySite[source]
get_all_content_classes(self)[source]

Returns a list (or set) of available Content classes (widget classes). This is used

  • To find layouts from root_choices
  • To find widgets to put on the shelf (using validate_relationship() against all existing widgets in a tree)
urls(self)

Returns the urlpatterns needed for this Widgy site. It should be included in your urlpatterns:

('^admin/widgy/', include(widgy_site.urls)),
get_urls(self)[source]

This method only exists due to the example ModelAdmin sets.

Todo

is urls or get_urls the preferred interface?

reverse(self, *args, **kwargs)[source]

Todo

explain reverse

authorize_view(self, request, view)[source]

Every Widgy view will call this before doing anything. It can be considered a ‘view’ or ‘read’ permission. It should raise a PermissionDenied when the request is not authorized. It can be used to implement permission checking that should happen on every view, like limiting access to staff members:

def authorize_view(self, request, view):
    if not request.user.is_staff:
        raise PermissionDenied
    super(WidgySite, self).authorize_view(request, value)
has_add_permission(self, request, content_class)[source]

Given a Content class, can this request add a new instance? Returns True or False. The default implementation uses the Django Permission framework.

has_change_permission(self, request, obj_or_class)[source]

Like has_add_permission(), but for changing. It receives an instance if one is available, otherwise a class.

has_delete_permission(self, request, obj_or_class_or_list)[source]

Like has_change_permission(), but for deleting. obj_or_class_or_list can also be a list, when attempting to delete a widget that has children.

validate_relationship(self, parent, child)[source]

The single compatibility checking entry point. The default implementation delegates to valid_parent_of() of valid_child_of().

parent is always an instance, child can be a class or an instance.

valid_parent_of(self, parent, child_class, child=None)[source]

Does parent accept the child instance, or a new child_class instance, as a child?

The default implementation just delegates to Content.valid_parent_of.

valid_child_of(self, parent, child_class, child=None)[source]

Will the child instance, or a new instance of child_class, accept parent as a parent?

The default implementation just delegates to Content.valid_child_of.

get_version_tracker_model(self)[source]

Returns the class to use as a VersionTracker. This can be overridden to customize versioning behavior.

Views

Each of these properties returns a view callable. A urlpattern is built in get_urls(). It is important that the same callable is used for the lifetime of the site, so django.utils.functional.cached_property is helpful.

node_view(self)
content_view(self)
shelf_view(self)
node_edit_view(self)
node_templates_view(self)
node_parents_view(self)
commit_view(self)
history_view(self)
revert_view(self)
diff_view(self)
reset_view(self)

Media Files

Note

These properties are cached at server start-up, so new ones won’t be detected until the server restarts. This means that when using runserver, you have to manually restart the server when adding a new file.

scss_files

Returns a list of SCSS files to be included on the front-end. Widgets can add SCSS files just by making a file available at a location determined by its app label and name (see widgy.models.Content.get_templates_hierarchy()). For example:

widgy/page_builder/html.scss
js_files

Like scss_files, but JavaScript files.

admin_scss_files

Like scss_files, but for the back-end editing interface. These paths look like, for an app:

widgy/page_builder/admin.scss

and for a widget:

widgy/page_builder/table.admin.scss

If you want to included JavaScript for the editing interface, you should use a component.