Development currently happening in the infobox branch.

Very often when making a page, you want to prominently show some structured data, such as address, phone number, hours of operation, etc.  The convention people use now is to create a table to hold this kind of data, right at the top of the page.  We refer to these as "info boxes", and they look like this:

They are difficult to make (although adding them to templates makes them reusable) and the data they hold isn't in a very usable format.  We can do better.

Ideally we would connect the idea of 'tagging' a page with the data in this thing.

Look at django-form-builder approach.

Use the widget type, on submit, to determine how to store the thing.  PageValueText, PageValueDateTime, etc model.  This might work.   We could create our own custom widgets for things like Hours (a series of <select>) and then dispatch to a custom PageValueHours model to save them.

Different types of pages would have different types of forms on them.  We allow the underlying forms to be edited (and editing them won't affect already stored data).  Creating a page from a template could make the page automatically have that template's form.

If we used a page plugin then this would be automatic.  It'd be cool if this was WYSIWYG, though -- that editing the page would show the form embedded in the editor, and filling it out and submitting with the edit would do the Right Thing.  Or we could just render it as we do on the page and allow it to be edited onClick (similar to how we should probably be doing the map)

Could have an "edit form" link on the form itself that'd take you to the form builder.

Think about reverting. If every field is a separate model...???

Mike misc thoughts

Looks cool, here's what I think.  I wrote a lot, kinda just thinking out loud.

Tagging is all good, no worries there.

The structured data thing, we should make the data and form editable outside the CKEditor at first.  This will be easier and also makes lots of sense.  Making it editable from CKEditor will definitely be more difficult to implement and may even be more confusing.  I'd think of it as images (can be embedded using the editor, but can't be edited there, just maybe slightly customized) or as maps (just attached to the page).  Choosing between these is just a matter of looking at use cases, I think (?) and which we choose will dictate a lot of the other choices.

I haven't read up about how these forms would be implemented and don't quite understand it, but I'd sketch it out something like this:

• Form field types are built in and have nice widgets for displaying and editing them.  So we'd have like a phone number field, and a business hours field and whatever.  Possibly let them add their own generic fields.

Then, option 1, if we think of these as images (can be added anywhere in the page, possibly multiple different forms):

• Form types are global to the site.  They live in some namespace, kinda like Templates, and you can go in and edit them.  This will be superconfusing for the average person, just like Templates, and that's ok, it doesn't need to be done that often but should be straightforward for technical people.
• You can add one or more of these to a page, choosing from a list, kinda the same as with images, and then place it somewhere on the page.  Would just need some way to name the forms or something so you can tell which one you're talking about within a page.
• Creating a page from a templates would then copy all the forms attached to the template.
• If we went with this approach we could experiment with making each form type its own, runtime-created Model.

Or, option 2, if these are just attached to the page, then:

• When editing, you just pick which data fields you want a page to have and they all get grouped into an info box thing.
• Templates have preset fields and the choice of those fields gets copied when creating a page from a template.

Just as a gut feeling, option 2 seems like it's easier to understand, more in the spirit of the current patterns set with maps, and would encourage the right behaviors (i.e., creating a page for each "thing" that you want to have these fields).  And it's really similar to tags and maybe there is a good way to combine the two.  As an added benefit, it wouldn't be coupled at all with the fucking editor while being wysiwig nonetheless.

Whiteboard after 2012-7-3 chat

Render w/ schema.org types.