[Radiant] Mailer behaviour failing but not getting any feedback

2006-10-11 Thread Nathan Donaldson 
Hi all,

I have the mailer behavior installed, but it is not working. Anyone have 
any idea what I am doing wrong?

I have the following parts in my page:

*Body*









*config*
mailers:
  contact:
subject: From SonarHQ
from: [EMAIL PROTECTED]
redirect_to: /contact/thank-you
recipients:
  - [EMAIL PROTECTED]

*email*
Name: 
Email:  
Comments:  

I have added the following to environment.rb:
ActionMailer::Base.server_settings = {
  :address=> "mail.sonarhq.com",
  :port   => 25,
  :domain => "sonarhq.com"
}

and have stopped actionmailer from being excluded in this file

In my logs I get the following when I submit:

Processing SiteController#show_page (for x.x.x.x at 2006-10-12 15:20:51) 
[POST]
  Parameters: {"mailer"=>{"name"=>"test", "comments"=>"test", 
"email"=>"test"}, "action"=>"show_page", "url"=>["contact"], 
"mailer_name"=>"test_form", "controller"=>"site"}
Completed in 0.03576 (27 reqs/sec) | DB: 0.00648 (18%) | 200 OK 
[http://dev.sonarhq.com/contact/]

-- 
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Re: [Radiant] Mailer behavior...anybody have any more tips to get it working?

2006-10-11 Thread jsmorris 
I did set up ActionMailer in the config/environment.rb file, but not
in the environments/production.rb file.

My understanding was that the config/environment.rb was for settings
in all environments and if you wanted different configuration per
environment, then you used the specific file
envrionment/production.rb.

Am I wrong in this assumption?  But, I will move the ActionMailer
config to that file and see if I get a different result and post back
to the list.

Thanks for the help.


On 10/10/06, Giovanni Intini <[EMAIL PROTECTED]> wrote:
> Did you setup ActionMailer in
> config/environments/production.rb?
>
> 2006/10/11, jsmorris <[EMAIL PROTECTED]>:
> >
> > I have scoured the list and it seems that several people are having
> > issues with the mailer behavior and I am one of them.
> >
> > I have tried all the suggestions that I found in the mailing list, but
> > still it doesn't work.
> >
> > I have edited my environment.rb file to remove the ActionMailer from
> > being excluded on startup.  I have add
> > ActionMailer::Base.server_settings needed for my hosting provider
> > (RailsPlayground).  I have configured my page, config and email parts.
> >
> > My form displays correctly, I click send, I don't see any errors on
> > screen or in the production log file but the email never shows up.
> >
> > Is there any more troubleshooting that I can do to make sure my
> > configuration is correct?  I guess the next step is to debug the
> > behavior, but since I am still a nuby, I find it difficult.  I was
> > hoping one of the smart people on this list would have an answer.
> >
> > Any help or guidance would be appreciated.
> > ___
> > Radiant mailing list
> > Post:   Radiant@lists.radiantcms.org
> > Search: http://radiantcms.org/mailing-list/search/
> > Site:
> http://lists.radiantcms.org/mailman/listinfo/radiant
> >
>
>
> ___
> Radiant mailing list
> Post:   Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:
> http://lists.radiantcms.org/mailman/listinfo/radiant
>
>
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Re: [Radiant] Core Page Render Methods

2006-10-11 Thread Alexander Horn 
> Ideally, I'd like to see a flexible caching mechanism that doesn't cache
> POST results, or alternatively, a different method (in the Ruby sense) for
> handling POST requests vs. GET requests.

If you have time, check out the "corex" developer branch (
http://dev.radiantcms.org/radiant/browser/branches/corex ). Please let
me know what you think of the new caching mechanism. Note that for
r133 or higher, you need to alter your behavior to adjust it to the
new API. Behaviors are now page class extensions. Please contact me
with any questions.

The new API allows you to ...
  1) Inherit tags from the parent class (i.e. subclass form
StandardPage and get all the standard tags).
  2) Get rid off the nested tags (now you only have define_tag()
statements in your class definition).
  3) Access private methods in your page model.

