Hi.
This may have been discussed before, but I wasn’t able to find a
reference to it.
I’ve setup a blog (archive) page with several parts: body, extended,
comments, sidebar, ecc. and avery time I create a new blog entry I’d
have to create a new page with the same structure and the same content
for all parts but the body and the extended ones.
What is the best/quickest way to copy a page (and its part structure)
so that I don’t have to re-enter it by hands?
(I recall it may be done via the console but how?)
Many thanks in advance.
M
Hello Maurizio
While this is not a perfect solution, you may edit “default.parts” value
in table “config” in Radiant’s database. Simply change the list of
default page parts. From this moment on every new page will have the set
of parts you defined.
What I’d like to see in Radiant is parts’ inheritance…
–
Krzysztof Szafranek
On Oct 30, 3:33 am, Bodhi [email protected] wrote:
then any new page you create will have those parts by default.
Thank you Bohdi.
A couple of questions:
-
those page parts, which logically could be “inherited” from a sort
of “template” page (which has all the parts and their content as
required), should be the default, but just for a branch of the site
tree, for example for the “/blog” one, and not for the entire site; how
can I do this?
-
except for the body and the extended part, also the content of the
other parts should be copied (or “inherited”); in other words, how can
I copy a page from another (a sister page) including its content?
M
On 29/10/2006, at 8:27 AM, Maurizio B. wrote:
What is the best/quickest way to copy a page (and its part structure)
so that I don’t have to re-enter it by hands?
(I recall it may be done via the console but how?)
Many thanks in advance.
Maurizio, from the console:
g5:/sites/radiant bodhi$ ./script/console
>> Radiant::Config['default.parts']
=> "body, extended"
>> Radiant::Config['default.parts'] = "body, extended, comments,
sidebar"
=> “body, extended, comments, sidebar”
then any new page you create will have those parts by default.
Bodhi
On 30/10/2006, at 4:00 PM, Maurizio B. wrote:
tree, for example for the “/blog” one, and not for the entire site;
how
can I do this?
- except for the body and the extended part, also the content of the
other parts should be copied (or “inherited”); in other words, how can
I copy a page from another (a sister page) including its content?
At the moment, there is no way of copying content from one page to
another (apart from copy-and-paste 
). If you just want to reuse
text from another page you could use the ‘inherit=“true”’ attribute, eg:
<r:content part="part_on_parent_to_inherit" inherit="true" />
But the part needs to be defined on one of the page’s ancestors, and
it’s a reference, not a copy (ie. if you change the part on the
ancestor, it will change on ALL the children).
Bodhi
I’m now 3 days into pulling my hair out trying to get a custom
calendar/events behavior to do what I need it to.
Two questions:
-
I can’t seem to deduce from the code the purpose of page.virtual
(or page_virtual within the behavior context). How is it used? How
might the use of it help me in creating a behavior which generates
it’s own, well, virtual pages a little like the Archive Behavior.
-
I’m overriding find_page_by_url and taking all the paths above the
page with the behavior as parameters to that behavior then outputting
the page again… so my find_page_by_url looks simply like this in
the behavior:
def find_page_by_url(url, live = true, clean = false)
@page
end
Having went around the routes and everything else in this manner I’m
not surprised that my <r:navigation tag no longer indicates a here or
selected on these link even though the url’s are a match… Is there
a way to trick Radiant back into seeing my “virtual pages” as real
pages in the proper context so that, well, I can use <r:navigation,
among things?
- Am I thinking of this all wrong? I’ve studied the search and the
archive behaviors to get this far but I’m going into uncharted area.
What I’m doing currently feels like a bit of a hack but I got here by
trying to take Radiant with me instead of diving straight into the
routes.rb and doing everything (including managing a separate set of
layouts) in another app… Maybe I should have just done that?
Any help is greatly appreciated. I’ve really struggled with this and
have to release it tomorrow. I never did feel like I found just the
right implementation.
However, when I am done I will attempt to clean it up a bit, refactor
as necessary and offer it to anyone here who might have use for an
iCal subscription based event calendar/tags for Radiant.
Thanks,
Loren J.
- those page parts, which logically could be “inherited” from a sort
of “template” page (which has all the parts and their content as
required), should be the default, but just for a branch of the site
tree, for example for the “/blog” one, and not for the entire site;
how
can I do this?
This isn’t currently possible, but page templates would be a great
feature that I may tackle as corex/APS2 evolves.
Either add more info to page_types or habtm page_templates,
specifying “default” layouts for the page. Plus have a
page_part_types-esque popup when someone clicks “add child”, default
inheriting from the parent? Something like that
Would also be great to have Easy Buttons somewhere for “new blog
post” or “new clothing item” that post a preprogrammed page_type/
page_template & parent_id. This is adding a lot of tabs to the top
though!
-jamie
Krzysztof Szafranek wrote:
What I’d like to see in Radiant is parts’ inheritance…
Mmm, that’s an interesting thought. So when you create a new page it
would have blank parts defined for every one of it’s parent’s parts? You
could then delete them or add others, but it would inherit it’s parent’s
parts at creation time?
–
John L.
http://wiseheartdesign.com
Mmm, that’s an interesting thought. So when you create a new page it
would have blank parts defined for every one of it’s parent’s parts? You
could then delete them or add others, but it would inherit it’s parent’s
parts at creation time?
I would think a ‘clone’ page would be more useful. It would
essentially clone a child page by copying all parts and behavior but
no content. the new clone would be a sibling of the page cloned.
Cheers,
Marty
Could this be introduced for new pages? For some behaviors you need to
create multiple parts. Having these present upfront gives one less thing
to explain to the users. The default content could be provided by the
behavior.
Erik.
John W. Long wrote:
Mmm, that’s an interesting thought. So when you create a new page it
would have blank parts defined for every one of it’s parent’s parts? You
could then delete them or add others, but it would inherit it’s parent’s
parts at creation time?
–
Erik van Oosten
Loren,
It sounds like you’re tackling a hard problem. I also had to tackle
some
hard conceptual problems when figuring out how to do the Commentable.
It
will be rewarding, I promise! In doing so, I learned a lot about what
makes
Radiant tick, even though I already understood Rails.
-
Virtual pages are not directly navigable, but fill some
system-specific
function for the site. The Archive Month behavior, is a virtual page
that
generates archive pages on a month basis, but each of those individual
pages
is not a real page, just generated by the behavior. So for your
“events”,
you wouldn’t want individual months or days or weeks to be pages, but a
virtual page that would show the events for each year/month/day/week
dynamically.
-
From the looks of this, yes you want a virtual page. But perhaps you
want the technique that the Archive behavior uses, in that it adjusts
the
children URLs. Or are there no children at all?
-
Every behavior is uncharted behavior until you’ve done it! In
retrospect, I would have done a lot of things with Commentable
differently,
but it works and is quite clever in some respects. It’s commendable
that
you are taking Radiant with you… it’s the harder path.
Sean C.
seancribbs.com
Could this be introduced for new pages? For some behaviors
you need to
create multiple parts. Having these present upfront gives one
less thing
to explain to the users. The default content could be provided by the
behavior.
Erik.
My preferred way to do that would be to let the parent in on the child
creation process - you would create a parent behaviour for, say
‘reviews’, and this parent behaviour would dictate the default parts and
behavior of its children.
This idea is in part because I would like pages to potentially have
their administration page change completely based on their behaviour - I
think the best way to do that would be to choose the behavior before
being presented with the administration page (so click new -> choose
behavior -> edit page). To make this less obstrusive, the parent page
could dictate what the allowed children were - so you don’t put archive
month summarys beneath pages that aren’t archive behaviors, and the
‘reviews’ parent would only allow ‘review’ children (thus skipping the
choose behavior page). Or maybe the child pages say what their parents
can be… either/or - if your review child page has it’s own behavior,
and that behavior is selected before the page object is instantiated,
the parts can be selected by the review child behaviour.
Simple behaviors that do little more than specify their allowed parents
and default parts would be fairly easy to create an admin interface for.
Store those in a table and dynamically create their classes on demand.
Ruby makes that bit brain-dead easy.
But I’ve yet to actually put any of that into an implementation, so I
don’t know whether these ideas are actually good or not… ‘when I have
time’… dammit… too much thinking not enough doing.
Daniel.
I actually was just in a similar situation, but found
that using the sibling’s page parts worked better in
my situation as opposed to the parent’s.
I wanted to have a “slideshow” section of my site and
used the very cool page_page_types that Dror created
to allow uploading of photos. I however wanted all of
the children tabs (page parts) of that section to have
the “attachment” attribute, so when I created a new
page under that section it automatically would be
created with an attachment page part (along with a few
other custom page I wanted parts). It was easy to code
up something in the page_controller.rb to just create
the @page.parts to use the parent of the new page you
were creating. For example:
if request.get?
@page.parent.parts.each do |part|
@page.parts << PagePart.new(:name =>
part.name)
end
end
This might do what some people have asked for. But, I
then thought about it more and realized… Ideally, in
my situation, I don’t want to have the attachments (or
other custom parts) page part types on the slideshow
SECTION page. This didn’t make sense to have to put my
page parts on the parent. I just needed some way to
say only that all of the children of that section
should have a predefined set of page parts. The
thought then was to make it so when a page is created
it would use it’s SIBLING’s page parts. The only way I
could think of to do this was to grab the first child
of the parent that is being created and use the parts
from that. For example, some code like this:
if request.get?
if @page.parent != nil && @page.parent.children[0]
!= nil
@page.parent.children[0].parts.each do |parts|
@page.parts << PagePart.new(:name =>
parts.name, :page_part_type_id=>
parts.page_part_type_id)
end
else
default_parts.each do |name|
@page.parts << PagePart.new(:name => name)
end
end
end
You have to create one page with the types you want,
but then others created in that section will have the
same as the first one defined.
I appologize for the long post. Just wanted to share
my thoughts and see what others thought about this. I
think there is some merit to having some sort of
“inherit” attributes on creating a page so all the
children of that page would have the attributes
defined, but just wanted to point out in some cases
you might not want to have to set the page part on the
parent and instead want to base the new page off it’s
siblings. I’m also looking for maybe a good generic
way to do this since as of right now I have hacked the
core page_controller.rb to get this to work. Plus, as
you can see my code only goes 1 level up, so ideally
if we were to have it use the parent’s, it should
recurse up to the root page.
Keep up the great work on Radiant!
Thanks,
Justin
— “John W. Long” [email protected] wrote:
parts at creation time?
Cheap Talk? Check out Yahoo! Messenger’s low PC-to-Phone call rates
(http://voice.yahoo.com)
John W. Long wrote:
Krzysztof Szafranek wrote:
What I’d like to see in Radiant is parts’ inheritance…
Mmm, that’s an interesting thought. So when you create a new page it
would have blank parts defined for every one of it’s parent’s parts? You
could then delete them or add others, but it would inherit it’s parent’s
parts at creation time?
Yes, that’s exactly what I meant. Inheritance doesn’t clutter current
interface, while simplify the mundane task of setting up each new page.
For me it would also eliminate the need for “cloning” functionality, but
maybe this one could also be useful.
BTW John: thanks for the work you’ve done on Radiant. I really love its
philosophy
and elegant design.
I would think a ‘clone’ page would be more useful. It would
essentially clone a child page by copying all parts and behavior but
no content. the new clone would be a sibling of the page cloned.
I like the “clone” command approach. It is a pragmatic one, probably
relatively easy to implement (but maybe I’m wrong), and easy to
understand for end users. In the case you need a clone of a sibling
page, you just clone the page, and a new sibling is created with a new
title/slug which you could change later (or contextually within the
cloning page–an input box pops up and request you the new title
otherwise a default is used); in the case of children, you create the
first child by hands (or by inheritance when and if available), and
then clone it to create a new page. I’d like to stress it would be very
useful to also have the part content pre-filled by the cloning process
(eventually this could be optional), because in many cases some page
parts could contain a snippet which is in common among all cloned pages
(think of config part in commentable, by way of example). I’d think
providing a clone button shouldn’t be hard.