On 22 Sep 2008, at 21:16, [EMAIL PROTECTED] wrote:

On Thu, 2008-09-18 at 15:37 -0400, Tim Gossett wrote:
On Thu, Sep 18, 2008 at 2:10 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED] >wrote:

Is it a bad thing? I was going to include a contact form on every page of a website I am building, but that means that every page must have the
page type "Database Form". Will that mess up any of the other
functionality that might be inherent in the page type "<normal>"?

I was planning on doing the same thing with the mailer extension.... put all the necessary parts on the homepage, and have every other page inherit it. However, it would require that every page be of type Mailer, and apparently
inheriting some of the mailer parts isn't allowed.

Maybe just put the mailer form in an iframe in the sidebar snippet? And
create the mailer page with a blank layout... sound useful?

I hate to bring up an old thread, but would putting an iframe in the
template be considered bad practice by html zealots?

I'll start by admitting that I haven't actually used the database_form extension (which looks excellent, by the way). But I've looked at the code, and recognise certain similarities with my subscriber_lists extension[1], which was based on Andrea's newsletter extension[2].

As I understand it, the DatabaseFormPage differs from regular Radiant pages in that it is able to process an incoming post request. On top of that, it adds a bunch of tags which make it convenient for you to build a form on that page. These tags are only available on pages of type DatabaseFormPage, but that doesn't mean that you *have* to build the form on a page of that type. You could code up a form using regular HTML, and set it to submit to the URL of your DatabaseFormPage. The handcoded HTML form could go in a regular snippet, and be included on every page.

I'll give an example to make it clear:

Say you have a DatabaseFormPage whose url is /contact and contains the following:

<r:database:form name="requestinfo" redirect_to="/contact/thank-you">
  <r:database:text name="name"/><br/>
  <r:database:text name="email"/><br/>
  Primary Interest:<br/>
  <r:database:select name="primary_interest">
    <r:database:option name="work"/>
    <r:database:option name="fun!"/>
  <r:database:submit value="Submit"/>
  <r:database:reset value="Reset"/>

This would render into something like this:

<form method="post" action="/contact" name="requestinfo">
  <input type="text" name="content[name]"/><br/>
  <input type="text" name="content[Email]"/><br/>
  Primary Interest:<br/>
  <select name="content[primary_interest]">
    <option value="work">work</option>
    <option value="fun!">fun!</option>
  <input type="submit"/>
  <input type="reset"/>

[this is no doubt simplified from the actual form, but it serves as an example]

Now copy that HTML code, and put it in a snippet called "contact-form":

<r:unless_url matches="^/contact">
...[copy the HTML form above]...

You can call that snippet on every page, because it doesn't use the radius tags defined by (and available exclusively to) DatabaseFormPage. The <r:unless/> tag ensures that if you are on the contact page itself, the HTML handcoded version is not rendered, but the radius coded version would be.

There is a possible snag to this approach: I am not sure how this will play with the validation. If you were to copy the real rendered HTML form, it should include ids and classes on all form elements, so the prototype validation might still work. Perhaps Nick Plante could chime in on this?

I used this approach on this site:


to make the Mailing List subscription form available on every page. Note that the subscriber_list page type uses server side validation, so if you submit the form with no email address, or an invalid one, the form is re-rendered in the page body with a list of errors. The sidebar version of the form is rendered from a snippet, which uses a pure HTML form. The version of the form which appears in the page body is rendered using the radius tags provided by the SubscriberList page type.

I think that this is a better solution than using an iframe. Let me know how you get on with it.


[1]: http://github.com/nelstrom/radiant-subscriber-lists-extension/tree/master
[2]: https://github.com/pilu/radiant-newsletter/tree
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to