I generated an extension and created a simple page called
“simple_page.rb” :
class SimplePage < Page
def virtual?
true
end
def cache?
false
end
def render
lazy_initialize_parser_and_context
if layout
parse_object(layout)
else
render_page_part(:body)
end
end
end
And in the _extension.rb file I added SimplePage to
the activate method:
def activate
# admin.tabs.add “Mc Coy”, “/admin/mc_coy”, :after =>
“Layouts”, :visibility => [:all]
SimplePage
end
When I set they page type on a page to “Simple” and try to access the
page, I get a 404.
Examining the log and injecting logger statements it seems that the
find_by_url method on the page is unable to locate the slug of the
virtual page:
SELECT * FROM pages WHERE (pages.parent_id = 1) AND (pages.“slug” =
‘simple’) LIMIT 1
Returns a row when executed from a postgresql console session but
fails to return a row when executing inside of Radiant.
I can also make the page a env dump page, for example, and don’t get
a 404 error. When I turn the page back into a “Simple” page, I go
back to 404-ville.
Any thoughts? Am I not understanding how the virtual page dealy
works? Any input would be much appreciated.
i was playing with virtual pages yesterday and couldn’t quite figure
out their usage either. i had a very similar situation, but time was
critical so i setup a page type that looked for post parameters and
in the URL.
im interested in any responses involving Virtual pages.
Mucho thanks-os.
For any other interested parties:
This is a simple non-caching page, but it is not virtual (where you
could do interesting stuff inside the render method):
class SimplePage < Page
def cache?
false
end
def render
lazy_initialize_parser_and_context
if layout
parse_object(layout)
else
render_page_part(:body)
end
end
end
This is the smallest example of a non-caching virtual page, where you
can do interesting stuff inside the find_by_url and I’m assuming
render (please let me know if I’m wrong about that.)
class BonzePage < Page
def virtual?
true
end
def cache?
false
end
tag “complain” do | tag |
"Jim, I’m a doctor, not a " + @request.parameters[:url].to_s
end
def find_by_url(url, live = true, clean = false)
url = clean_url(url) if clean
return self
end
end
Paul H. wrote:
When I set they page type on a page to “Simple” and try to access the
page, I get a 404.
Examining the log and injecting logger statements it seems that the
find_by_url method on the page is unable to locate the slug of the
virtual page:
SELECT * FROM pages WHERE (pages.parent_id = 1) AND (pages.“slug” =
‘simple’) LIMIT 1
Returns a row when executed from a postgresql console session but
fails to return a row when executing inside of Radiant.
That’s because of this code:
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/models/page.rb#L128
By default, the find_by_url method is setup to not find virtual pages.
Most of the time, in order to use a virtual page you need anotheranother
page type that overrides the find_by_url method. This is exactly what
the archive page does:
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/models/archive_page.rb#L18
with the archive index pages:
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/models/archive_day_index_page.rb#L14
http://dev.radiantcms.org/radiant/browser/trunk/radiant/lib/archive_index_tags_and_methods.rb#L43
I can also make the page a env dump page, for example, and don’t get
a 404 error. When I turn the page back into a “Simple” page, I go
back to 404-ville.
Right. That’s because the env dump page is not a virtual page. Virtual
pages don’t show up in standard queries.
What exactly is a virtual page? That’s a hard question. The simple
answer is it is a page does not have its own URL. The File Not Found
page is an excellent example. You wouldn’t want the File Not Found page
to show up in search results or a list of a page’s children. Because of
this it is marked “virtual”. Queries for displaying pages should, for
the most part, exclude virtual pages.
–
John L.
http://wiseheartdesign.com