Re: [Radiant] Copying a page
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 ___ 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] Copying a page
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 http://www.day-to-day-stuff.blogspot.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] Copying a page
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: 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 Long http://wiseheartdesign.com ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates (http://voice.yahoo.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] Our first site in Radiant, finally
Hi Loren,congratulations that you finished your site, while i am still working on my first radiant powered site :-) And it looks nice, too.Just in case you did't notice it yet, some links provided in the navigation bar above the header point to non existing parts of your site. Bye,Tino2006/11/1, Loren Johnson [EMAIL PROTECTED]: Our first site in Radiant is up and runningOur first site in Radiant is up and running. We've got lots of work still to do, but we're happy with the manageability of things in Radiant even after a chaotic and compressed release schedule: http://www.diopa.orgThe CMS we used before this for this site was ModX (php) which had a few very good things going for it: 1) feature rich and, 2) dead simple to implement exactly the visual design we wanted, 3) mature. However where it lacked and what ultimately pushed us over to Radiant, despite it's relative lack of features: 1) More enjoyable / simpler to use, 2) Ruby, 3) Rails.We hope to be building applications in Rails all next year and didn't want to be dragged down by a PHP legacy app. Available Behaviors UtilizedMailer Behavior,Search Behavior,RSS Feed Behavior,Redirect Behavior (just a code snippet grabbed from Sean here off the list) MUCH GRATITUDE TO EVERYONE WHO SET OFFERED THESE BEHAVIORS TO THE OPEN. We couldn't have gotten the site done in Radiant without at least this much of a jump start. Custom Behaviors / Global Tags CreatedCustom global tagsIn the course of getting what we needed out of Radiant for this release I hack-in the following custom tags They're all a little obscure and nothing genius going on so I won't bother explaining them -- if someone is interested in any more detail just ask: r:find_level level=r:section_namer:if_request_uri r:navigation_level level= iCal fed Calendar DisplayI also created a custom behavior called calendar including a set of tags and virtual pages for displaying a grouping of calendars fed from Google Calendar feeds. The Event and Calendar models are created and administered in another Rails app and database. If you go to: http://www.diopa.org/calendar/master/all you'll see it in action.This behavior needs to be revisited and implemented using page_virtual and such (for now I override find_page_by_url and manually parse the path to get parameters...), but hopefully I'll get a chance to clean it up into something self contained and worth sharing. Modsof anything outside the Vendor, Log and Public directoriesBeing the first attempt to seriously use Radiant much of my energy in this project was diverted to finding ways to stay out of the app directory. I want us to stay on track with Radiant as new releases are formulated. The only change I had to make was in /app/views/page/new.rhtmlwhere I added a row in the more...and included the published_at date such that it could be modified to reflect the correct date on content converted from the previous site.Wish List1. A new plugin system / page types (same thing, right?). How much I'd love to be able to be free to build madly and freely on top of Radiant without feeling like I was branching or going to need to create an auxiliary Rails app. 2. Page reordering andre-parenting so that I can3.A more sophisticated navigation generation tag or tags which has options for dynamically generating navigation based on the tree which would go hand and hand with arbitrary ordering of pages and probably a new page attribute or status to indicate whether an article should show-up in navigation or not. Thanks to everyone for the bits of help throughout. I hope that through continuing to improve this site we'll have some help and code to offer back to the community. Loren JohnsonFN Group[EMAIL PROTECTED]AIM: NL7XF ___Radiant mailing listPost: 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] Copying a page
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. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Implementing a tag for outputting radiant tags?
So I've put together a couple of plugins for Radiant, which plugins provide some global tags. Now I'd like to write about these tags on my Radiant-powered web site. That is, I'd like to be able to write something like: precoder:blah foo=barr:link//r:blah/code/pre _without_ the r:blah tag being executed and replaced by its output. The r:escape tag doesn't help, since the r:blah tag gets expanded first, then its output is escaped. I was thinking of creating a simple echo tag, like Behavior::Base.define_tags do tag echo do |tag| tag.contents end end but obviously there's no contents property (or body or text or any other variation I could think of). I've looked through radius.rb, and page_context.rb, but don't see a way. If someone could point me in the right direction, I'm happy to do the work. I just don't know where to start . . . - Sean ___ 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] Implementing a tag for outputting radiant tags?
Sean Santry wrote: That is, I'd like to be able to write something like: precoder:blah foo=barr:link//r:blah/code/pre ... If someone could point me in the right direction, I'm happy to do the work. I just don't know where to start . . . Unfortunately I don't know of an easy way to make this happen. I've consider providing an escaping mechanism to Radius so that you could write: \r:tag_name / But I haven't had the time to mess with it. For now I'd suggest that you write your tags with the gt; and lt; entities: lt;r:tag_name /gt; -- John Long http://wiseheartdesign.com ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
