Let's take an example you probably recognize: input of data for a new article on your CMS. You have fields for the title, the content, and an expiration date, and the title is mandatory, so the user *must* write something.
To do this you must go through the following steps:
1. Read the posted values one by one.
2. Verify that the title contains text (validation).
3. Verify that the date is really a date (validation).
4. Generate an error message if validation fails (error handling).
5. Regenerate the input form, but this time include the previous user input (state management)
6. Possibly convert the date to a format readable by the database (database access).
7. Transfer posted values to database.
All of these things must be done for each web form you create. This is very tedious and error prone work, which is why pnForms was introduced to PostNuke: pnForms address all of the 1-6 issues above, and with the use of PostNuke's DBUtil API you can start creating web applications with much much less programming than ever before in PostNuke.
Features
(excerpt from
wiki docs):
First of all - pnForms is a clean extension to pnRender! You can do all the stuff you are used to, but you can also make life easier with the extensions.
pnForms is event driven - you supply an object (the page event handler) to the pnForms framework which will in turn call different methods on this object when interesting things happen, like for instance the click on a button.
pnForms builds on Smarty's plugin system and allows you to extend the framework with new plugins (like for instance a GPS input field for your next project). Plugins are heavy on object oriented programming which means you can reuse and extend existing plugins by simple OO-inheritance.
Plugins are also event driven like the page event handler, so your plugin will get notified when certain reactions are required such as rendering the plugin or reading data posted from the web form.
pnForms manages state for you - all variables in your page handler object is persisted accross different calls to the browser. So if you save an article ID in the event object during the first page rendering, well, then it's still available after the next postback of data from the form.
pnForms handles input validation - you just insert a plugin in your template and pnForms takes care of the rest. You will just have to ask the render whether the page is valid or not.
pnForms simplifies database driven data: you supply the database field name to the plugins (defaults to their ID), assigns data to the render's template variables, and then pnForms take care of the rest. If you also use PostNuke's database utilities (DBUtill) then there's very little work left to do for you.
Please read the rest of the
article for a complete example.
Current state
All of the above is working now and mostly documented in both code and in the Wiki. So grab the current SVN snapshot of PostNuke .8 and start playing around with pnForms. Look
in the Wiki docs for an introduction and pointers to complete code examples.
If you want to try out the user side then look at
turmappen.dk which is 100% PostNuke .8 and pnForms based. You can also look into Frank's
Multihook module (SVN version only) for ideas - it should already be converted to pnForms (so I was told at least).
If you have questions then please post them in the forums, but since I don't read these regularily I suggest you send a short notice to me at jw-at-fjeldgruppen-dot-dk.
Happy hacking to all of you guys and girls :-)
/Jørn (www.elfisk.dk)