Been thinking about this more, the reason for this is the lack of
orthogonality in:
addPackageFromXML, addProcessFromXML
Process is just another package type, thus we are creating exceptions in
our terminology. Now we do already have pre-agreed file extensions,
maybe we can create enums for these and insist they are used as an argument.
kbuilder.addResource( reader/url, KnowledgeType.DRL )
So the support knowledge types could be in the KnowledgeType drl as:
DRL, DSLR, RM, XLS, CSV
we could even say that when URL is used, we don't need to use the
KnowledgeType, that's only for Reader.
kbuilder.addResource( url )
kbuilder.addResource( reader, KnowledgeType.DRL )
Although when loading dsls you need another argument:
kbuilder.addResource( reader, reader )
we already know that's a DSL, so not sure if the enum makes sense there
Thoughts?
Mark Proctor wrote:
What do people think of insisting on a file per type. So functions go
in one file, rules in another and declare models in another. They all
end up in the same package object, but we enforce a separation at both
the file and api level.
kbuilder.addRulesFromURL( url );
kbuilder.addModelFromURL( url );
kbuilder.addFunctionsFromURL( url );
kbuilder.addProcessFromURL( url );
Really more thinking about orthogonality of api and design here. We
have the following situation
kbuilder.addPackageFromXML()
kbuilder.addProcessFromXML()
Processes live in a package, so to a package there is no difference
from a process to a rule - yet we are losing that orthogonality in the
api to handle the special case.
What do people think, I'm just trying to find a better way to get some
language orthogonality. I don't think we are likely to do this, but
just throwing it out for discussion.
I think ideally we would like kbuilder.addResource( url/reader ), but
not sure if we can easily determine each file type, we can't do it by
file extensions as readers have none.
Mark
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
