Form Submission Processor
Here's my 2 cents on how I think forms should be implemented. I don't know how far they stray from the existing/upcoming system.
I would like to see a Parser called "form" that would simply render a form on the screen. This should make it easy to have whole-page forms or include them within another wiki page. This would also define the block that the form tags would include. The data for the form should be any allowable wiki markup, with the addition of fields, which would be similar to a macro, except it would define the field and any default data.
Example:
{ { {#!form myformname
'''Enter Your Name:''' [[FormTextField("username",40,EvanLanglois)]]
'''Enter Your Problem:''' [[FormEditBox("edittext",60,20,"")]]
[[SubmitButtonClear()]] [[SubmitButton("Submit",ProcessProblemSubmit)]]
} } }The fields could be edit boxes, text boxes, drop-down lists (which should be capable of fetching the list from another page using whatever macros you have that can do such a thing), and submit buttons. Special submit buttons for clearing a form and things like that should be built-in. All others should take a page the user will be sent to when the button is clicked, and all form fields would be passed to that page as variables to be expanded using the @variable@ syntax. This page could then use of the MySQL plugins to add the data to a database, or using some new plugin, could add the data to a specific part of some other named page to be queried by some other part of the system.
For consistency, I'd like to see a new MySQL plugin that would fetch the data into variables instead of just displaying as a table, and then jump to another page for display (which could in-turn be a variable so that the calling page determined the next destination). This could lead to well-defined WorkFlows. For example, some page might set some variables and then use some form of new [[GoTo(PageName)]] macro to jump to a page that fetched data based on those variables, which would in-turn jump to a form which would use those variables as field defaults. When the user clicks submit the field variables are passed to another page which could insert them into the database, etc. As long as these temporary variables are preserved across the [[GoTo(PageName)]] then everything should work.
Is this clear? A few conditional macros and I think this could become really flexible! Also, while primarily handling forms, I think the piece-meal approach of making the components more global and re-usable and seperating the data sources from the data display (a query that fetches data such as from a database or another page should set variables, not display the data) could lend flexibility elsewhere as well.
Comments
All comments and discussion is welcome. If I get any feedback, I'll move this to somewhere more global.
The main problem of "form support" is that currently nobody works on it. And there isn't much there. So what's really needed is a developer caring for it, collecting all ideas, making and discussing a plan, implementing and testing it - and also cares for it in the future. It would be nice if the form support would make it possible doing the forms (see UserPreferences) that moin uses itself in an easier way, but that won't be easy. -- ThomasWaldmann 2005-09-18 09:59:27
You do not need a parser here. But in fact, you can already start working on the macros you designed above
Well, the parser idea was to help make it easier to have seperate forms. If these forms are included from other pages in piece-meal fashion, I wouldn't want fieldnames to collide. However, I suppose this would be an abuse since its still just wiki inside, and it looks like {{{ syntax doesn't nest, so perhaps a [[FormStart(formname)]] would be better? -- EvanLanglois
As for just creating the macros, this would possibly work, however, for things to work cleanly/easily, I think a few things must happen. First, there is an assumption that pages are processed in the following order:
- Expand variables
- Expand Macros
- Output page
Is this the way it works? Any other order would kind of kill the ability of variables to be passed to macros, which is fundamental to the flow working correctly. Also, to have a Macro that produces a redirect without requiring javascript, you can't have any output or html generated before it processes that Macro! I suppose there is also some variable scope assumed here that variables are preserved across the new [[GoTo(PageName)]] and across the submit action, and not much else. For conditionals, since there are no blocks that I know of, one could assume a wiki page or subpage to be the block. That only leaves some form of expression syntax to work out. Is there any form of expression that can be used in variable assignment (like for example a way to express : c = a + b), or is this a static assignment only?
I'm not familiar enough with either the Python langauge or MoinMoin code base to really be the best person to implement this, but I also know that if no one is working on it, it isn't likely to get done unless I jump in and figure it out. -- EvanLanglois
- There are no variables expanded. The page is rendered like you see it. Depending on the dynamicness of your plugin, it is rendered in the caching phase or in the page output phase. But you can read this somewhere else in the wiki.
I meant variable expansion such as -- EvanLanglois and things like that. Its not entirely clear what the difference is between the @USER syntax and the [[GetVal(WikiDict,var1)]] type of syntax. It looks as though -- EvanLanglois expansion is done on page save, with some exceptions, and Macros are done later. Nor is it clear if you can GetVal from some other page than your personal dictionary page. The macro/IncVar looks similar to [[GetVal(WikiDict,var1)]] type of syntax but more flexible, but its not clear if you can do nesting with either one, such as [[GetVal([[GetVal(...,var3)]],var4]] or something crazy like that. Doing a redirect for a GoTo(PageName) would require rendering in the caching phase, before page output I'm thinking. Are there docs available on the internals? Or do I have to start looking at the code?
What exactly do you want to do with GoTo?
Basically, the idea is to be able to have some pages that display data, and some that either contain data or fetch data. I suppose that using Include would be fine, but a form submit would work like a GoTo but with a pagename specified. Also, once you start looking at simple conditionals, a GoTo would simulate branching functionality treating a Wiki page like a block. -- EvanLanglois
- It is still not clear what a goto should do here. What do you mean by pages that fetch data? Please elaborate.
Fetch data, such as from a MySQL database. There is a plugin to do this, but it currently displays a table, and I'd rather have some sort of variable returned, which could be displayed by jumping to a wiki page that expands those variables into whatever display the user wishes. Instead of entering data into a wiki page, it may be easier to insert data into a database from a WikiForm, or with some other program, allowing the wiki to integrate with other intranet applications.
I see two questions here.
- How to write forms?
- What to do with the submitted data?
First problem is easy. There are several solutions, all of them almost equivalent -- a good topic to start a flamewar :-). (macro? parser? extend wiki sytntax?)
Second question is more difficult. The problem is that there is no general solution. Some people want to append the submitted data to a wiki page, some of them want to insert them into a database, send them via e-mail or whatever. I would ignore it for the moment. Just allow to specify an action inside a form and let the wiki administrators write the actions themselves. I am sure there will be many of them in the ActionMarket, people can then pick one and tweak it. -- GejzaJenca