Forum: Radiant CMS Radiant integration with another Rails app?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Loren J. (Guest)
on 2007-05-28 20:04
(Received via mailing list)
Does anyone have a successful example out there of putting Radiant in
the vendor directory of an existing full-scale Rails app and having
it play nicely?

I've tried unsuccessfully in the past, however with the final polish
on 0.6 (and now 0.61) I'm ready to give it another shot.

I have an app I would like to do this with that I'll be working on in
a week or two.

For my use here are the two main issues that I know of are:

1. Routes... I can load my app's routes first I essentially override
everything but the final Radiant default "page not found" route.

2. Rendering of snippets or page parts with Radius tags in them
straight in to my Rails app view... In particular, I imagine making a
helper in my app for calling the Radiant content. Is there a way to
render the snippet or part directly without creating a new
PageContext every time it goes to render (I'd be doing this all
through a Rails helper method I imagine...)

3. Less important to me, but interesting... the reuse of Layouts. Can
I pull a layout as a Rails layout, ERB render and then do a final
Radius render? Anyone tried this?

Anybody doing any of this yet?

Thanks,

Loren
www.hellovenado.com
Matt Parrish (Guest)
on 2007-05-28 20:14
(Received via mailing list)
Hi Loren,

Nice to talk to you again! ;)

I'm working on the same thing right now.  I currently have a Radiant
extension that allows Radiant to live in /vendor while having a Rails
app at it's current location with only a slight modification required
for config/routes.rb to work properly.

It also has the ability to insert a snippet using a helper as you
suggested, although I don't know how robust it is depending on what
radius tags are in that snippet.  And yes, as you mentioned, it
creates a Page object to do this.

I'm also very interested in allowing Rails pages to leverage Radiant
layouts, and that is the next thing I plan to work on.  Let me know
if you're interested in seeing the extension I have so far.  I plan
on creating a Rubyforge project for it, but I haven't gotten around
to that yet.  Perhaps we can work together to get this done.  I also
think that Sean was working on the layout problem, too.  So maybe he
already has made some progress in that area.

Thanks,
Matt
Loren J. (Guest)
on 2007-05-28 20:26
(Received via mailing list)
Hey Matt,

Funny -- I knew I talked to someone about this at RailsConf and I
just couldn't remember who... Now I remember our discussion well.

Yes, I'd very much like to help out in whatever way I can. I really
want to see this happen and end-up with something that makes the
integration dead simple to accomplish.

Love to see what you've got so far and talk more. It'd be especially
nice to see how you're using it in your existing app. I still have
your card here, I'll give you a shout later today or tomorrow to talk
approaches and see in what way I might be able to pitch-in, etc.

Maybe it'd be nice to set a date and time for you, Sean and myself
(and anyone else interested) to meet-up in #radiantcms IRC on this
topic...

Glad there is something already happening on this front!

Loren
Matt Parrish (Guest)
on 2007-05-28 20:35
(Received via mailing list)
I'm working right now to get a project created on RubyForge and
trying to come up with a reasonable name for the extension.  How does
'RadiantFromRails' sound?

I'm up for getting together with you and Sean on IRC.  I'd really
like to hear Sean's thoughts about how he might approach the issue of
layouts as I haven't really spent any time thinking about the
implementation yet.
Francesco L. (Guest)
on 2007-05-28 21:40
(Received via mailing list)
Hello everybody
I have a site with a node page called news, inside that I have some
subpages and some other nodes with subpages in them.
I am using children:each to show all subpages of news, but I need to see
subpages of other nodes too called for example sction1 and section2. So
I put another cycle children:each inside the first one.
It is ok, but I see the nodes pages too.
I am trying to use unless_url matches="section\d$" to match all pages
that ends with that url to avoid displaying nodes pages, but it doesn't
work. Is there some special way to use regexp inside radiant?
Or maybe exist tag like unless_parent but matching if a page
has_children?
Thanks to everybody

