Refactoring Add Transform Wizard

[rcernich]

Hey all,

I'm working on integrating transformer creation into the service promotion workflow.  To enable that, I've done a bit of refactoring of the "Add Transform" functionality in the editor (right-click a connection, Add Transformer).  Here are some of the changes:

1. Renamed action to: Create Required Transforms
2. Action is available on the Composite figure, in addition to connections.
3. Action throws up an info dialog if all required transforms have already been created.
4. Wizard has been refactored to a single page:

What do you think about these changes?  Yea?  Nae?

Best,

Rob

[kcbabo]

• I think this view generalizes well to present a view of all transform pairs in an application.  If you click on an edge in the diagram, then you get the list of types used for the service/reference operations.  If you click on the composite, then you should get a list of all types used in the application.
• A list of all types/transforms is a handy thing to have at an application view.  Very efficient way to view missing/unhandled transforms and create them quickly, IMO.
• The biggest issue with this approach is the limited space to display the from and to type names in one row.  This is already an issue in the existing dialog for really long names and it will be much worse with this view.
• "Select Transform Pairs:"
  • We need a lot more space for the from and to names.  One thing you can do is widen it and drop it below the label.  Another thing would be to include the local part of the name and have the full name available as a pop-up or displayed on a separate line.  For QNames, this would involve trimming out the leading {} namespace URI.  For Java types, it would mean trimming "java:".  For ESB types, I'm not sure there's much that can be done.
  • Will this only list type pairs which lack a mapping?
• "Transformer Usage:"
  • I found this information to be confusing.
• "Transformer Type"
  • Seems straightforward for JSON, but what about transformer types which require extra information (JAXB contextPath, Smooks details, etc.)

[jeffdelong]

I like the wizard approach.

A couple comments on things to check for as you implement this based on some problems I am seeing with the current editor.

1) When I tried to change the transfrom from using JAXB to Smooks, once I removed the JAXB transform it would not give me option to add one.

2) Once I deleted the service and started over, when I added Smooks, it did not give me an option to add the Type (Keith's point above), so I had to hand edit the xml. Was not clear whether to add the type of SMOOKS or XML2JAVA.

[rcernich]

Hey Keith,

Thanks a lot for the feedback.

• I think this view generalizes well to present a view of all transform pairs in an application.  If you click on an edge in the diagram, then you get the list of types used for the service/reference operations.  If you click on the composite, then you should get a list of all types used in the application.

Yep.  That's how it's implemented.

• The biggest issue with this approach is the limited space to display the from and to type names in one row.  This is already an issue in the existing dialog for really long names and it will be much worse with this view.

Yep.  Space is a problem.

• "Select Transform Pairs:"
  • We need a lot more space for the from and to names.  One thing you can do is widen it and drop it below the label.  Another thing would be to include the local part of the name and have the full name available as a pop-up or displayed on a separate line.  For QNames, this would involve trimming out the leading {} namespace URI.  For Java types, it would mean trimming "java:".  For ESB types, I'm not sure there's much that can be done.
  • Will this only list type pairs which lack a mapping?

This only lists the missing transformers.  I have toyed with the idea of displaying all the required transformers, making the existing ones "checked" and not "uncheckable."  I would also want existing transforms to be displayed lighter, so the missing ones pop out.  Not sure how to do the graying, and I think I'll leave this as an opportunity for enhancement.

• "Transformer Usage:"
  • I found this information to be confusing.

Yep.  I figured.  I'll see if I can improve the label and the layout.  It is intended to provide details regarding where the selected transform is required.  In the case above, it is required for mapping input from the SourceService.operation() to the TargetService.operation().  I can see about turning this into a table: Message (input | output | fault), Invoking Service, Invoking Operation, Target Service, Target Operation.

• "Transformer Type"
  • Seems straightforward for JSON, but what about transformer types which require extra information (JAXB contextPath, Smooks details, etc.)

Yep.  JSON is easiest, so it's the prototype.  Depending on the complexity of the other types, the information will either show directly beneath the drop list (e.g. Context Path for JAXB) or add additional pages to the wizard (e.g. New Java Class).  I can post additional screen shots, once I've mocked those up.

Best,

Rob

[rcernich]

Hey Jeff,

Thanks for the feedback.

1) When I tried to change the transfrom from using JAXB to Smooks, once I removed the JAXB transform it would not give me option to add one.

