Problem/Motivation

Contextual data from analyzers is now part of analyzer results.

However, the native contextx of the DefaultAnalyzerResult (e.g. user) are only accessible thorigh specific interfaces, not through the context system.

Proposed resolution

Expose this properties through context system too.

This allows context introspection once integration to tools like Rules is done.

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

miro_dietiker created an issue. See original summary.

miro_dietiker’s picture

Priority: Normal » Major

Raising prio as it changes majorly our architecture. Not sure how much it breaks our API.

drobnjak’s picture

Assigned: Unassigned » drobnjak
drobnjak’s picture

Assigned: drobnjak » Unassigned
miro_dietiker’s picture

This issue has no overlap with the idea to drop the topic based analyzer structure.

It's just about putting typed context to the defaultAnalyzerResult for the existing properties so that they can be accessed through the context system and enumerated when asking for existing contexts.

ModernMantra’s picture

Assigned: Unassigned » ModernMantra
Status: Active » Needs review
FileSize
563 bytes

Little progress... most probably not in good direction. Will soon made some more exploration/reserach on this issue :)

Status: Needs review » Needs work

The last submitted patch, 6: contexts-2770553-6.patch, failed testing.

mbovan’s picture

Currently, DefaultAnalyzerResult has $contexts property (representing collection of contexts attached to the analyzer result instance) and several (hardcoded) properties like sender, account, body, footer, subject etc.
In the first place we added them (as properties) for two reasons:

  • In order to allow collaboration between analyzers
  • As they are "standard" mail properties, we assumed that (all) analyzers would benefit from direct access

However, some time afterward we realized that we can use context system and achieve the same results. That means, to provide first steps for future integrations with Rules too.

The goal of this issue is to replace default analyzer properties with contexts (see #5). Each of the analyzers would set/update the context in case they need it.
That said, we have to identify the moments where analyzers need those properties (now contexts) and create/update them.
Another option could be to create the contexts (with no values?) when DefaultAnalyzerResult is initialized? That would make things easier regarding the ensuring/accessing the contexts on Analyzer level.

As an example how to set/add context, you can look at Drupal\inmail_test\Plugin\inmail\Analyzer\TestAnalyzer::addContext(). Mailhandler module can serve as an example too.

Also, since this is an API change we would need to investigate how much it breaks Inmail integrations: inmail_cfortune, inmail_collect, inmail_mailmute, inmail_demo, inmail_phpmailerbmh and mailhandler.

Hope the things are clearer now.