* Example usage for new API:
  
http://dev.radiantcms.org/radiant/browser/branches/corex/radiant/app/models/file_not_found_page.rb
http://dev.radiantcms.org/radiant/browser/branches/corex/radiant/app/models/standard_page.rb

> The double-redirect is kind of a hack/kludge that circumvents page caching
> -- Radiant was caching the redirect, which resulted in an endless redirect
> loop.

Would you find it helpful if you could extend (subclass) the
site_controller and have the render*, parse* and process() methods
available in the controller? I would like feedback from anyone who has
developed a Third Party product. You guys have a better idea what
functionality you need.


Thanks,
-- 
Alexander Horn
http://www2.truman.edu/~ah428



On 10/11/06, Sean Cribbs <[EMAIL PROTECTED]> wrote:
> Commentable redefines process(request, response).  The purpose of this is to
> capture POST requests for creating comments.  It also redirects back (doubly
> in some cases) after completing the POST operation.
>
> The double-redirect is kind of a hack/kludge that circumvents page caching
> -- Radiant was caching the redirect, which resulted in an endless redirect
> loop.  Essentially, if the Commentable page received a POST, it processes
> then redirects to the Comments/CommentBucket child page which clears the
> cache item for its parent/Commentable page and redirects back to it. Now,
> you could say that I should just make the Commentable page uncached and
> avoid this brouhaha, but I wanted the opportunity for greater performance,
> and the number of page requests/time unit will always be an order of
> magnitude greater than the number of posted comments/time unit unless you're
> getting D.O.S.'d or spammed.
>
> Ideally, I'd like to see a flexible caching mechanism that doesn't cache
> POST results, or alternatively, a different method (in the Ruby sense) for
> handling POST requests vs. GET requests.  Of course, in the future,
> Commentable will use real models and not page hacks!
>
> Sean Cribbs
> seancribbs.com
>
>
> On 10/11/06, Alexander Horn <[EMAIL PROTECTED] > wrote:
> >
> > Currently behaviors have access to render*() and parse*() methods:
> >
> > Behavior::Base render/parse methods:
> >
> > * process(request, response)
> > * render()
> > * render_part(part_name)
> > * render_snippet(snippet)
> > * render_text(text)
> > * parse(text)
> > * parse_object(object)
> >
> > Question:
> >
> > Are you relying on these methods listed above in your behavior?
> > In other words, do you redefine these methods inside your behavior class?
> >
> > 1.2) If yes, which methods are you overwriting?
> >  1.1) What functionality do you intend to provide when altering
> > these methods?
> >
> > Your response directs our efforts to redesign the page class. Thanks,
> >
> > --
> > Alexander Horn
> > http://www2.truman.edu/~ah428
> > ___
> > Radiant mailing list
> > Post:   Radiant@lists.radiantcms.org
> > Search: http://radiantcms.org/mailing-list/search/
> > Site:
> http://lists.radiantcms.org/mailman/listinfo/radiant
> >
>
>
> ___
> Radiant mailing list
> Post:   Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:
> http://lists.radiantcms.org/mailman/listinfo/radiant
>
>
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Re: [Radiant] help with the docs?

2006-10-11 Thread Dave Crossland 
On 11/10/06, Allen <[EMAIL PROTECTED]> wrote:
> I offered to help with the documentation a couple of days ago on
> radiant-docs and didn't get a reply, maybe because no one looks at that
> list. Anyhow, I'd still like to help with the docs.

Awesome!

John asked me to take an official role for documentation a couple of
weeks ago, as I've been putting stuff from the list into the wiki.

I've been busy working this month, but next month is quieter and I
hope to be productive then; the handbook is the first thing I want to
look at.

Sorry I missed the posts to the docs list,

-- 
Regards,
Dave
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Radiant] help with the docs?