We don't currently allow you to change the transformer types, so you're stuck having to go the delete/add route.  Please create an enhancement request for this.

2) Once I deleted the service and started over, when I added Smooks, it did not give me an option to add the Type (Keith's point above), so I had to hand edit the xml. Was not clear whether to add the type of SMOOKS or XML2JAVA.

This is clearly a bug in the Smooks support in the editor. It will be addressed in the new wizard, and I'll make sure the existing wizard (properties view, add) gets fixed too.

Thanks again for the feedback.

Best,

Rob

[jeffdelong]

I just added issue SWITCHYARD-1064

[bfitzpat]

Keith & Jeff both raise some great points.

For me, I just have a few questions/comments.

1) I'm hoping the wizard dialog is resizeable? And maybe have it remember the last size for the next time it appears? That may adjust some of the screen real estate concerns to a point.

2) Instead of a one-column table for the transformer context (usage), can you show it in two columns showing the From type and the To type? After all it's just showing a more concrete representation of the types list above.

3) Perhaps we could layout the labels a bit differently...

Type Pair to Transform:

...

Configuration Areas Where Transform Applies:

...

Type of Transform:

...

Additional Transform Details:

...

[rcernich]

Hey Brian,

Thanks for the feedback.

Keith & Jeff both raise some great points.

Always!

1) I'm hoping the wizard dialog is resizeable? And maybe have it remember the last size for the next time it appears? That may adjust some of the screen real estate concerns to a point.

It can be resized.  I'll make sure dialog settings are hooked up too.

2) Instead of a one-column table for the transformer context (usage), can you show it in two columns showing the From type and the To type? After all it's just showing a more concrete representation of the types list above.

Yes.  That's what I was trying to convey (in response to Keith's comments).

I like your suggestions for the fields.  I was going for breveity (Transformer Type vs. Type of Transform).  What do you think of:

• Transformer type pairs:
• Interaction contexts for selected transform pair
• Transformer implementation:

I'll have an updated screenshot illustrating a more complex implementation type (JAXB) in a few.

Thanks again,

Rob

[rcernich]

I don't have the stuff figured out for from/to, but here's an updated screen shot with new labels, layout and JAXB transformer settings.

Let me know what you think.

[bfitzpat]

Yeah, that works much better. And I like the additional section for the transformer type (the context path for the JAXB transformer).

[rcernich]

And the page for the Java transform class details:

I figured that list of types is what most users would use for representing non-Java data types.  Should I remove any types?  Add any types?  I was going to use String as the default, would another type make more sense?

Thanks in advance for the feedback.

Rob

[rcernich]

Regarding validation, the current setup let's you apply any transformer implementation to any transformer pair.  I was guessing that not all transformer implementations support all transform pairs.  Should I add validation for the selected pairs and should it look something like this: (assume all non-Java types are XML, more than that would require a lot of work)

JSON: only Java<=>XML

JAXB: only Java<=>XML (should I also validate that the context path supports the namespaces for the XML types?)

Java: any

Smooks: any, depending on setting

XSL: XML<=>XML

What do you think?

[kcbabo]

Rob Cernich wrote:

I don't have the stuff figured out for from/to, but here's an updated screen shot with new labels, layout and JAXB transformer settings.

Let me know what you think.

One thing to keep in mind is that contextPath is optional for JAXB transforms.  Other than that, the add/remove stuff looks nice.

[rcernich]

I've add validation to the selected transform pairs as described above (e.g. XSLT does not support transforms to/from Java types) and have modified the text in the table.  Let me know what you think.

[bfitzpat]

Quick question - how did they get it into this state?

I'm guessing the wizard comes up and the list of transformer type pairs appears pre-populated. Do only pairs without existing transformers appear?

Does the validation occur when the transformer type pair is selected? I'm guessing that the lower part of the wizard page changes based on that selection?

(Sorry, just trying to get context.)

Validation is awesome though - that will help avoid getting into an invalid state from the get-go.