The Request
To enable the structured data of data forms to be combined with the unstructured data of an ordinary wiki page on the same page. (Note: the data form wiki field is not sufficient since it doesn't support includes, divs or other non-text formatting markup.)
The Reason
The ability to “attach” a few data form fields to a regular wiki page could satisfy many feature requests that have not yet been implemented and make Wikidot much more powerful and flexible than it is now. (see example uses at the end)
The Proposal
_template pages for data forms and live templates would continue to work as they do now. But if a _template page has both data form markup and live template markup separated by =-=-=-=-=-=-=-= (or whatever you like), it would be handled as described below.
[[form]]
…
[[/form]]
=-=-=-=-=-=-=-=
[!-- live template area for unstructured content --]
%%content%%
In edit mode
- If the data form markup is above the =-=-=-=-=-=-=-=, the data form fields will be displayed below the title box and above the normal wiki editor's tool bar buttons.
- If the data form markup is below the =-=-=-=-=-=-=-=, the data form fields will appear below the normal wiki editor.
In normal/presentation mode
- The data form fields are completely hidden. Only the normal, unstructured wiki content will be displayed.
- Values from the structured, data form portion could be inserted in the unstructured wiki content using special variables, perhaps using something like: %$fieldname$%.
This would allow users to format the presentation of their data in a much more familiar and flexible way. It would also enable admins to easily retrofit existing wiki pages to take advantage of data forms while still displaying their existing content.
For example, in the screen shot below, the author box which is mixed into the unstructured content could be filled with the data attached to the page in the data form section using syntax like:
Author: %$author$% and %$tte-maintainer$%
A quick search of the wishlist shows at least a dozen unfulfilled wishes (several rejected) that could be satisfied by this feature.
Some Example Uses
Attach names of author and maintainer to page
Add fields to store the name of a page's author and maintainer, which aren't necessarily the same as the page's creator. This would enable you to use the listapages module to sort pages by the actual author or maintainer.
Create a "controlled" tagging system
Present a list of tags as a set of data form checkboxes. This is separate from the existing tagging system. It would eliminate the need for each author to manually type in tags which is prone to errors in spelling and to remember all the possible tags a site admin wants them to use. The listpages module could find pages using these data form tags as easily as it can now with the existing tag system. (Even better would be to have a "tag" field for applying a selection to the current tag system.)
Create author selectable list of predefined page includes
Create a select field called “pagename” that contains a list of pages that a page's author can choose from. Then in the unstructured content, live template area, or in a static template you could do something like [[include %$pagename$%]]. This would enable a page author to easily choose a page header, footer or other predetermined content to embed in their page from a list.
Provide selection of different possible views of data at page creation
Create static templates (the template: category) that make use of data form variables to provide a set of different ways to display the data form's data. For example, I've noticed many Wikidot users are into what appear to be role playing games where they store character sheets on the wiki. You could have different static templates with appropriate artwork and backgrounds for Orcs, Elves, or whatever other imaginary creatures the game has and choose the one that matches the character type when you create the character and enter their specs.
I could keep coming up with uses for this, but I'll stop now and leave the rest to your imagination.
For the usage of 2 page contents ( structured dataform and unstructured page content):
why do you not use a module ListPages with the selection of ONE page ( the dataform fields) of the dataform-template on the unstructured (differrent ccategory) page ( perhaps with the corresponding page-name ) ?
( I know, this does not help in all the question..)
If I have not thought deep enough in all the following ideas of your propopsal — please excuse me..
Edit: to make it clear - I would combine unstructured page content with dtaform structured page content on the "outer" page - not with dataforn template.
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
Helmut,
The key is that the content of both the structured and unstructured data must be on the same page otherwise this won't work at all. The structured content describes or in some way identifies the unstructured content to make it sortable in ways that cannot be done now, at least not without a lot of manual effort. For example, if I wanted to associate the name of a page's author with the page, I could create an entire data form category that contained just author names and links to pages, but that would be a lot of extra work for the people creating the content on my site to copy the URL of their page, create a new page in this author's category and paste the link in the new page and enter their name. It would be much easier if there were a text box or select box where they could enter their name right on the page they are writing so that their name will be directly associated with the page containing their content.
This way I could use ListPages to sort pages by author (not by page creator) or any other criteria I define in the data form portion of the page.
This is just one example of how it could be used. The flexibility of this system would unleash a whole series of applications that are not currently possible.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
I'm not entirely clear as to exactly what you are trying to do, but is it similar to this example?
Timothy Foster - @tfAuroratide
Auroratide.com - Go here if you're nerdy like me
That is almost exactly what I'm trying to do. However, when I tried something like this, includes didn't work in a wiki field. They didn't get parsed at all. I was told in the forums that the wiki field doesn't support includes which are used extensively by my site as a way of extending the wikidot markup. Apparently includes do work according to your page, so I shouldn't give up on data forms just yet.
However, beyond that there are major differences in my proposal. If data forms and unstructured content could be combined:
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
Thanks for your example, Timothy. This certainly illustrates some things that aren't clear from the data form documentation. I've really struggled with data forms since the documentation is incomplete or scattered around in separate areas of Wikidot. This gives me hope that I can do what I want even if it will be fairly labor intensive to get there.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
This is a very creative solution given the current implementation of data forms. However, it seems like it is creating an extra burden on the servers since it uses ListPages to get and display the current page's content. I would think that my proposal would ultimately be more efficient since it only requires the markup parser to pick up what is on the current page and place the data, also on the current page, in the appropriate places when the page is compiled/rendered. Of course I could be wrong since I don't know exactly how either ListPages or the parser/compiler are implemented.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
Timothy, I've played around with your solution a bit, and it almost works for me. Where it fails is that I need to be able to include wiki fields from one data form inside the wiki field of another data form, just as I would include one regular page's content inside another page's content. That doesn't appear to be possible when the included page is itself a data form. Using a regular include just lists all the content of the data form listed by field. Using ListPages inside the wiki field doesn't work since ListPages can't be used recursively.
As it turns out, my proposed solution probably wouldn't be any better since includes in effect copy the content of one page to the other and then render it. So any references to the first page's variables would no longer be valid on the second page where the content was included. What would be needed is something that behaves more like an iframe where the included content is rendered independently of or before being included on the host page.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
You can include a dataform page with a ListPages module:
However, this will not work in the example I gave you because it relies on a ListPages module for self-reference. Modules cannot go inside each other, so it would fail.
You can amend that, however, by not having the self-referential ListPages module on the live template page and instead use it in the content fields of each page where it is needed.
Timothy Foster - @tfAuroratide
Auroratide.com - Go here if you're nerdy like me
Thanks for the suggestion, but I'm not sure that gets me to where I need to be.
Both the source page and the host page where the ListPages would reside in the content field must be viewable as if they were ordinary wiki pages.
If I eliminate the ListPages from the template, the source page can only be displayed as a list of fields.
I appreciate the discussion. I've learned a lot about data forms that will be useful for some other things I'm working on, but I don't think I can use them for this particular part of my project. They come tantalizingly close to meeting my needs, but fall just a little short. All I really want is to be able to attach a few data fields to what is otherwise a completely normal wiki page. In many respects, what I need is a much more flexible and robust tagging system than we have now.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
A little more explanation on my rationale for this…
Data forms are a very cool and powerful addition to Wikidot. As a former data base developer, I really appreciate what they can do, in spite of some of their limitations.
The biggest problem I have with them is that they are too disconnected from the rest of Wikidot - too separated from existing unstructured content. As they are implemented right now, they are their own thing, not really part of the existing wiki environment. You need to use them from the beginning or not use them at all. Most people don't even learn about them until they've already setup their wiki in a more traditional way. They are very difficult for many users to grasp and use precisely because they are handled so differently from regular wiki content. If they were fully integrated with the more familiar unstructured content, I think you would find many more people taking advantage of the power they offer.
For me personally, I have a wiki with nearly 2000 pages of content. I would really love to have each page tied to an author - not the page's creator. As it stands right now, assuming includes do work, I would have to recreate my wiki from scratch to use data forms including creating some new CSS to get those pages to display the way they do now. Copy the unstructured content into wiki fields, and add the author information. It would be far easier if I could modify the live template I use throughout my site to add some structured content to the existing unstructured content. Then all I need to do is have each author add their name to the pages they created. Then I could finally sort pages by author, which is impossible to do now.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
No it's not. If you have a text fieldtype called author you can sort by the author in the ListPages module using order="_author" or order="_author desc" (make sure you use the underscore) .
You've not said what is missing from the documentation but sorting by data form field is certainly there.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
I can sort by author IF I'm using a data form. I meant that with a regular wiki page it is not possible. That's why I'd like to be able to combine data forms and regular wiki content in a more flexible way.
Keep in mind, with a regular wiki page the author isn't necessarily the page's creator. The wiki engine has no idea who the author of the content is without looking at the history, which list pages can't really do.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
I finally found %%form_raw{name}%% on the ListPages documentation page. It's description isn't very helpful for this application, "For select fields, the internal value saved in the page form data, if any". Nowhere does it mention being useful for wiki fields (it suggests it is only for select fields) unless you happen to see a comment in a code box that demonstrates "Ordering Pages" half way back to the top of the page:
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help
form_raw is also discussed in some detail in relation to images at http://www.wikidot.com/doc-data-forms:images although I don't think you are intending to use it with images.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
The reason for that is that they are built on YAML which is different to the rest of Wikidot. This might limit the ability of the developers to do what you want.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
I don't doubt that it might take a little extra work to parse two different languages on a page, but if they are separated it would be relatively trivial to call one parser then the other. For example, my request could be simplified to have the data form content always be at the bottom. Then, the page parser could go through the page like it does normally. When it hits the separator it switches to the YAML parser to pick up the data form portion. I've done things like this myself, so I know it's possible. Web browsers do this all the time when they switch from HTML to XML (used by SVG images). Now, there may be other complicating factors I'm not aware of here, so I would understand if something else made it non-trivial.
It's times like these that I really wish WikiDot were still open source.
I really appreciate the discussion with you and Timothy. I've learned a few things about data forms I didn't know before that will prove useful even if I don't get to use them for what I'm working on now.
Rob Ostapiuk, Principal Technical Training Engineer, Microchip Technology Inc.
Microchip Developer Help