--
Francesco L.
Ymir s.r.l.
Viale Verona 190/11
38100 Trento
Loren J. (Guest)
on 2007-05-30 09:15
(Received via mailing list)
Matt,

RadiantFromRails sounds good to me.

Let me know when you get it set up, I'm anxious to give it a spin.
Once I am sitting down to do that I'll feed my experience back to you
on how it goes.

Do you have a client use case for the integration? I think you said
you did, but it'd be good to know your requirements as it seems that
a completely general purpose integration method could be a stretch...

Feel free to AIM, call or email me if you'd like to bat any part of
the implementation details around with someone.

Loren
Loren J. (Guest)
on 2007-05-30 09:44
(Received via mailing list)
Francesco,

It will help if you can post the code snippet with the nested
<r:children:each ... tags in it to look at. If I am understanding
what you're describing correctly, yes I'd expect it to work as well.

If you're still stuck post that section of code and maybe I can help
more.

Loren
John W. Long (Guest)
on 2007-05-30 19:17
(Received via mailing list)
Matt Parrish wrote:
> I'm working right now to get a project created on RubyForge and
> trying to come up with a reasonable name for the extension.  How does
> 'RadiantFromRails' sound?
>
> I'm up for getting together with you and Sean on IRC.  I'd really
> like to hear Sean's thoughts about how he might approach the issue of
> layouts as I haven't really spent any time thinking about the
> implementation yet.

If you get a plugin going, I'd be happy for it to live in the Radiant
SVN repository.

--
John L.
http://wiseheartdesign.com
Matt Parrish (Guest)
on 2007-05-30 20:55
(Received via mailing list)
John,

Are you suggesting that I develop from the Radiant SVN repository?
Or are you saying that you'd be happy to host a copy of stable releases?

Also, the name I settled on was Radiant on Rails and it is a Radiant
Extension.

Thanks,
Matt
Loren J. (Guest)
on 2007-05-30 21:38
(Received via mailing list)
Did you consider wrapping it up as a plugin? Off the top of my head
that seems like it could be the cleanest way to go, but I say that
without seeing how you have it setup now.

What is a basic sketch of the install process as it is?

Some way to embed in a straight Rails app is in my view a key piece
of the puzzle that is Radiant's future.  I have frequent applications
now that would use Radiant in this embedded way if an easy and
unobtrusive way to do so was already established.

So as for going in the Radiant SVN I think it belongs there and I'm
willing to pitch-in on the development effort if you want/need that.
There are "in development" pieces in there already, so I think it's a
fine place for it. -- But that just "like my opinion, dude".

:)

Loren
Mario T. L. (Guest)
on 2007-05-30 22:01
> I'm also very interested in allowing Rails pages to leverage Radiant
> layouts, and that is the next thing I plan to work on.

I'm very happy to see this project forming.  After tossing around many
ideas for integrating custom Rails views within a Radiant site, I've
formulated a pattern.

I simply create an extension and build the functionality exactly like
I'm building a Rails app.  I modify the routes in the extension
initializer being careful to differentiate between back-end
functionality (for the admin interface) and front-end functionality (for
the sites users).  Admin functionality is put in "admin" subfolders just
as is already done with the Radiant admin stuff.  For example, here are
the routes I currently use for an in-progress extension that has both
front-end and back-end interfaces.

define_routes do |map|

  #back-end interfaces
  map.admin_event 'admin/event/:action/:id', :controller =>
'admin/event'
  map.admin_offering 'admin/offering/:action/:id', :controller =>
'admin/offering'

  #front-end interfaces
  map.offering 'offering/:action/:id', :controller => 'offering'
  map.event 'event/:action/:id', :controller => 'event'
  map.registration 'registration/:action/:id', :controller =>
'registration'
  map.invitation 'invitation/:action/:id', :controller => 'invitation'
  map.evite 'evite/:action/:id', :controller => 'invitation'