2006-10-11 Thread Allen 
I offered to help with the documentation a couple of days ago on 
radiant-docs and didn't get a reply, maybe because no one looks at that 
list. Anyhow, I'd still like to help with the docs.

Allen
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Re: [Radiant] WYSIWY Get plugin

2006-10-11 Thread Tom Styles 
Todd Baur wrote:
> Sorry, I have to disagree with you completely. The non-technical
> person is non-technical because they choose not to or their cognitive
> patterns align them to excel in other ways. 

Just wanted to back that up with a tale from the front line.
I have recently built a news system for our Intranet using rails. Being
a bit of a convert to the textile way of things I initally shunned the
idea of implementing a wysiwyg interface. But after a week of so of
support calls from across the office asking how to put bullet's in etc.
I gave in a implemented widgEditor by Cameron Adams -
http://www.themaninblue.com/experiment/widgEditor/

It's very simple to start with and we've made it even more so by
removing the italic and image buttons from it too. We also removed some
of the options in the "Blocktype" drop down so the only options are now,
Paragraph, Heading, and Sub-Heading. Our users wouldn't understand what
an h3 was anyway.

The cheers of glee that errupted when we showed off the new interface
were an strong show of feeling in favour of wysiwyg. So even though
I'm going to be using alot more textile on my own sites, I'm going to
stick with trimmed down wysiwyg for customer's sites.

Cheers
Tom

-- 
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Re: [Radiant] Core Page Render Methods

2006-10-11 Thread Sean Cribbs 
Commentable redefines process(request, response).  The purpose of this is to capture POST requests for creating comments.  It also redirects back (doubly in some cases) after completing the POST operation.The double-redirect is kind of a hack/kludge that circumvents page caching -- Radiant was caching the redirect, which resulted in an endless redirect loop.  Essentially, if the Commentable page received a POST, it processes then redirects to the Comments/CommentBucket child page which clears the cache item for its parent/Commentable page and redirects back to it. Now, you could say that I should just make the Commentable page uncached and avoid this brouhaha, but I wanted the opportunity for greater performance, and the number of page requests/time unit will always be an order of magnitude greater than the number of posted comments/time unit unless you're getting 
D.O.S.'d or spammed.Ideally, I'd like to see a flexible caching mechanism that doesn't cache POST results, or alternatively, a different method (in the Ruby sense) for handling POST requests vs. GET requests.  Of course, in the future, Commentable will use real models and not page hacks!
Sean Cribbsseancribbs.comOn 10/11/06, Alexander Horn <[EMAIL PROTECTED]
> wrote:Currently behaviors have access to render*() and parse*() methods:
Behavior::Base render/parse methods:* process(request, response)* render()* render_part(part_name)* render_snippet(snippet)* render_text(text)* parse(text)* parse_object(object)
Question:Are you relying on these methods listed above in your behavior?In other words, do you redefine these methods inside your behavior class?1.2) If yes, which methods are you overwriting?
1.1) What functionality do you intend to provide when alteringthese methods?Your response directs our efforts to redesign the page class. Thanks,--Alexander Horn
http://www2.truman.edu/~ah428___Radiant mailing listPost:   Radiant@lists.radiantcms.orgSearch: 
http://radiantcms.org/mailing-list/search/Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Radiant] Core Page Render Methods

2006-10-11 Thread Alexander Horn 
Currently behaviors have access to render*() and parse*() methods:

Behavior::Base render/parse methods:

* process(request, response)
* render()
* render_part(part_name)
* render_snippet(snippet)
* render_text(text)
* parse(text)
* parse_object(object)

Question:

Are you relying on these methods listed above in your behavior?
In other words, do you redefine these methods inside your behavior class?

1.2) If yes, which methods are you overwriting?
1.1) What functionality do you intend to provide when altering
these methods?

Your response directs our efforts to redesign the page class. Thanks,

-- 
Alexander Horn
http://www2.truman.edu/~ah428
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant