I am left with a bit of a dilemma regarding one of my latest Mura plug-ins, URLIntercepts.
Basically this is a plug-in that intercepts a Mura page request, looks for patterns in the url that have been identified (such as /go/storefront/shoppingmall/) and then allows the application to split off the remainder (or match + remainder) and put this into a response object. The remaining url (i.e. /go/storefront/) is passed to Mura as a regular page request. This makes it possible to use clean, SEO friendly urls and hide garbage information (ie. ?prid=blah&page=blah...) from the user. Currently it uses both path-matching and regex to look for matches.
The complication comes in with use scenarios. I actually built it before I needed it or used it, which in itself makes it a exercise in assumption. Now that I have begun to actually implement it into a product (Mura Forums, now officially named Meld Forums for Mura), I have made some significant changes to how I implement it. Intercepts in Mura have to be (by definition) a dynamic affair. Plugins will generally never know where they are going to be displayed until a content object is inserted and saved on a page, so it follows that an intercept will never exist until that action has been completed. The exception to this would be where they are manually configured/created. The latter is currently the only option (the former will come with the completion of Meld Forums), as currently they are manually created XML files (I figured only developers would be using this, and XML is easy to edit/replicate). There may be an option for them to live in the database as well (Mura Forums may dictate this).
I guess what I'm looking for is use case scenarios from people developing Mura Plugins. How would you use them? Would you create them dynamically, or use static files? Would you use this as a plugin, or integrate it directly into your application? If anybody has an application they are working on and wants to test it out, let me know and I'll send you a copy. I'm not sure if it's worth creating a whole RiaForge project for this (it will be GPL 2.x), but I might do that as well.
Once I've gathered a bit more data in this area, I'll clean it up and release it as a plug-in.
Thanks in advance.
Aug 29, 2009 at 6:45 PM Couldn't you just make your plugin aware that the URL interceptor plugin is available?
<cfset interceptorPlugInName=pluginConfig.getSetting('interceptorPlugInName')
<cfset interceptorApp=getPlugin(interceptorPlugInName).getApplication()>
<cfset interceptorApp.getValue('manager').addExpression('[regex]') />
Or something like that?
Aug 29, 2009 at 7:15 PM First, "aha!", that's how you get the package name for plugins!
And yes, that is a good example. My worry is having to have too many co-dependent plugins, while also worrying about having too many similarly functioning plugins (i.e. 4 plugins all using the URLIntercepts class or similar and smacking each other on the head).
The former is cleaner and easier on resources, but I'd have to code for no intercepts by default, and then to use intercepts if the plug-in is present ... or start acting like eclipse (er, sorry, you are still missing required classes...bork).
Or, if Mura did multi-install for dependent plugins ... heh, let's not go there, right Matt?
I am leaning towards your way, though (even though I am currently using the latter, i.e. intercept detection embedded in the application).
Aug 29, 2009 at 7:32 PM I think multi-install for dependent plugins is going to have to happen. Be we might not go there this very moment. :)
Sep 1, 2009 at 3:11 PM I think the way I'd like it to be used is the way Matt suggests. You'd have your "cleanURL" plugin which does the funky URL intercepting stuff. Then people would be able to use the API of that plugin when coding their own plugins in order to get clean URLS to work. If the "cleanURL" plugin isn't installed, then it defaults to the query string.
Also, i'd like to take you up on your offer and test out your plugin with a plugin I'm currently working on.
Sep 2, 2009 at 9:26 AM @Tony, yes that seems to be the way to go. I'm going to spend some time in the next week reworking them to a) use xml as general templates, which plug-ins can use to then b) load as active intercepts. I'll have to find a clean way of adding/removing active ones, either via custom events (which will require some exploration) or direct API calls to the plug-in. I'll probably lean towards the API method to start.
Ideally I see a listener on onContentSave/onContentDelete that looks for plug-in insertion/removal which then loads/removes its appropriate intercept via the API. It should be pretty straight forward, and I'll include a little demo display object in the plug-in to test/illustrate this.
Once this is done I'll fire you a 'test' copy to play with. I plan on a 'release' version to coincide with Meld Forums release, which looks to be on track for this month.
Oct 15, 2009 at 2:58 PM Hi all, I probably only understand half of that intricate backend technology, but I am looking forward to MELD enormously :-)
All the best,
Jonas