[rules-dev] file per asset type

[Mark Proctor]

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
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>