Macrobyte Resources Conversant Developer Central
Internet groupware development platform
Plug-in architecture




 

Topic: Plug-in architecture

Shown in reverse chronological order.
Forward chronological order | Hierarchical outline view

Messages: 8 of 8.
Pages: 1
RE: Plug-in architecture (#249)
Posted: 5/23/2002; 7:09 PM by Philippe Martin
Modified: 5/23/2002; 7:09 PM by Philippe Martin
Response to: 246
Edit | Reply
Just some addition to Greg's and Seth's answers.

At 18:35 -0400 23/05/02, David Davies wrote:
>I'm familiar with the website fragment approach of Manila plugins whereby you create essentally a mini website within the plugin that's easily viewable via the web browser. How do I start making 'pages' for my Conversant plugin?

There is no website table, like in Manila plugins, because a Conversant plugin doesn't have to have associated pages. For instance, the email interface is implemented as a plugin. It has preference pages, because it has a "preferenceInfo" table that defines its prefs at system level, conversation level, and so on, but it doesn't have a "sub-site" à la Manila. Similarly, some other plugins are used to implement features called from macro calls, like the Bookmarks box, for example.

So Conversant plugins don't really have a required structure. Some tables are always there (like callbacks or tools, but I think only callbacks is required). Some are optional, and are used when present (like preferenceInfo). And you can create your own tables.

One thing to note, is that most plugins we've done are driven through callbacks. There are lots of callbacks available to plug in, as you can see if you look in the "callbacks" table of the plugins that came with Conversant.

Hope this helps at least a bit.

Flip
--
______________________________________________________________________
Philippe MARTIN (a.k.a. Flip) mailto:flip@macrobyte.net
http://www.MacrobyteResources.com http://www.Free-Conversant.com
RE: Plug-in architecture (#248)
Posted: 5/23/2002; 6:15 PM by David Davies
Modified: 5/23/2002; 6:15 PM by David Davies
Response to: 247
Edit | Reply
I'm *sure* you'll have more questions.

So you've heard about me then ;-)

Thanks for the pointers Seth. I'll take a look at this tomorrow and document what I come up with.

Cheers,

David.

RE: Plug-in architecture (#247)
Posted: 5/23/2002; 6:05 PM by Seth Dillingham
Modified: 5/23/2002; 6:05 PM by Seth Dillingham
Response to: 246
Edit | Reply

On 5/23/02, David Davies said:

>OK, I've made a plugin, restarted Conversant and activated my plugin
>via admin/system/preferences$section=Plugins
>
>I'm familiar with the website fragment approach of Manila plugins
>whereby you create essentally a mini website within the plugin that's
>easily viewable via the web browser. How do I start making 'pages' for
>my Conversant plugin?

To be perfectly honest, I'm *not* familiar with how this works. I've never looked at it. Greg may have, and I'm sure Flip has, and I'm equally sure that Brian hasn't. Anyway, there's very little chance that the plugins work in the same way.

What a "page" is, in Conversant, is sort of like a CGI script in a traditional server. The objects you create in your plugin's pages table are mini-apps.

There are two page types that are very, very simple, and make for an easy place to start learning about Covnersant's "pages". They are "Bound Message" and "Redirect".

The Bound Message is the easiest one to set up. Just do this:

1. Go to a message in your browser, like http://my_sites_url/1 (and make sure you're logged in)

2. Scroll to the bottom of the page, where the Admin Functions table lives. Look for the form that says "Bind Message to URL"

3. Type "a_new_page" into the text field, then click on the "Bind" button

4. A new page opens that tells you the new page was created, and where. Click the link. You've created a "Bound Message" page, and now you're seeing it for the first time.


Now if you want to study how that page works, open up the site in Frontier (or Radio). Look for a file under the "Windows" menu named "ConvZone_[sitename].root", where [sitename] is the name of the site you created in the installer. In that window you'll see a root-level table with the name of your site, and then a further structure like this:

ConvZone_myFirstSite.root
    myFirstSite
        members
        websites
            #Conv_zoneId
            #ipBanning
            myfirstsite

Open up that last "myfirstsite" table, and you'll see the contents of the web site.

Scroll down through the table until you reach the table named "a_new_page". Open it up.

When that page is requested through the browser, the #content script runs. That script was put there when the page was created. It's copied directly from the "page type's" prototype table, which you'll find here:

["MainResponder Interface"].pages.["Bound Message"].content

I know that's a long answer... I'm going to stop here, hopefully I've given you a place to start digging.

I'm *sure* you'll have more questions. Keep asking! LIke I said before, you'll helping to write the documentation.

Seth

RE: Plug-in architecture (#246)
Posted: 5/23/2002; 5:29 PM by David Davies
Modified: 5/23/2002; 5:29 PM by David Davies
Response to: 242
Edit | Reply
Hi guys

OK, I've made a plugin, restarted Conversant and activated my plugin via admin/system/preferences$section=Plugins

I'm familiar with the website fragment approach of Manila plugins whereby you create essentally a mini website within the plugin that's easily viewable via the web browser. How do I start making 'pages' for my Conversant plugin?

In my plugin's table I can see potential sub-tables for such a web site fragment but putting items in them doesn't make them available to the browser. For example, creating a new wp object in the 'pages' sub-table of the plugin doesn't do what I'd expect.

I'd appreciate a quick 2 minute tutorial on building a web site inside of a Conversant plugin.

BTW, I intend to document my exploits with Conversant in the off-chance that my stumblings will help someone else. For starters I'll create a 'how to get started with Conversant plugins' page in my blog.

Cheers,

David.

RE: Plug-in architecture (#243)
Posted: 5/23/2002; 9:06 AM by Seth Dillingham
Modified: 5/23/2002; 9:06 AM by Seth Dillingham
Response to: 242
Edit | Reply

On 5/23/02, Greg Pierce said:


>>Any pointers will be gratefully received!
>
>We'll be working on docs in the coming months -- but please feel free
>to ask questions here.  We'll do the best we can to keep you moving
>along in the meantime...

I'll just add that my primary focus for the next few weeks *is* developer documentation, and I'm well aware of the need for docs on writing plugins. They won't come first (first would be an explanation of some basics), but they will happen.

Thanks for your interest David. Keep asking questions, please... it helps guide my writing. (Plus, when Greg spends a long time answering questions like that, he does some of my writing for me!).

Seth

RE: Plug-in architecture (#242)
Posted: 5/23/2002; 7:54 AM by Greg Pierce
Modified: 5/23/2002; 7:54 AM by Greg Pierce
Response to: 241
Edit | Reply
On Thu, 23 May 2002 06:06:29 -0400, David Davies wrote:

>I've kind of answered my own question by downloading the trial version of Conversant and I've had a >first look at the anatomy of a Conversant plugin. I understand that Manila plugins won't work out of the >box but I expect a port is possible, especially if the plugin in question isn't too reliant upon Manila or >mainResponder, which mine isn't....

It would certainly be easier than porting a Zope product or something, but it will still require some work. It depends on what your plugin does how much work it will be. Conversant has an entirely different API, and entirely different macro engine, so they'll be a lot of changes necessary.

>Are there any doc available to help a potential plugin developer get started?

Sadly, no. We're just getting started on developer docs. :-(

There is an API call to create a plugin, I suggest you use that to get started...in QuickScript, run:

Conversant.plugins.create( [nameOfPlugin] )

This will automatically create the plugin, and place it in the "Conversant Plugins" folder so that it will be registered on restart of Conversant. Once you have created it, you need to go activate it on the system level by going to the admin interface under the "System" area ( button at top ) and selecting "Preferences" -> "Plugins" ( tab ). You have selections there for activating and deactivating plugins there. You also have checkboxes to determine whether that plugin will be active in new zones by default, or if it is even available to zones admins to toggle on/off.

At startup, Conversant loops over the "Guest Databases/Apps/Conversant Plugins/" folder and opens each GDB file. For each root, if there is a "Conversant Plugins" table at the root level, it loops over the entries in that table, and looks for a plugin by that name at the root level of the GDB, and registers it with the system. Look in "Conv_basePlugins.root" to see the set in action.

Like I said, the API call will set all that up for you, however.

At the zone level you have similar options for enabling/disabling plugins for whole zone, and whether conversations can enable/disable them.

Plugins are _not_ global in Conversant.

>Any pointers will be gratefully received!

We'll be working on docs in the coming months -- but please feel free to ask questions here. We'll do the best we can to keep you moving along in the meantime...

g.

RE: Plug-in architecture (#241)
Posted: 5/23/2002; 5:00 AM by David Davies
Modified: 5/23/2002; 5:00 AM by David Davies
Response to: 240
Edit | Reply
Hi again

I've kind of answered my own question by downloading the trial version of Conversant and I've had a first look at the anatomy of a Conversant plugin. I understand that Manila plugins won't work out of the box but I expect a port is possible, especially if the plugin in question isn't too reliant upon Manila or mainResponder, which mine isn't. Are there any doc available to help a potential plugin developer get started? For example, I seem to have been able to create a Conversant plugin but have no idea how to develop an interface for it nor get it to appear in the list of plugins at /admin/system/preferences$section=Plugins, if indeed that is what i need to do to make it 'work'.

Any pointers will be gratefully received!

Cheers,

David.

Plug-in architecture (#240)
Posted: 5/22/2002; 9:38 PM by David Davies
Modified: 5/23/2002; 3:19 AM by David Davies
Response to: Top of Thread.
Edit | Reply
Hi Guys!

I'm completely new to Conversant so I'd like to ask a question that'll influence my shift from Manila. I've got a lot invested in Manila plug-ins, those I've written myself and others. Is Conversant's plug-in architecture compatible with Manila's in any way? I'd expect there to be some differences not least due to Manila's quirkiness, but in principle can we easily port Manila plug-ins to Conversant? Do you have any recommendations for would-be plug-in developers, specifically on how best to share extensions to Conversant?

Thanks for offering an evaluation copy. I'll be taking a look for myself!

And good luck with Conversant!

Cheers,

David.

Messages: 8.
Pages: 1


 
© 2002 Macrobyte Resources. All rights reserved.