Informal

Informal is intended as a combination of a Wiki notation filter and a free-form DB.

(After years on DokuWiki, I cannot live without Wiki notation and the existing filters do not satisfy me, sorry!)

Basics:

• Wiki notation, being a hybrid between DokuWiki, MediaWiki and Redmine's Wiki
• Wiki behaviour, i.e. define a link, click on it to create a new node (of the same node-type), being aware of permissions e.g.
• Free-form database (FFDB): markup fields simply in the text, having these indexed and formatted
• Define templates to be copied into the body field on a click or even on a function key (ajax?).
• Definition of specific index tables for certain fields (later extension)

Not all is fully designed, yet.

For those not being aware of a free-form DB: just mark elements of the body as "fields" with fieldnames and the save will extract the fields. Apart from formatting them specifically, they will be stored in a search table.

There will surely be a filter definition to query the FFDB as well as a page to query it online. That simple search facility will translate the queries into SQL selects and show the results. Integration to views is to be checked!

(Coming soon: examples, use cases, notation documentation, etc.)

PS: right this moment the module is growing on my PC, first checkin will happen when initial functionality is basically there.

Q & A

Why not using flexifilter?

Flexifilter is nice for more compact filters, like "I want to autoreplace certain strings with something.". I once tried for a proof of concept to code a Drupal wiki filter with flexifilter. I failed bitterly. After just a few more patterns I lost overview, because Flexifilter e.g. does not provide means to document the filter you create. I raised an issue, but even with such feature it is hard to overview a flexifilter. Second problem: regular expressions are nice but the proper descending or stateful parser is more powerful (I still have to come to the point having one ... admitted!). Third: Wiki is not just notation it is also behaviour. Having to combine half a dozen modules to get something "like" a wiki is not what I am looking for. I want a fire-and-forget solution!

Isn't the FFDB competing CCK or fields?

No! By no means! Well ... actually some people may find that their use-case fits better with FFDB than CCK/fields, but there are massive differences: CCK is structure on admin-/editor-level, i.e. people who may define content-types. FFDB allows structuring on user level. So CCK/fields apply where structure is given and/or shall not be deviated from. FFDB applies where users actually continuously develop the structure or even need to deal with changing situations and requirements. I could imagine using both, combined, CCK/fields for known and mandatory structure, FFDB for individual attributes.

FFDB?

In 1980+some years I found an application called Asksam. Text based for the PC. It was such a free-form-DB. It was amazingly simple and straightforward to manage data with it. Asksam still exists in today's world: Windows-based, GUI, etc.. After 30years there is no patent to fear: Informal-FFDB is inspired by that 30years old Asksam because I believe this ease of handling things somehow got lost in the evolution of IT. Saying this, I must admit I never had a look into a today's Asksam, I am more of an online-person! Also just the concept is used: mark DB fields inline, for technical reasons I had to find a completely different syntax to avoid collision with other Drupal mechanisms.