more.zites.net

For the second exercise of my Information Retrieval course at the university I had to do implement a relevance feedback system - so I thought: Why not build it upon drupal's search?

So that's what I did. The result is a working proof of concept module, which you can find in my sandbox and test at the demo site.

The system has two operation modes: One that uses "implicit feedback" and one that let's the user give "explicit feedback". The implicit feedback mode just tracks which search results the user has viewed, takes these results as relevant to generate an optimised search query and shows the improved results to the user.

The explicit system works the same way, but provides some UI for users to mark results as relevant and non-relevant, as you can see on the screenshot:

You can test the system at the demo site, which runs in explicit feedback mode. Once you have provided three positive results as feedback the system makes use of the Rocchio algorithm to generate an optimised search query and redirects you to the improved search results.

I'm going on vacation right now - so don't expect me to shop up in the issue queues or to respond to mails until Sept. 21.

:)

I'm happy to announce the rules 6.x 1.0 BETA 1 release. Check out the rules project page and try it. Now the API is frozen and modules developers are encouraged to write module integration and to port their workflow-ng integration to rules. You can find the documentation here.

To get token support everywhere in your actions you just have to install the latest development snapshot of it.

Now basically everything is there, including support for

• firing core actions
• grouping rules in rule sets
• scheduling arbitrary rule sets
• a module input evaluation system
• and much more!

If you want to know more details about the improvements done for rules 6.x check out the development status page or the slides from the drupalcon session.

Developers often want to embed a node form. So I'll try to work out, how this is done best in drupal 6. For 5.x I provided the subform element module, which was an easy way to do it. However recently I found out, that embedding fully working node forms in 6.x isn't so easy any more. The funky JS stuff of node forms, which relies on the #ahah form API property, fails if $form doesn't look that way it expects.

So how to embed a node form with working AHAH?

Fortunately, it's not that hard either. We must just ensure to keep the structure of $form as in the original form. So don't move the embedded form in $form['fieldgroup'] - or it's #ahah stuff gonna break.

So let's show how to embed a node creation form.

I'm really happy to announce that Content Profile is going to be the common base module for "profiles-as-nodes" solutions in drupal 6.x!

After a long discussion discussion about the bio 6.x port, I already thought my efforts to join bio and node profile development were for nothing.
But then the discussion continued and we were able to agree on a common base module, which avoids unnecessary code duplication and provides an API on which further extension modules may rely on. The people from FunnyMonkey started working on it and agreed with me on continuing my previous work on this topic: Content Profile :)

So now as we have a decision we can concentrate on coding..

Quite a long time ago I started the discussion about the future of the profile as nodes solutions out there (link). There was a lot of input to the discussion and most people (including me) agreed on variante 2 "build upon a small base module". This means we build a small, well tested simple profile-as-node solution, which can be further extended by other modules.

So I had started developing content profile and invited others to join in - but unfortunately no one did. Now after some discussion it looks like there will be a 6.x bio version - introducing the imho unnecessary duplicity again. As an affect code like views integartion, user register integration and so on has to be written twice - once for each solution. But in my opinion the worst is that further extension modules, which want to build extended functionality on top of "profile as nodes" can't support all solutions by building upon a single module - they would have to build support for each solution on its own. Don't mentioned that they can't rely on a unique API to do so.

So what I'm going to do now?

During the last days I was really busy with things like work and studying. So I had no time for the workflow-ng port "rules" for some days. Furthermore I'm going for one week to Ireland, so I won't have time during the next week either.
Anyway I plan to get back working on it as soon as I'm back from Ireland. I've already ported the API and overhauled it. I've added support for rule sets and improved things, so that the API is ready for further enhancements like generic scheduling and d6 actions integration. Furthermore I've written simple tests for the API, which will be a great help during further development.

As it looks like the rules API improvements take already too much time, so I won't be able to spend as much time as I'd like on the UI of the rules module. So I'll start with a more basic UI leaving the planned ajax/ahah usability improvements open for later. However if you like to help me working on that, contact me!

Actually I'm wondering what the features are that people are missing most in workflow-ng?

Currently I'm starting with the 6.x port of it, the rules engine. I'll utilize this opportunity to improve the system. So if you miss anything important, let me know now!

I'd also like to know your wishes! As a start, here are mine:

• generic scheduling support
• verbose mode, so that admins can track the execution of rules
• support for sets of entities
• to work with them - support for looping over these sets
• based on that support loading arguments from views
• basic variable support (strings, ..)

Yes, this all goes into the direction of a high level programming solution. Isn't it drupal's goal to eliminate the programmer? :)

I'm proud to finally announce the 2.0 release of workflow-ng. This brings a whole bunch of new features to you, e.g. now you can clone rule configurations, order them with weights or load further entities like (CCK) referenced users and work with them as usual.

For a more complete list have a look at the release notes.

Now I'm concentrating on the 6.x port, the rules engine. I hope to have at least a beta version out with the end of March.

Breadcrumbs...

One new feature workflow-ng 2.x just got, ist the "Set breadcrumb" action. Perhaps you know eaton's great custom breadcrumbs module? This new action is similar, but...

In addition to the new features which were already available for some time in worflow-ng's 2.x series, some further improvements are waiting for you!

Logging per entity

First off there is a new extension module, which is shipped with workflow-ng. It allows you to log a customize message on every support workflow-ng event for content or users. This is done by actions! For flexible display of the log messages, views support is available. So there a lot of possible use cases for this, I have to in my mind:

Activities..

You could easily log certain actions of users and their buddies and list them in blocks and pages generated by views. So you can build something similar like the (really interesting) activity module!

State change log

In workflows it's often desired to have a log of state changes. E.g. if content, let's say an article goes from "needs review" to "published" this should be logged and displayed on a tab associated with the article (yes, views can do that!).

Great, isn't it? Thank GHOP and corsix for that! Yes, corsix implemented the whole module in two GHOP tasks. This took him only 1 day per task, awesome!

Rules ?

Furthermore I've changed the terminology as preparation for 6.x. Configurations are now called rules. I think the term "rule" describes it very well.
With 6.x the core of workflow-ng will be a separate project: the Rules Engine