Core Page Render Methods

Ruby Apps Radiant CMS
1

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

2

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

3

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.

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