Re: [Radiant] Implementing a tag for outputting radiant tags?

[John W. Long]

Sean Santry wrote:
> That is, I'd like to be able to write something like:
> 
>   
>
> ...
>
> 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:

   \

But I haven't had the time to mess with it. For now I'd suggest that you 
  write your tags with the > and < entities:

   

--
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

[Radiant] Implementing a tag for outputting radiant tags?

[Sean Santry]

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:



_without_ the  tag being executed and replaced by its output.  
The  tag doesn't help, since the  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] Copying a page

[Daniel Sheppard]

> 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

Re: [Radiant] Our first site in Radiant, finally

[Loren Johnson]

Thanks Tino,I did know about the breadcrumb failure up top... That's one of the reasons I'll be re-writing my Calendar behavior to work properly through virtual_pages... I assume you ran into the problem with the calendar URLs.Good luck on your site!On Nov 1, 2006, at 11:43 AM, Tino Breddin wrote: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.  Loren Johnson[EMAIL PROTECTED] ___
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

[Tino Breddin]

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:
 
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.
Mods of 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.rhtml where 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 and re-parenting so that I can 3. 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

[Radiant] Our first site in Radiant, finally

[Loren Johnson]

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: 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.Mods of 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.rhtml where 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 and re-parenting so that I can 3. 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 list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Radiant] Mailer Behavior - File Attachments

[Loren Johnson]

Has Matt or anyone else made any progress on making file attachments work with the Mailer Behavior.I'll hack in an implementation for my purposes if need be, but would much prefer to go off something already thought through. Loren Johnson[EMAIL PROTECTED] ___
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

[Justin Grammens]

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] Copying a page

[Erik van Oosten]

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

[Marty Haught]

> 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

[John W. Long]

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

Re: [Radiant] Copying a page

[Krzysztof Szafranek]

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
http://szafranek.net

-- 
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post:   Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant