Draft: Input Parsing Refactor / Generic Input Extension Mechanisms #3180
Conversation
wrtobin
added
type: feature
|
Hello @wrtobin , I think this work is also related to this discussion #3073 I would be in favor of keeping things separated:
|
|
Part of this work is attempting to separate input file format dependence / parsing from internal group/attribute instantiation and definition. There is still work to do (clearly) but this includes abstracting inclusion to the point that files of arbitrary (but supported) hierarchical input formats can include other files of arbitrary (but supported) hierarchical input formats. Whether we want to fully allow that is a different concern from designing a system that is componentized in such a way to facilitate trivially supporting that. To accomplish that inclusion needs to be independent of document type, where it sits right now ( the current implementation ) is mostly a result of iteratively removing it from the xmlwrapper, rather than a hard decision of how we should actually accomplish this. |
|
The separation of file format / groups is a very good idea If follow you remark I'd say it should be possible to include yaml files in json files and theses files in xml files. But that's a bit weird. And yes the work sits in the xmlwrapper but I am concerned about the handling of these includes. |
|
The inclusion modification is currently the part of this work I like the least, yeah. While I don't necessarily want to support inclusion of files of different formats, my intent is to implement things in a generic enough way that such a thing is possible (though not supported), since really we're just working with a bunch of abstract trees in all cases. I'm amenable to reworking it and seeing if putting inclusion processing into document abstractions makes things cleaner. |
| auto & knownChildNames = childNamesMap[ dataParent.getName() ]; | ||
| document_node_pos docNodePos = m_document.getNodePosition( docNode ); | ||
| GEOS_ERROR_IF( std::find( knownChildNames.begin(), knownChildNames.end(), dataNodeName ) != knownChildNames.end(), | ||
| GEOS_FMT( "Error: An Input block cannot contain children with duplicated names.\n" |
| using PreprocessOnly = InputProcessor< xmlWrapper::xmlDocument, | ||
| Group, | ||
| TerseSyntax< xmlWrapper::xmlDocument, Group >, | ||
| Declaration< xmlWrapper::xmlDocument, Group >, | ||
| TerseSyntax< xmlWrapper::xmlDocument, Group > >; | ||
|
|
There was a problem hiding this comment.
I like the fact that we could be agnostic about the type & process of the input file in Group
There was a problem hiding this comment.
if the xml would be versioned, we could add a LegacyCompatibility phase that would transform the data model to the last version.
| inputExtension::InputExtender< document_node > m_inputExtender; | ||
| }; | ||
|
|
||
| template < typename DocumentType, typename DataNode, typename... Phases > |
There was a problem hiding this comment.
| template < typename DocumentType, typename DataNode, typename... Phases > | |
| template < typename DocumentType, typename DataNode, typename... InputPhases > |
|
|
||
| void xmlDocument::addIncludedXML( xmlNode & targetNode, int const level ) |
There was a problem hiding this comment.
As you guys already said about the moving / deletion of xmlDocument::addIncludedXML(), I also think it is up to the file format to define a way to include files.
No description provided.