inseefr / eno Goto Github PK
View Code? Open in Web Editor NEWQuestionnaire generator
License: MIT License
Questionnaire generator
License: MIT License
Is it possible to separate the main instance in two ?
And is it possible to flatten the instance ? It will be necessary if we want to remove id sections of the main instance.
DDI2XMLPogues transformation.
Simpsons v2 questionnaire
Filters questionnaire
This element is misplaced since it doesn't need to be saved.
It needs to be moved to fr-form-util.
It has only one implementation for the moment so it can be easily renamed.
If the enofr:get-help function needs to be linked to another function or element, it would have to be handled in ddi2fr-fixed.xsl.
For the empty xd:desc elements, and the complex templates.
This requires to dynamically create the folder before processing and to delete it afterwards.
Folder reorganization
Enhancement of XSLT import mechanism
Enrichment of in-getter/out-getter mapping
A high level introduction to Eno
Is is exactly the same that the default Bind template but with a non used variable some code in comments using this variable.
Because it isn't appropriately named.
But I have no good idea !
This branch was used to prevent empty Xforms element to be written in the output (output/fr/models.xsl).
It lightens considerably the generated questionnaire.
If possible, it'll be an improvement if it was taken into account.
5 warnings raised by OSSRH during Eno publication:
Including CSS upgrade to target Orbeon version
The second one was inspired by the first one.
And the first isn't completely compliant with the Eno architecture.
In theory, the Table driver should write some elements, call some functions and continue the process with the children of the input.
Those children will call some other drivers, etc....
When I wrote the functionnality, I could not manage to do that, so I use a function to directly get the elements I needed as children and do the treatment within the Table Driver.
Some functions on the DDI side are a little weird.
It will be an improvement to refactor that part.
It is the template on xhtml:a.
It seems to me that it is not correctly placed.
Is it really dereferencing ?
Wouldn't it be more appropriate to :
Make dynamic tables appear with at least @minimumrequired lines
Do we need to create an init submission which will be called in a xforms-ready action to init the instance ?
Look for a way to internationalize the controlled vocabulary used by eno.
It might not be doable but it needs to be investigated.
The usage of this driver is weird and it is not at all generic.
It creates two xforms controls from a unique ResponseDomain.
And it indicates that the select values can only be between 20 and 60 in the output.
The driver is not reusable in that state.
There might be something to do with :
It might be impacted by issue #54.
It might help if the labels on the DDI side were harmonized.
Maybe something better or simpler could be done on the produced xhtml.
There are a lot of comments in the xslt stylesheets.
The useless comments must be removed.
In the future, if possible, branches must be used to keep some code that could be used later rather than keeping it in the master branch in comments.
Miscellanous parameters and anticipation of DDI 3.3.
The enoddi:get-codes-first-dimension getter doesn't return consistent result between Table and TableLoop driver.
In the first case it's a sequence of <l:Code/> that are returned, on the other it's a sequence of elements (used only to render the number of lines).
In the ddi2fr implementation, the TableLoop driver never use this getter but still it's a bit confusing for new implementation.
This getter should return consistent results from both driver (in the ddi2fr implementation, a dummy sequence is enough as l:Code are never used through this getter, only the number of lines is used).
For the empty xd:desc elements, and eventually within the complex templates.
Bug fixes:
Lang conf files are duplicated in both src/lang/fr and src/resources/lang/fr, should keep only one copy of it.
The xsl stylesheets are currently generated this way :
Maybe it could be done another way (to be discussed) :
It could be difficult but it would be more appropriate to build the control in ddi2fr.xsl by calling different ddi functions (existing or not).
At least in README.md.
Formalize process with XProc or equivalent.
Definition of a parameter file format (XSD / Schematron)
Some drivers are named as if they produced elements of the XForms namespace, whereas in fact they are not. This should be documented.
Example: xf-double-duree
.
Development of XMLPogues to DDI
Integration of XMLPogues to DDI
Development of DDI to XMLPogues
Integration of DDI to XMLPogues
If not, the corresponding template must be modified, and can probably be mutualized with another one.
A comment in the code seems to tell that the behaviour should be parametable.
A parameter needs to be created on a questionnaire level (in parameters.xml file) and used in models.xsl to know if the behaviour is wanted or not.
For example, the alert message :
'You shall type an integer number between x and y" is written a lot in the resource instance.
It should be possible to do something approximately like this :
Would it really decrease the size of the questionnaire ?
Would it be faster/slower/the same ?
It should return the values 'radio-button', 'drop-down-list' and 'checkbox' and not the values 'full' and 'minimal'.
The enofr:get-appearance function must not be directly linked to the enoddi:get-output-format.
The values 'full' and 'minimal' must be deduced from enoddi:get-output-format and enoddi:get-type in ddi2fr-fixed.xsl.
Good Job!!!!
Ed
It is a well-known open-source practice. See for example https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/FSDiskFullWriteError.java#L1
It is a very good idea of @BulotF.
It does seem a little counter-intuitive since, for example, a QuestionItem with a TextDomain response seems very close to an xf:input field.
But it will allow to delete a lot of templates which will become useless and to simplify a lot of other templates. It will increase the readability of parts of Eno.
It will have a big impact on the produced Xforms.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.