none
Extensibility - Using search as an example

    General discussion

  • I have been looking at Orchard development for a while and I like it extensibility. Since you will be focusing on the core of Orchard in the next iteration, I think this discussion is important:

    Could you give some pointers on how one could build a module that makes existing content items searchable?
    Basically, it would be a module that can detect blog posts and pages when they are created/updated, index them and provide search views on the front end website.

    There are two approaches that I can see:

    A - The new module has strong references to the existing modules (blog, page, etc.) and manually handles each content type. This is quite simple and provides great control, but it only works on the limited modules that are supported (adding support for a new module implies more work)

    B - A generic approach to detect content items and make them searchable. Not sure how that would be implemented but it could be a great one-time solution that works everywhere. One danger is that it might not perform well due to lack of knowledge on the meaning of the fields in the content items. This could be alleviated with some AI techniques and/or some (re)configuration in the admin section (like telling the module what to (not) index and giving indications for relevance ranking).

    Searching is just an example here; there are many other extensions that one could want to be able to "drop" on existing modules.
    In a broader sense, I want to talk about possible scenarios where a module would want to manipulate content items as they are loaded/saved and inject some views (or just some script) inside other modules.
    For example: A module that detects url/phonenumber/address on a page/post/wiki/... and injects some custom behavior like a link/map/image.

    People familiar with Google Wave would notice that this is similar to the concept of robot there and maybe some aspects of gadgets. They are its main extension points (and follow some interesting design principles).

    I understand that there is a limit to how extensible Orchard can be, but it would be nice to consider all these and see if it can help make Orchard better.

    What do you think?

    Monday, March 29, 2010 9:11 PM

All replies

  • Great questions, thanks.

    Searching is something that we're thinking about, and we have some ideas, but we're not working on it currently. This is kind of a great timing though as I just wrote that: http://weblogs.asp.net/bleroy/archive/2010/03/29/nosql-is-not-about-object-databases.aspx which is related to thoughts about search, and also in a broader sense querying.

    Search and querying will be generic in Orchard, that's for sure. We wouldn't have it another way.

    As to manipulating contents as they get loaded/saved, the infrastructure for that is already in place. It's even at the core of our work to enable multiple parties to participate in the construction of contents. We are also going to add output filters at some point in the future, which will enable more of the scenarios you mention.

    Does this help?

    Monday, March 29, 2010 10:43 PM
  • I understand that searching will get a "special" treatment in its implementation; which is understandable considering its importance.

    This actually makes me wonder: Will Orchard always be tightly coupled to NHibernate?
    When looking at the way Orchard handles persistence, so transparently, I had the thought that writing another persistence layer using Azure Table Storage would be great and fit nicely.

    As for the other scenarios, could you give me some pointers as to how a new module could manipulate content items as they are loaded/saved? Is it done using InlineStorageFilter and the approach "A" I described above?

    Is there also a way to intercept any content item, without knowing its type or name (approach "B")?

    Finally, I hope that you will be adding output filters in this iteration; it will allow me to do some interesting stuff :)

    Thanks,
    Pierre Henri.

    Tuesday, March 30, 2010 7:05 PM
  • Orchard is not tightly coupled to NHib. I'd say it's tied to the availability of it's features ;) In other words, you could replace with something else as long as it has the features we rely on. But as you can see, the higher layers of the app (blogs, etc) don't even have a reference to the NHib dlls.

    I think you should look at drivers and handlers, for example the HasCommentsHandler and HasCommentsDriver classes. Can you be a little more specific about what you're trying to achieve?

    Output filters won't be this iteration, sorry, but I take good note of the request.

    Wednesday, March 31, 2010 4:35 AM
  • I think Orchard is (becoming) a great platform, and I'm just thinking about various scenarios and how I would implement them.

    The output filter will probably cover this, so I will wait until it is implemented to investigate it further.

    Thursday, April 01, 2010 8:26 PM