[Radiant] Plugin System Meeting

[Oliver Baltzer]

I forgot, the times in the logs are ADT/GMT-4.

On 18-Sep-2006 23:26 -0300, Oliver Baltzer was heard to say:
> Hi all,
> 
> On 18-Sep-2006 15:45 -0400, John W. Long was heard to say:
> > This evening at 8pm Eastern, a couple of us are getting together over 
> > IRC on the #radiantcms channel to discuss what the plugin system should 
> > do and be.  Anyone with an interest is invited to attend:
> 
> The logs of the main part of the meeting are attached or viewable at
> http://nobits.org/irclogs/radiantcms-20060918-2155-2100
> and summarize in which direction immediate future development might go.
> 
> After that we went on to more futuristic thinking resulting in the
> following log:
> http://nobits.org/irclogs/radiantcms-20060918-2259-2155
> 
> Unfortunately, the logs are text only at this point. I am still lacking
> this PrettyIRCLog behaviour, I always wanted to have.
> 
> Cheers,
> Oliver
> -- 
> Oliver Baltzer
> .web   > http://nobits.org/oliver/
> .pgp   > 0x32B54706

> 21:00 < alxh> hi
> 21:00 <@o> hi
> 21:00 -!- mode/#radiantcms [-o o] by o
> 21:00 < alxh> check out the last changes on http://dev.radiantcms.org/radiant/wiki/RPS2
> 21:02 < o> I like ideas for the Advanced Plugin System, but I was wondering how to include views, since this seemed to be a most difficult part to do.
> 21:03 < alxh> let's see if John is here.
> 21:03 <@jlong_> i'm here
> 21:03 < o> I had a similar thing sort of put together a few months ago, but got stuck with view.
> 21:03 < alxh> we were talking about Plugins vs. Behaviors ...mabe this is the point to go ahead and see how they differ and compare to each other
> 21:04 < alxh> in the ferret driven search behavior I had no trouble including views by shifting things around a little
> 21:04 < o> I thought plugins are a requirement for behaviours?
> 21:05 < alxh> http://dev.radiantcms.org/radiant/browser/trunk/plugins/search
> 21:05 < o> I mean for user-added behaviours
> 21:05 <@jlong_> o: you are right
> 21:05 <@jlong_> they pretty much are
> 21:05 < alxh> there are two major ideas here I think:
> 21:06 < alxh> 1) Plugin::Behavior < Plugin::Base (?)
> 21:06 < alxh> 2) Behavior::Base (standalone ?)
> 21:07 <@jlong_> alex
> 21:07 <@jlong_> you keep talking about (1)
> 21:07 < alxh> conceptually i think 1) makes most sense but John has a good point that this is not what we want
> 21:07 <@jlong_> but i don't see any need for a complicated model
> 21:07 < o> alxh: interesting to see views working in plugins, is that a recent feature of the Rails plugin system or did I just overlooked it?
> 21:08 < alxh> it's an idea that needs to be addresses today. I think it makes for a clean philosphy what we consider "Behaviors"
> 21:08 < alxh> o: no. it's a "hack"
> 21:08 < alxh> the main goal of ferret-search was to introduce views in behaviors
> 21:09 < alxh> ... thus eliminating previous work in which behavior developers hard-coded html
> 21:09 < o> I think 1) is a special use of the plugin system, which should be usable to add own controllers as well as extend with own behaviours.
> 21:10 < o> I mean extending with own behaviours is already pretty straight forward.
> 21:10 -!- rickster [n=rickster at user-37ka5nk.dsl.mindspring.com] has joined #radiantcms
> 21:10 <@jlong_> why would one be any clearer?
> 21:10 <@jlong_> or "conceptually" better?
> 21:11 < alxh> john: you mention that plugins are different from behaviors
> 21:11 <@jlong_> the plugin model object is
> 21:12 <@jlong_> it has a couple of methods that make managing plugins easier
> 21:12 <@jlong_> #init, #setup, #activate, and #deactivate
> 21:12 <@jlong_> init is called when the plugin is loaded by rails
> 21:13 <@jlong_> activate is called to activate a plugin within Radiant
> 21:13 <@jlong_> you can have both active and inactive plugins
> 21:13 < o> that is what I was thinking too, a mechanism to extend radiant with a minimum amout of mixins and a clean API.
> 21:13 <@jlong_> deactivate is called when you deactivate a plugin
> 21:13 <@jlong_> and setup is called when you first install a plugin
> 21:13 <@jlong_> to create tables, run migrations, etc...
> 21:14 < o> jlong_: re setup, are you thinking of being able to add plugins at runtime?
> 21:15 <@jlong_> no, probably not
> 21:15 <@jlong_> when you install a rails plugin
> 21:15 < alxh> john: Ok I see what you mean.
> 21:15 <@jlong_> doesn't it automatically run setup.rb?
> 21:16 < o> oh, right never mind
> 21:16 <@jlong_> so if you look back in the code of setup.rb
> 21:16 <@jlong_> it runs MyPlugin.setup
> 21:17 <@jlong_> alex: on the view end of things
> 21:17 <@jlong_> the way i would like for it to work
> 21:18 <@jlong_> is that if we implemented something similar to what you described in http://dev.radiantcms.org/radiant/wiki/RPS2RefactoredBehaviors
> 21:18 <@jlong_> then it would be just a matter of using partials
> 21:18 < alxh> correct
> 21:18 <@jlong_> in the app/views/site/ directory
> 21:18 <@jlong_> of a plugin
> 21:19 < alxh> yes
> 21:19 < aiwilliams> forgive me, I'm new here, but plugins would contribute behaviors, not *be* behaviors, right?
> 21:19 <@jlong_> i kind of think we need a good name for that
> 21:19 <@jlong_> aiwilliams: yes
> 21:19 < alxh> naminging is important here. it caused confusion even on my part
> 21:20 <@jlong_> the name that comes to mind is "RenderHelper"
> 21:20 <@jlong_> or perhaps "ControllerHelper"
> 21:20 < alxh> for Behavior::Request you mean?
> 21:20 <@jlong_> yes
> 21:20 < alxh> ok
> 21:20 < alxh> agreed
> 21:21 < o> ControllerHelpers as a name for what?
> 21:21 <@jlong_> a couple of weeks ago
> 21:21 <@jlong_> er
> 21:21 <@jlong_> o: Behavior::Request
> 21:21 < alxh> o:  http://dev.radiantcms.org/radiant/wiki/RPS2RefactoredBehaviors
> 21:22 < o> ok
> 21:22 <@jlong_> basically alex is suggesting that we give behaviors the ability to extend the controller object
> 21:22 <@jlong_> which would let you use any of the methods that a controller has
> 21:22 <@jlong_> render partials
> 21:22 <@jlong_> etc...
> 21:22 < alxh> i.e. render methods in (ActionController::*Helper)
> 21:23 < o> that would be ideal
> 21:23 < alxh> :-)
> 21:23 < aiwilliams> that makes sense to me. do behaviors provide views?
> 21:24 < alxh> RPS2's behaviors: yes
> 21:24 < aiwilliams> partials, I suppose you said
> 21:24 < alxh> the same for our purpose because the partials make most sense in tag definitions
> 21:24 < alxh> ...which brings up an important thing:
> 21:25 < o> so a behaviour would be able to act like a controller? I mean it sort of can already, but not very easily.
> 21:25 < alxh> tags are defined within a scope of site_controller
> 21:25 < aiwilliams> so in casual conversation, would I say "I have a page that is a bahavior", or "I have a page that has a behavior"?
> 21:25 < alxh> o, aiw.: correct. but let me explain in more detail:
> 21:25 < alxh> a page is a behavior.
> 21:26 < alxh> a behavior is a page.
> 21:26 < alxh> we say Page < Behavior::Base
> 21:26 < alxh> where Page class' body is more or less empty
> 21:27 < alxh> (again check the wiki  http://dev.radiantcms.org/radiant/wiki/RPS2RefactoredBehaviors)
> 21:28 < alxh> each behavior (i.e. each page) defines certain tags
> 21:28 <@jlong_> actually
> 21:28 <@jlong_> i'm thinking i would like to go with your original suggestion
> 21:28 <@jlong_> a couple of weeks ago
> 21:28 <@jlong_> of getting rid of behaviors entirely
> 21:29 <@jlong_> and replacing them with an inheritance heirarchy for pages
> 21:29 < aiwilliams> yeah, I like PageType or somesuch
> 21:29 <@jlong_> exactly
> 21:29 < alxh> ok let's talk about this more!
> 21:29 <@jlong_> a lot of people seem to have had trouble with the name "Behavior"
> 21:29 < aiwilliams> mostly because it does sound like a mixin
> 21:29 < aiwilliams> not a superclass
> 21:29 <@jlong_> it once was
> 21:30 < aiwilliams> and I should be able to have a bunch of them
> 21:30 < aiwilliams> (if they are called behaviors ;)
> 21:30 < alxh> aiwilliams: bring this question up in 3 minutes again
> 21:30 < aiwilliams> :)
> 21:30 <@jlong_> mostly what i was trying to do with behaviors in the first palce
> 21:31 < alxh> ok for the records John in saying: Debug < Page. Right?
> 21:31 < alxh> (where Debug is an example of course)
> 21:31 <@jlong_> was to separate the code that is used in the admin from the code that is used in the site controller
> 21:31 -!- bhelmkamp [n=bhelmkam at c-71-205-204-25.hsd1.mi.comcast.net] has joined #radiantcms
> 21:32 < o> jlong_: inheritance hierarchy? do you mean, a page can have multiple "Behaviours", i.e. represent multiple things?
> 21:32 <@jlong_> no
> 21:32 < bhelmkamp> did I miss the plugin chat?
> 21:32 < alxh> bhelm: still going on.
> 21:32 <@jlong_> we are discussing getting rid of behaviors
> 21:32 < alxh> instead of Behaviors we subclass Page directly
> 21:33 <@jlong_> exactly
> 21:33 < alxh> i.e. Search < Page
> 21:33 <@jlong_> or SearchPage < Page::Base to be more precise
> 21:33 < alxh> I like Page::Search much better
> 21:33 < bhelmkamp> hmm... interesting
> 21:34 <@jlong_> Page:Search isn't very conventional in the Rails sense
> 21:34 < aiwilliams> how would I then get searching on the home BlogPage < Page::Base?
> 21:34 < aiwilliams> is it SearchResultsPage < Page::Base?
> 21:34 < alxh> aiw: no
> 21:34 < bhelmkamp> aiwilliams: the search box on a home page could submit to a SearchPage, right?
> 21:34 < aiwilliams> and the SearchPlugin contributes a handy little 'widget'?
> 21:34 < aiwilliams> yeah, right
> 21:35 <@jlong_> exactly
> 21:35 <@jlong_> you have a global tag
> 21:35 <@jlong_> for the search box
> 21:35 <@jlong_> that you can put on any page
> 21:35 < bhelmkamp> global tags are definitely in, right?
> 21:35 <@jlong_> definately
> 21:35 <@jlong_> i wish people would use them more
> 21:35 < o> jlong_: but global is bad
> 21:35 < aiwilliams> globals are bad, mmm kay
> 21:36 < aiwilliams> hehehe Java whiplash
> 21:36 < alxh> globals are "bad"
> 21:36 < bhelmkamp> lol
> 21:36 <@jlong_> that's why plugins should namespace stuff
> 21:36 < o> you mean the tags should be namespaced or the definitions
> 21:36 <@jlong_> the tags
> 21:36 -!- eean is now known as Boatswain_Eean
> 21:36 <@jlong_> so i have a search plugin
> 21:37 < alxh> how do I prevent from having two <r:title /> tags? one prints out h1 and the otherh2
> 21:37 <@jlong_> all of it's tags should be inside of "search"
> 21:37 < o> you can automate that during plugin registration
> 21:37 < alxh> s/otherh2/other <h2>/
> 21:37 <@jlong_> i don't see a need to automate that during plugin registration
> 21:37 <@jlong_> but it should be advised
> 21:38 < bhelmkamp> have people laid out some use cases for what they'd like to be able to do with plugins?
> 21:38 < alxh> I think people are resorting to globals because we don't support inheriting page attributes
> 21:38 < bhelmkamp> beyond search
> 21:38 < alxh> we should address this
> 21:38 <@jlong_> i've got a couple of use cases for plugins
> 21:38 <@jlong_> * a comments system for blogging
> 21:38 <@jlong_> * a redirect plugin
> 21:39 < bhelmkamp> here's ones I'm thinking of...
> 21:39 < bhelmkamp> * an asset manager, probably a separate tab in the admin ui
> 21:39 <@jlong_> that's a big one :-)
> 21:40 < bhelmkamp> * an event system
> 21:40 < bhelmkamp> which need start/end dates and times, show up on calendars, etc.
> 21:40 < o> people should write global tags, but where does the functionality come from? I mean, the gallery plugin for example has to deliver binary images.
> 21:40 <@jlong_> * a custom model object plugin
> 21:40 <@jlong_> so you could define models (like events) in the admin ui
> 21:40 < bhelmkamp> and then we often have one domain specific model we want to manage on a Radiant site... like a basic product DB
> 21:40 < aiwilliams> * a contact database
> 21:41 < bhelmkamp> jlong_: yeah, that's the same thing, I think
> 21:41 < bhelmkamp> I love the Radiant admin UI, but I think it's kind of cumbersome for managing a lot of the same thing
> 21:42 <@jlong_> you mean you think a lot of tabs will clutter the admin interface?
> 21:42 < o> jlong_: considering the comments system, where should the comments be stored?
> 21:42 < o> jlong_: aren't they pages just as any other page?
> 21:42 <@jlong_> in their own model object
> 21:43 <@jlong_> pages have a physical url
> 21:43 <@jlong_> comments don't
> 21:43 < o> why not?
> 21:43 <@jlong_> because most blogging systems don't work that way :-)
> 21:43 < o> what about images?
> 21:43 < o> or contact addresses?
> 21:44 <@jlong_> that's up to the plugin author
> 21:44 <@jlong_> if you look back at the Advanced Plugin System page
> 21:44 <@jlong_> you'll see that there is an app/models directory
> 21:44 < bhelmkamp> jlong_: no, didn't mean lots of tabs... I mean if you have 50 of something at the same level in the tree
> 21:44 < o> that is what I mean, a page should be more abstract and the specfics are defined by its implementation/behaviour.
> 21:45 <@jlong_> bhelmkamp: in most cases you shouldn't have 50 something at the same level of the tree
> 21:46 <@jlong_> o: i don't want to see us end up with a complex inheritance heirarchy
> 21:46 <@jlong_> where everything in a web site decends from "Asset"
> 21:47 < bhelmkamp> jlong_: with pages, right... but I might have 50 objects from a specific model which I'd like to build into a Radiant plugin once this stuff is figured out
> 21:47 <@jlong_> bhelmkamp: then put them on their own page
> 21:47 < o> jlong_: ok, I guess no cookie for me
> 21:48 <@jlong_> er, tab
> 21:48 < bhelmkamp> can you do that with the current plugin system?
> 21:48 < bhelmkamp> that's what I'd like to do
> 21:48 <@jlong_> we'd like to make it so that you can do that
> 21:49 < bhelmkamp> ok, cool... that'll solve my problems :D
> 21:49 <@jlong_> http://dev.radiantcms.org/radiant/wiki/RPS2
> 21:50 <@jlong_> ok
> 21:50 <@jlong_> to sumarize
> 21:50 <@jlong_> what we've got so far is:
> 21:50 <@jlong_> * get rid of behaviors in favor of Page types
> 21:51 < bhelmkamp> was just looking at that... sorry, just getting into Radiant as a way to get rid of our own custom Rails Engine CMS
> 21:51 <@jlong_> * create an advanced plugin system as outlined: http://dev.radiantcms.org/radiant/wiki/RPS2AdvancedPluginSystem
> 21:51 < bhelmkamp> jlong_: as an aside, that seems _very_ similar to Rails Engines
> 21:51 <@jlong_> * come up with some way to allow Pages to extend controllers
> 21:52 <@jlong_> anything lese
> 21:52 <@jlong_> *else
> 21:52 <@jlong_> ?
> 21:52 < alxh> give me a sec to organize my thoughts
> 21:52 < bhelmkamp> ..thinking... :)
> 21:52 < aiwilliams> * Implement asset management plugin
> 21:52 < bhelmkamp> aiw: well, yeah... but that's a side project
> 21:52 < o> jlong_: I think that was the core of the dicussion.
> 21:53 < bhelmkamp> how do Page types differ from behaviours as far as the UI is concerned?
> 21:53 <@jlong_> bhelmkamp: it will be similar to engines, but hopefully cleaner and more powerful since you will have access to the admin ui
> 21:53 < bhelmkamp> similar? just a drop down at the bottom?
> 21:53 <@jlong_> yes
> 21:53 <@jlong_> exactly the same
> 21:53 <@jlong_> the internals get kind of interesting
> 21:53 < alxh> here the key phrases I like to throw out that should *directly* correspond to what john just summerized for us:
> 21:53 < bhelmkamp> is there a connection between page type and layout?
> 21:53 <@jlong_> but the interface will be the same
> 21:54 < alxh> MyPersonalPageExtension < Page
> 21:54 <@jlong_> bhelmkamp: no connection
> 21:54 < alxh> * MyPersonalPageExtension < Page
> 21:54 < bhelmkamp> jlong_: ok
> 21:54 < alxh> * Page::ControllerHelper module
> 21:54 < alxh> * Plugin::Base (setup etc.)




> _______________________________________________
> Radiant mailing list
> Post:   Radiant at lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

-- 
Oliver Baltzer
.web   > http://nobits.org/oliver/
.pgp   > 0x32B54706
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.radiantcms.org/pipermail/radiant/attachments/20060918/b311e85f/attachment.bin