Modifying structure of frontpage for department from backend

[Pi2048]

@bartromgens is working on this - see, among others, commit 701a159885b712534704a66fb091aa8d00b9544b.

[bartromgens]

Ah! There is a ticket for this :) Thanks!

I'll make sure I find or create a ticket for new features/branches from now on.

[bartromgens]

Modification of the two page columns on the homepage of all sites (including departments) is now possible with commit 701a159885b712534704a66fb091aa8d00b9544b.

It allows to add a ColumnElementWidget to a HomePage in the admin interface (via inline). This widget contains a reference to a ColumnElement.

A ColumnElement is a generic foreign key; it can refer to any object that we allow. These ColumnElements are automatically created for each new object that is implemented/supported (only BlogCategories for now, Calendar/Agenda should be next).

The ColumnElementWidget contains the logic, for each supported object type, on how to create the items (like BlogPosts or events) to show, and the corresponding template to use. This template is inserted in the index.html template of the homepage when the page is viewed.

This concept allows a generic, extendible way to represent data objects on a page. And allows this to be done in the backend admin interface.

How to use A backend user can create a new ColumnElementWidget in the admin view of a HomePage. The widget has the following properties:

• A title that will be shown as header of the element.
• The ColumnElement it should represent. For example, a 'News' BlogCategory.
• The number of element items that the widget will display. For example, the number of BlogPosts.
• Left or right column can be selected via dropdown.
• Vertical order can be selected via drag-and-drop.

An example of the admin interface is shown in the screenshot below,

[bartromgens]

On a side node, I use 'Widget' to mean a user interface object. Comes from my frequent use of the Qt framework. If this is confusing in Django or web development. Or if there are other standards, please let me know so I can change my habits.

[Pi2048]

Very cool. This is exactly what I was hoping for :). I have confirmed this also works on department websites.

Now it is a bit confusing though. I have two entry fields, one for each horizontal position. However, when I enter a new widget, I can choose the horizontal position, regardless of which of the two entry fields I use! I would expect that this field would be hidden and would be automatically inferred from which entry field I'm using. In other words, if I create a widget in the tabular environment 'Left column widgets', it should automatically be added at the bottom of the currently existing left column widgets. Same for right column widgets.

[bartromgens]

In other words, if I create a widget in the tabular environment 'Left column widgets', it should automatically be added at the bottom of the currently existing left column widgets.

Good suggestion. Completely agree. I tried to find out how to set the default based on the inline field. Will try some more. This should be possible. Get back to you on this!

[Pi2048]

Maybe with this?

 if you set editable=False on the model field, any form created from the model via ModelForm will not include that field.

From https://docs.djangoproject.com/en/1.7/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form.

[bartromgens]

editable=False will hide the field, but then I still have to set the correct column based on the type of the inline (left or right).

This seems rather difficult due to the combination of the inline and the javascript of the admin. I tried and googled many things, but no full solution.

What I am able to do, and what I added in commit daaf131137de9dea1fe5a0a9185925f8140529c3, is setting the initial value of the left/right field to the correct value. However, I cannot do this when I hide the field or make it read-only. Moreover, when you click the 'Add another' button in the inline, the new field is not initialized correctly.

It is currently not worth the effort to improve this more by digging deep into Django formsets and the Grappelli javascript. Unless someone comes up with a simple solution.

[Pi2048]

Agree with your conclusion. The change you made seems to be the right one. We'll see how it works in practice.

[Pi2048]

To make this ticket complete, the following is needed:

• Add column widget type for 'upcoming events' (both local and national).
• Add column widget type for 'blog list' (compare the right-hand column of jdamsterdam.nl).

Am I correct, or am I missing something?

[Pi2048]

Could you also add information on the design of this feature to the design document?

[bartromgens]

Am I correct, or am I missing something?

Correct! Good call.

Could you also add information on the design of this feature to the design document?

Yes, I will. It is, or should be, part of the work :)

TODO:

• [x] upcoming events column widget
• [x] blog category headline column widget
• [x] design documentation and example

[Pi2048]

You can peek at the required template tags for upcoming events in /website/template/elements/tabs_sidebar_item.html.

I would create three ColumnElements when creating a new Site: one for upcoming events of the site, one for upcoming events of the main site and one for upcoming events of the site and the main site combined.

[Pi2048]

I would really like to show the frontpage structure functionality to the AS functionaries when they come by on Sunday. @bartromgens , could you look into this (i.e. finish the column widgets for upcoming events and blog lists)?

[bartromgens]

I will try to finish the events column widget tomorrow.

[bartromgens]

Merged feature/eventscolumnwidget in commit 756a65e5c91f4521aa6c77b618988024c93723f1.

Note that I used the same event options as available in the sidebar,

• site events
• site and main site events
• all events

There is no option available to show the main events only (on department sites). I can easily add this if the events/fullcalendar app supports this.

The event column elements that can be selected are automatically created when a site is created. This also happens when the demo_data fixture is loaded. The main site is created with name 'example.com' from the Mezzanine required fixture, so the event element for the main site has 'example.com' in the name. Minor issue that is not fixed yet, we can always change the name manually.

The blog list column widget will not be ready before Sunday.

[bartromgens]

Blog category headline column widget is added in commit 06fb4bb8dce55a6df2156aa1dd3843ffaa7ae234

[bartromgens]

Added design documentation for Page columns in commit accef0a07225b2ca6157f6cc7741fdc607b3c648

[bartromgens]

All major functionality related to this issue is implemented.

Therefore, I will close this issue. Please create a separate issue for remaining functionality or bugs.