Support for providing a default text for the block

[mandx]

Consider this syntax:

{% flatblock "page.info" %}
Here goes the default text of the flatblock named "page.info". When defining this block
the tag search for the flatblog with this name and include it's content. If the flatblock doesn't
exists, it would automatically create the flatblock record and fill the contents with this
very same text.
{% endflatblock %}

That way, the admin usage of flatblocks is reduced, and the final user only needs to change the needed flatblocks, and it's easier for the user to locate the right flatblock to edit because he can see the default contents that's being displayed, besides the flatblock's name. Also there's no need to create the flatblocks in the admin, the are created as needed (as the template gets rendered), and therefore ready to edit.

This is a better way to provide initial data from the designers, since they don't have to mess around with fixtures.

[kmike]

huge +1, I was about to submit the same issue several months ago but this gets lost in my TODO list ;)

What do you think about an another name for this tag?

{% editable "page.info" %}
default text
{% endeditable %}

The name 'flatblock' is already used, it can be ambiguous and technically harder to implement.

[mandx]

@kimke I just coded my variant Anyway now I'm thinking that some things can be improved on what I have done. I used {% flatblock_default %}{% end_flatblock_default %} for the template tags name, that's what came out at the momente :) I guess I was more focused on getting the tag working than the name.

[zerok]

I really like the idea of having some kind of default text but I'm personally not 100% convinced about the "magical" auto-creation of the block. There is also the problem that this block might include some header which should perhaps be handled as a "kwarg"-like argument to the tag in the default-text scenario. I'm thinking about something like

{% flatblock "page.info" with default title "Page Information" %}
This is the default content
{% endblock %}

The moment the parser sees the "with default" string it would switch into some kind of default-block mode. If it is then also followed with the string "title" then the new node would also receive a title".

In any case, I'll look into this issue more next week during EuroPython (sorry, but I have absolutely no time before that :-().

[kmike]

The magical auto-creation can be very tasty! E.g. the site have a static html page (or a page with static block of text) and after some time site owner says: "I want to change this text". Developer wraps it in a 'flatblock' tag and that's all. It becomes even easier to make static html site editable for admins. Combined with a link to edit view from the frontend and django-markitup for editing this turns django-flatblocks into a lightweight CMS (btw, title field is not used in this case because titles are handled by the markup in this case).

One more thing to consider is what to do if default text changes and the block is already in DB.

[mandx]

@zerok: Let's see if I make some time to implement that syntax.

@kmike: About default text changes when the block is overriden in DB; well, is logical that the text on DB in any case overrides the template text. Maybe the Flatblock model could include an admin-readonly field that contains the text defined in the template, and gets displayed as text in the admin, as reference to the user.

[zerok]

Sorry for the radio-silence on this one.

If I understand you correctly, the point of this default text would be to replace fixtures with the "fixture" being re-added when someone deletes a the flatblock in the DB, right?

In this case the issue with "what happens once a block exists in the DB" becomes irrelevant IMO since once the block exists in the DB, the default text is no longer relevant.