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 Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.GA Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Attachments: Screen shot 2010-01-09 at 08.56.01.png Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Attachments: Screen shot 2010-01-09 at 08.56.01.png Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Attachments: Screen shot 2010-01-09 at 08.56.01.png Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Attachments: freemarkertemplate.png, Screen shot 2010-01-09 at 08.56.01.png, ui.diagram.png, xmlstructuredmodeldiagram.png Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)

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 Assignee: Xue Peng Fix For: 3.1.0.CR2 Attachments: freemarkertemplate.png, Screen shot 2010-01-09 at 08.56.01.png, ui.diagram.png, xmlstructuredmodeldiagram.png Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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 :)