# Core Page Render Methods

**URL:** <https://www.ruby-forum.com/t/core-page-render-methods/71812>\
**Category:** Radiant CMS\
**Created:** [October 11, 2006, 5:32pm UTC](https://www.ruby-forum.com/t/core-page-render-methods/71812 "2006-10-11T17:32:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![alexh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/6f9a4e/32.png) [@alexh](https://www.ruby-forum.com/u/alexh)\
**Post date:** [October 11, 2006, 5:32pm UTC](https://www.ruby-forum.com/t/core-page-render-methods/71812/1 "2006-10-11T17:32:22Z")

</div>

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 H.  
[http://www2.truman.edu/~ah428](http://www2.truman.edu/~ah428)

---

<div class="post-metadata">

**Author:** ![alexh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/6f9a4e/32.png) [@alexh](https://www.ruby-forum.com/u/alexh)\
**Post date:** [October 11, 2006, 6:12pm UTC](https://www.ruby-forum.com/t/core-page-render-methods/71812/2 "2006-10-11T18:12:34Z")

</div>

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 C.  
[seancribbs.com](http://seancribbs.com)

---

<div class="post-metadata">

**Author:** ![alexh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/6f9a4e/32.png) [@alexh](https://www.ruby-forum.com/u/alexh)\
**Post date:** [October 11, 2006, 9:50pm UTC](https://www.ruby-forum.com/t/core-page-render-methods/71812/3 "2006-10-11T21:50:02Z")

</div>

> 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](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/file_not_found_page.rb)  
[http://dev.radiantcms.org/radiant/browser/branches/corex/radiant/app/models/standard\_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 H.  
[http://www2.truman.edu/~ah428](http://www2.truman.edu/~ah428)