end

There models are common, but there is a distinction between the
front-end and back-end controllers and views.

I find this is a very natural means of doing just what I have been
attempting to do all along.  The only piece that I am missing is the
ability to take advantage of Radiant from the Rails side, which
apparently is a much sought-after piece that is now in the works.

At this point I am creating Rails layouts that are identical to their
Radiant counterparts.  It's not DRY, but it is workable for the time
being.

I'm eagerly anticipating seeing this extension so I can DRY things up.

Mario
Adam W. (Guest)
on 2007-05-30 23:59
(Received via mailing list)
On May 30, 2007, at 2:01 PM, Mario T. Lanza wrote:

>> I'm also very interested in allowing Rails pages to leverage Radiant
>> layouts, and that is the next thing I plan to work on.
>
> I find this is a very natural means of doing just what I have been
> attempting to do all along.  The only piece that I am missing is the
> ability to take advantage of Radiant from the Rails side, which
> apparently is a much sought-after piece that is now in the works.

I also wonder if the ability to take advantage of Rails partials in
Pages/Snippets/Parts would be useful to Extension designers. It would
primarily support creating models and tags which produce a kind of
'widgety' thing - not necessarily for public/generic consumption, but
for allowing Radiant Extension builders (developers working for CMS
users) to encapsulate something, leveraging the power of Ruby/Rails
while still protecting the CMS user from having the full power of Erb.

But are we going away from the 'original intent'? There's fascinating
conversation about the meaning of a piece of literature: is it found
in the text, in the author, or in the reader?

    adam
Matt Parrish (Guest)
on 2007-05-31 00:07
(Received via mailing list)
It looks like we're both looking for the same goals out of this
project.  The number one feature for us is to reuse the Radiant
layouts to keep that DRY.  And that's where this project will be
going next.

As for the rails portion of the site, the other thing this extension
allows for, is to be able to use the traditional RAILS_ROOT/app/
[controllers|helpers|models|views] folders instead of burying
everything into /vendor/extensions.  I think this also helps to
create a cleaner split between Rails and Radiant code and also makes
it easier to integrate Radiant into an existing Rails app.

Matt Parrish
http://www.pearware.org
John W. Long (Guest)
on 2007-05-31 00:50
(Received via mailing list)
Loren J. wrote:
> Did you consider wrapping it up as a plugin? Off the top of my head
> that seems like it could be the cleanest way to go, but I say that
> without seeing how you have it setup now.

I think I agree with Loren that Radiant as a plugin is a much nicer way
to go (vs. dropping it in your vendor directory). This way you could
install the pluginized version of Radiant with a simple:

   script/plugin install radiant

I'm willing to consider changes to Radiant make this integration easier.

> Are you suggesting that I develop from the Radiant SVN repository?
> Or are you saying that you'd be happy to host a copy of stable
> releases?

Perhaps you could work with Loren on this for the time being. He just
recently joined core and it sounds like you have the same goals. When
you have something ready you guys could drop it in:

http://dev.radiantcms.org/svn/radiant/trunk/plugins/radiant/

I'd suggest that the plugin would have the following directory
structure:

plugins/
   radiant/
     init.rb
     lib/
     vendor/
       radiant/  <<< an svn:external to trunk/radiant

All of this talk makes me think that we need to move all of the Radiant
models into the the top level Radiant module to avoid namespace
collisions.

--
John L.
http://wiseheartdesign.com
Matt Parrish (Guest)
on 2007-05-31 00:58
(Received via mailing list)
I like the idea of being able to install Radiant as a plugin as that
will make it easier to integrate with an existing Rails application.
However, when starting from scratch, the current method seems just as
easy.

As for the RadiantOnRails extension, I'll release that on RubyForge
for use with 0.6.1 and work with Loren on getting it to a Plugin-ized
version within Radiant SVN repository.

