Resource/Validator interface #803
Conversation
This reverts commit 8ca4d55.
cwhitten
left a comment
cwhitten
left a comment
There was a problem hiding this comment.
Good start, I'd like the see the following:
- Some more comments as to how the public API will be exposed and used in the application
- How we can leverage this system in custom schema scenarios
- The convergence plan for the
dialogLinttool
| case 'Microsoft.SendActivity': | ||
| target = value.activity; | ||
| break; | ||
| case 'Microsoft.TextInput': |
There was a problem hiding this comment.
This switch feels hard-coded, and this the only prompt where we hook in to LU, is it?
There was a problem hiding this comment.
This switich is hard-coded to extract lg template from certain type of actions. We only SendActivity and TextInput leverage lg template now.
This part is just moving the previous extracting logic into dialogResource. not adding\removing any features.
| id: `events[${index}]`, | ||
| displayName: '', | ||
| type: rule.$type, | ||
| isIntent: rule.$type === 'Microsoft.OnIntent', |
There was a problem hiding this comment.
Microsoft.OnIntent should come from the shared-menus package, not hard-coded here.
There was a problem hiding this comment.
Yes, as stated above, here i just put the code pieces into the right location, not intended to change it's behavior. And yeah, i will put a comments here, as i do in other places when i spot something not promising.
| * This is the one single validation library for any declartive assets | ||
| * that can power both command-line tool and composer | ||
| */ | ||
| export class DeclartiveValidator implements ResourceValidator { |
There was a problem hiding this comment.
s/DeclartiveValidator/DeclarativeValidator
| } | ||
|
|
||
| if (validator !== null) { | ||
| return validator.validate(resource, resolver); |
There was a problem hiding this comment.
is this where all the validation will happen?
There was a problem hiding this comment.
yes, and this DeclativeValidator is actually the expected entry of "dialogLint".
See comments below how i vision a, how to handle customized schema, b. how to converge dialogLint
|
|
||
| /** | ||
| * TODO: | ||
| * 1. use schema to verify json structure |
There was a problem hiding this comment.
the schema used to do the validate needs to from the caller. as in any bot with it's own schema needs to be able to use this system of classes and validation will just work.
There was a problem hiding this comment.
the design here is schema is located and loaded into resourceExplorer, and when valiadtor needs it, it ask resourceResolver.
It's behaved the same way like any other resources needed to validate a dialog.
For example, in a.dialog,
{
$schema: "path to schema",
generator": "file name of lg file",
recognizer: "file name of lu file",
...
}
to validate such a dialog, it depends the actual content from schema file, lg file, lu file, and those files are resolved in a consistent way, by asking the resolver to get the resource content.
So, no matter it's customized schema or official schema release by us, it will use "$schema" to identify the source, and resource resolver will be able to resolve that. That's also why there is a "SchemaResource"
Sounds good?
Although there is many validators for each resource, there is only one entry to this whole validation functionality which is "DeclarativeValidator" which is also going to be the only public facing API surfaced out in Shell API, as also surfaced out as a library when we move this out.
Quick recap of the previous gap we see in DialogLint. DialogLint does dialog validation better than us now(which leveraged the schema), so we want that, but DialogLint don't handle LG\LU, so we create LG\LU to fill that gap. DialogLint coupled some file operation, we replaced that totally with the new resource system decoupled from storage location, which aligns better with the direction of runtime. |
|
Close this for now, i will rework on this, since some significant change in architecture would happen in master |
Description
Resource
Resource is a new interface created in this PR, which is a higher level abstraction of all declarative assets (dialog, lg, lu, schema, etc).
Motivation
Resource reference resolving
The background is adpative SDK used a "ResourceExplorer" which take over the resource management, including many aspects. Some aspects like basic CRUD, which is previously done in composer side with direct disk r/w. But other aspects like resource reference, which leverage a different way to identify resources (other than relative file path) and the interpretation\resolving of this id system.
For example, the SDK resource explorer would enable you to not specifying a full path when referring a lg file, you can just give the name, no matter you are referring a lg file from a dialog file, or from another lg file. Which means resource explorer takes over the reference resolving between dialog <-> lg, and between lg <-> lg. (side story, resource explorer today, don't handle lu<->lu reference)
For our validation scenario, the very first principle is to make sure, the validation works the same way as the runtime, which requires us to also create an abstraction layer enabling us to mimic the way how resource is identified, and how those reference are being interpreted in runtime.
Resource management
It might be debatable of whether it's reasonable to allow another approach of interpreting the resource reference, rather than just use relative path like many other systems do. Even we forget about the resource solving issue, bringing an abstraction for declarative assets also make the resource management significant easier.
We can share more common logic in this layer, and reduce lots of duplication\inconsistency, and the system can be more stable and predictable. Just in this PR, I spotted several inconsistency of handling difference kind of resources. A shared layer for basic resource management can bring us further.
Managed Lu
It also benefits managed lu scenario in certain level, the managed LU story requires the capability of manipulating lu content, with this resource interface, we move the generic functionality into resource, specific features for each type resource can be captured naturally inside each resource.
Changes summary
Major
Minor
Note, this PR is focusing on the abstraction, the interface, the mechanism, not any specific validation work, so i mark this as a code factor work.
Next
Task Item
closes #694
Type of change
Please delete options that are not relevant.
Checklist