[JBoss JIRA] Created: (JBIDE-5291) Generalize the code used to handle source to target template mappings
by Tom Fennelly (JIRA)
Generalize the code used to handle source to target template mappings
---------------------------------------------------------------------
Key: JBIDE-5291
URL: https://jira.jboss.org/jira/browse/JBIDE-5291
Project: Tools (JBoss Tools)
Issue Type: Task
Components: smooks
Reporter: Tom Fennelly
Fix For: 3.1.0.CR1
I'm wondering can we generalize the editor parts that handle the mappings between the Java Mappings and the target templating model. I probably didn't lay out my thoughts clearly enough on this, but what I was hoping for was that the target model parts would be agnostic of target message format (CSV, XML etc) and the templating technology used - FreeMarker only now, but I've structured the templating API to allow us add other TemplateBuilder impls e.g. for XSLT.
What I see at the moment in the editor is that when I attempt to make a mapping connection, I see the FreemarkerCSVNodeGraphicalModel and FreemarkerCSVContentGenerator editor model parts on the call stack. I may be reading the code incorrectly, but I would only expected to see totally generic editor parts at play here... imo, this mapping part of the process should be totally generic i.e. exactly the same, no matter what the target message format and templating tech.
I know I might just be reading the code incorrectly and I don't really understand the EMF process, but I thought I should add this JIRA anyway so as to allow it be tracked ... if I'm talking rubbish, we can just reject this JIRA :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JBIDE-5675) Increase width and depth of Smooks automated testing
by Brian Fitzpatrick (JIRA)
Increase width and depth of Smooks automated testing
----------------------------------------------------
Key: JBIDE-5675
URL: https://jira.jboss.org/jira/browse/JBIDE-5675
Project: Tools (JBoss Tools)
Issue Type: Task
Components: smooks
Reporter: Brian Fitzpatrick
Fix For: LATER
Now that we have started putting together some automated tests, it's made me think again about what it is we should be testing...
At a high level, we have some basic functional areas... Setting the input data, mapping to some Java Classes, and then taking the data from the Java Classes and outputting to some other format (such as CSV or XML (XSD)).
We take input from:
* XML/XHTML files
* Incoming Java classes (meeting JavaBean-type interfaces)
* XSD/WSDL files
* CSV files
* EDI files
* JSON files
* Custom files (what requirements do custom Smooks inputs have?)
So we need to test to make sure that a variety of these input types can be successfully brought into the editor without errors. But since we only really support a limited set of inputs, this should remain pretty stable if we come up with a few solid examples of each. Tests should include edge cases such as Java Classes that don't match the Java Bean structure, invalid files, empty files, etc.
The next area is then the Java Mapping task, where we provide a facility for users to import Java classes to map their input to. These java classes need to meet the Java Bean-type structure.
This Java Mapping should be tested against:
* Java Classes that don't match the Java Bean-type structure
* Simple classes (single class vs. collection)
* Collection of simple classes
* Collection of compound classes
And the final area at this point is applying a template - either CSV or XML (XSD). This mapping between the Java Mapping task and the output template should mix/match a number of things, including but not limited to:
* (Same things we tested the Java Mapping against)
* Java Classes that don't match the Java Bean-type structure
* Simple classes (single class vs. collection)
* Collection of simple classes
* Collection of compound classes
Plus:
* Single-field CSV (field1)
* Multi-field CSV (field1,field2,field3,...)
* Simple XML (XSD) - i.e. XSD with only simple types
* Complex XSD - multiple complex types
* Invalid XSD
* Blank XSD
Generally I just want us to try and automate as many tests as we can. Dart, Tom & I can help you with this process once we get through the release.
Ultimately we need to think of as many weird or strange things as we can to start hitting fringe cases that our users may try. Users are talented in the ways they will try to make tools work. And I have to admit I've used the occasional screwdriver to pound in a nail (typically unsuccessfully) so we should anticipate the user will try and do the same thing with the Smooks editor.
The better we build our test suite, the better off we'll be as we add additional template types, new functionality, and continue to bang on this thing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months