Loren, congrats on the promotion to Radiant Core team member! :)

Matt Parrish
http://www.pearware.org
Matt Parrish (Guest)
on 2007-05-31 21:15
(Received via mailing list)
The RadiantOnRails extension is now live on RubyForge at http://
www.rubyforge.org/projects/radiantonrails.  This extension allows for
Radiant to co-exist with a Rails application.  You can checkout the
code with the following command:

svn checkout svn://rubyforge.org/var/svn/radiantonrails/trunk

Or, to install the extension, follow the instructions from the
Radiant website (http://dev.radiantcms.org/radiant/wiki/Extensions)
using the name 'radiant_on_rails' for the extension_name.

Matt Parrish
http://www.pearware.org
Adam W. (Guest)
on 2007-05-31 21:34
(Received via mailing list)
On May 31, 2007, at 1:14 PM, Matt Parrish wrote:

> radiant_on_rails

Excellent.

   aiwilliams
Meekish (Guest)
on 2007-06-01 08:56
Matt Parrish wrote:
> The RadiantOnRails extension is now live on RubyForge at http://
> www.rubyforge.org/projects/radiantonrails.  This extension allows for
> Radiant to co-exist with a Rails application.  You can checkout the
> code with the following command:
>
> svn checkout svn://rubyforge.org/var/svn/radiantonrails/trunk
>
> Or, to install the extension, follow the instructions from the
> Radiant website (http://dev.radiantcms.org/radiant/wiki/Extensions)
> using the name 'radiant_on_rails' for the extension_name.
>
> Matt Parrish
> http://www.pearware.org

I already have a Rails app and would like to retrofit it with Radiant
using this extension. How would the process differ from starting with a
Radiant app and building it out into a Rails app?
Loren J. (Guest)
on 2007-06-01 11:35
(Received via mailing list)
Read through the Readme in the extension now posted on RubyForge (see
Matt's original post for address, etc) and you'll find that the
"installation" is very straight forward and will be the same whether
it's with a fresh Rails app or an existing one.

Give it a shot...
Meekish (Guest)
on 2007-06-01 12:21
Loren J. wrote:
> Read through the Readme in the extension now posted on RubyForge (see
> Matt's original post for address, etc) and you'll find that the
> "installation" is very straight forward and will be the same whether
> it's with a fresh Rails app or an existing one.
>
> Give it a shot...

I read the README before posting, but it seemed to me like it was
explaining how to modify an existing Radiant app, rather than an
existing Rails app:

==================================================
1. Edit RAILS_ROOT/config/environment.rb and change the following line

  config.view_path = File.join(RADIANT_ROOT, 'app', 'views')

to

  config.view_paths << File.join(RAILS_ROOT, 'app', 'views')
  config.view_paths << File.join(RADIANT_ROOT, 'app', 'views')
==================================================

The environment.rb file (RAILS_ROOT/config/environment.rb) in a stock
Rails app wouldn't have any mention of 'RADIANT_ROOT'

Am I misunderstanding the directions?
Loren J. (Guest)
on 2007-06-01 15:25
(Received via mailing list)
You're absolutely right, sorry I hadn't looked closely enough.

You could gem install Radiant and generate an instance and then merge
the necessary bits from the environment.rb it generates into your
existing app.

If I get a chance I'll try and determine what those necessary bits
are later today and email back what I learn.

Loren
Matt Parrish (Guest)
on 2007-06-01 17:34
(Received via mailing list)
Loren,

Yes, it's not quite straightforward at the moment to retrofit an
existing Rails app.  These are the exact issues that need to be
worked out for the plugin version of Radiant, though.  So, anything
you figure out should be applicable there.  I'm guessing that there
might be a few minor changes to the Radiant code to get things
working cleanly in instance, gem and plugin modes.

Matt Parrish
http://www.pearware.org
Meekish (Guest)
on 2007-06-02 05:17
Loren J. wrote:
> You're absolutely right, sorry I hadn't looked closely enough.
>
> You could gem install Radiant and generate an instance and then merge
> the necessary bits from the environment.rb it generates into your
> existing app.
>
> If I get a chance I'll try and determine what those necessary bits
> are later today and email back what I learn.
>
> Loren

So is the goal at this point to make it possible to install Radiant as a
plugin with the folder structure that John laid out?

plugins/
   radiant/
     init.rb
     lib/
     vendor/
       radiant/  <<< an svn:external to trunk/radiant
Matt Parrish (Guest)
on 2007-06-02 17:39
(Received via mailing list)
Yes, it seems to me like that is the goal.  Currently, Radiant takes
control of the files in config/ to do its initialization.  It seems
like we would want to keep the Rails files as is, and do the
initialization in plugins/radiant/init.rb.  I haven't looked at it
yet, but I'm guessing there will be a few challenges to getting this
to work properly.  One challenge I immediately see is getting
Radiant's routes to coordinate with the Rails ones in config/routes.rb.

Matt Parrish
http://www.pearware.org
Sean C. (Guest)
on 2007-06-02 17:42
(Received via mailing list)
Why not keep Radiant in vendor/radiant?  Then the startup scripts would
require less modification.

Sean
Matt Parrish (Guest)
on 2007-06-02 17:47
(Received via mailing list)
Oh, I guess I didn't realize that vendor/radiant would be any easier
than vendor/plugins/radiant.  How would that change things?  If it's
in vendor/radiant, don't we have to get into config/environment.rb or
config/boot.rb to load radiant, whereas if it was in vendor/plugins/
radiant, then Rails would automatically start initializing it
(although I'm not sure at what part of the process it would do that)?

Matt
Sean C. (Guest)
on 2007-06-02 17:53
(Received via mailing list)
The stock environment.rb and boot.rb will load Radiant from
vendor/radiant automatically.  The challenge of course, would be loading
the proper routes and adding the traditional app directories to the load
path.  I think you guys already have that, no?

The other issue is that Radiant radically alters the bootup process and
needs to do so for the purpose of loading extensions.  It's my guess
that if you put it in vendor/plugins/radiant, things are going to be
much harder to hook up.

Sean
Matt Parrish (Guest)
on 2007-06-02 18:13
(Received via mailing list)
Okay, cool.  As for the routes, my extension currently has the user
modify config/routes.rb a bit since /vendor/radiant/config/routes.rb
calls the Rails route initialization.  If we could change it so that
Radiant hooks into that process differently, then the developer can
write config/routes.rb as is done traditionally.  It doesn't look
like the Rails guys have given an easy way to hook into that process,
although it could easily be a one line call to Radiant to load its
routes at the end of the ActionController::Routing::Routes.draw { |
map| } block.  However Radiant's /vendor/radiant/config/routes.rb
would need to change slightly to be like how extensions define routes.

Here's the change I see.  Instead of how Radiant currently does
config/routes.rb and vendor/radiant/config/routes.rb as

load File.join(RADIANT_ROOT, "config", "routes.rb")

and

ActionController::Routing::Routes.draw do |map|

   # Admin Routes
   map.with_options(:controller => 'admin/welcome') do |welcome|

   ...

end


respectively.  It could look like this:

ActionController::Routing::Routes.draw do |map|

   # Place for Rails Routes
   map.with_options(:controller => 'admin/welcome') do |welcome|
   ...

   RadiantRoutes.define_routes(map)
end

and

class RadiantRoutes
   def self.define_routes(map)

   # Admin Routes
   map.with_options(:controller => 'admin/welcome') do |welcome|

   ...

   end
end

What do you think about making a change like that?  We would just
need to make sure that config/routes.rb can see the RadiantRoutes
class.  It wouldn't affect the current Radiant usage, but would allow
for developers to work with config/routes.rb like normal.  The
RadiantOnRails extension is like the first solution, except that I
have the user create a class RailsRoutes with a define_routes method
that my extension calls.  I think the second solution here would be
preferred.

Matt Parrish
http://www.pearware.org
Sean C. (Guest)
on 2007-06-02 19:03
(Received via mailing list)
Here's another option, one you may have considered already.

Extension routes are loaded before the Radiant routes and all of this is
taken care of by Radiant::Initializer.  You could either extend
Radiant::Initializer or use the define_routes block in the extension to
load the primary routes.rb.  I'm not sure whether you should parse,
process, and eval it or some other method, but it is conceivably
possible.  I think it has to do with generators or rake tasks, but
Radiant does something similar to redefine some stock Rails stuff.

Sean
Matt Parrish (Guest)
on 2007-06-02 19:26
(Received via mailing list)
Yes, that's basically what my extension is doing.  But it does
require a slight change to config/routes.rb, because vendor/radiant/
config/routes.rb is where the ActionController::Routing::Routes.draw
{ |map| } block is.  And I don't think we can have that there and in
config/routes.rb

Matt Parrish
http://www.pearware.org
Sean C. (Guest)
on 2007-06-02 19:40
(Received via mailing list)
Yeah, that's why I was saying perhaps a parse-and-eval method might
work:

1) Load the "#{RAILS_ROOT}/config/routes.rb" file as text.
2) Find and strip out the lines that contain the beginning and end of
the block.
3) eval the file in the local context of the define_routes block.

Not elegant, I know, but effective.

Sean
Matt Parrish (Guest)
on 2007-06-02 19:47
(Received via mailing list)
Yeah, that might work, but eeewwww! :)

Wouldn't it be better to modify Radiant a bit to have it be clean?
It's really a fairly non-invasive change to Radiant.
Sean C. (Guest)
on 2007-06-02 19:53
(Received via mailing list)
Yeah, I was also thinking of the distribution issue... how do you make
it relatively painless to use.

Here's another option -- I imagine that the project's lib/ directory
will be searched before the RADIANT_ROOT/lib directory, so you might be
able to replace the Radiant::Initializer class in there with
modifications.  This should give you the hooks you need.

Maybe we should continue this discussion in the IRC channel?  We're
getting very back-and-forth.

Sean
Jed H. (Guest)
on 2007-06-02 19:57
Sean C. wrote:
> The stock environment.rb and boot.rb will load Radiant from
> vendor/radiant automatically.

You mean the stock environment.rb and boot.rb from a Radiant app, right?
Isn't the idea to make RadiantOnRails act like a normal Rails plugin
that can simply be installed from the root of a Rails app with
'script/plugin install radiant_on_rails'?

I believe this is why John laid out the folder structure the way he did:

John W. Long wrote:
>plugins/
>   radiant/
>     init.rb
>     lib/
>     vendor/
>       radiant/  <<< an svn:external to trunk/radiant


That would be necessary to get auto-loading from a stock Rails app.
There seems to be a little bit of confusion in this thread ("Are we
adding Rails to a Radiant app, or Radiant to a Rails app?"), but I think
this snippet of Loren's original post should clear things up:

Loren J. wrote:
> putting Radiant in the vendor directory of an existing
> full-scale Rails app and having it play nicely

I totally agree with Loren that it would be a much more common scenario
to want to retrofit a Rails app with Radiant. I've created more than a
few Rails apps (primarily e-commerce stores) where the site owner
eventually wanted more control over the copy. Update rhtml >> check-in
>> cap deploy gets quite tedious after a while. Retrofitting the app
with Radiant (in an unobtrusive way) would have been a great solution.
Sean C. (Guest)
on 2007-06-02 20:05
(Received via mailing list)
I think Matt and Loren's cases are more about a tighter integration
between Radiant and the host application, including reusing Radiant
pages, layouts, and snippets in Rails.  If you just want to add some
content management to an existing Rails application, there's always the
Comatose plugin, which has been around for a while and is probably
better suited to that scenario.

Sean
Jed H. (Guest)
on 2007-06-02 20:16
Sean C. wrote:
> I think Matt and Loren's cases are more about a tighter integration
> between Radiant and the host application, including reusing Radiant
> pages, layouts, and snippets in Rails.  If you just want to add some
> content management to an existing Rails application, there's always the
> Comatose plugin, which has been around for a while and is probably
> better suited to that scenario.
>
> Sean

I spent a little bit of time with Comatose this week. It's a cool
project, but a little bit too basic for my needs. I think we would agree
that Radiant is—in many ways—an unparalleled CMS.
Loren J. (Guest)
on 2007-06-03 09:31
(Received via mailing list)
Two things from my perspective with regard to what's been said so far:

1. In my understanding the standard plugin architecture as suggested
by John gives us dead-simple Radiant plugin-ability to any forming or
existing Rails app. This is probably the primary objective for my
cases despite my whining about wanting to reuse my layouts, that and
calling snippets / page parts in Rails views is a second priority for
me.

2. I don't think we have to make the choice between "tight
integration" of Radiant content into Rails views and simplicity of
installation. They are different issues both with their own
significant challenges, so it doesn't make sense to try and achieve
both in the same release. So, I think addressing the plugin
architecture issues first is good. From that basis we can then work-
out integration issues (snippet helpers, layout reuse, etc.)

I figure if we go that route we'll have more people using Radiant as
a component of a larger Rails app sooner and therefore more input,
effort and ideas being contributed to making the content integration
stuff work as well and completely as possible.

3. I've used Comatose in a few projects and each of those cases I'd
rather have used a plugged-in version of Radiant instead. It's a
great project but I'd sure like to be leveraging my Radiant work and
skills when I integrate. This also makes the transition with my
clients from "we'll start with a simple content site" to "now let's
build a custom app" less expense and painful. This is a common enough
scenario for me.

I'll put some more time into playing with Radiant installed as a
plugin this week and see what trouble I find. Looks like you've
gotten a good start on the right questions for me Sean and Matt. I'll
report back on how far I get later this week.

Loren
Jed H. (Guest)
on 2007-06-03 19:39
Loren J. wrote:
> ..."we'll start with a simple content site" to "now let's
> build a custom app" less expense and painful. This is a common enough
> scenario for me.

I could see this being very common scenario for me as well. I'm moving
to a more iterative development process—hard-coded rhtml first phase,
then CMS second phase. I agree that the plugin would gain much more
exposure and feedback if we initially focused on making this a simple
process.

Since this is something I immediately need, I am very willing to pitch
in. I have to admit I've never made a plugin, but I have built about
seven production Rails apps.

If you point me to the right material, I could do some reading and
research this week and get up to speed on plugin development and help
out where possible.

Of course, if you feel it would be more a burden than a benefit to bring
on a plugin noob, that's ok too.
Jed H. (Guest)
on 2007-06-08 21:17
Loren J. wrote:
> I'll put some more time into playing with Radiant installed as a
> plugin this week and see what trouble I find. Looks like you've
> gotten a good start on the right questions for me Sean and Matt. I'll
> report back on how far I get later this week.
>
> Loren

Any luck, Loren?
Loren J. (Guest)
on 2007-06-09 03:10
(Received via mailing list)
Jed,

Thanks for checking. I actually gave the project several hours this
week and made some progress. I had a long conversation with Sean and
reviewed with him the issues I've ran into so far and the changes big
and small that may be required to make it work.

Feel free to email me directly and I'll fill you in and see if we
might work together on any part of it. I'm not really ready to
publish my "findings" to the entire list quiet yet, though I'd like
to do just that shortly...

Loren
removed_email_address@domain.invalid
This topic is locked and can not be replied to.