anonymous wrote : Warning - I am a smooks noob, just have that in mind when 
reading my answers :)  

No problem. But I must confess that I am wondering now if we are talking about 
the same thing ;). 

I am also just brainstorming here, so my theories can also be wrong one or more 
points ;).

anonymous wrote : Of course, the problem is just that the two models of Smooks 
1_0 and Smooks 1_1 is vastly different so I'm not sure any strategy can be 
defined that would work. But of course if it is doable then sure. 

To make sure that we are talking about the same thing I am going to explain my 
idea in little more detail.. I am proposing to use Smooks its readers (XML, 
EDI, CSV, JSON, Java reader) to analyze an example file of the source data, 
that the final Smooks configuration is going to process. Because of Smooks its 
flexibility you can let Smooks do the reading but you provide your own code to 
build the data model. The resulting model will probably look a lot like a DOM 
model. The visitor classes, provided by the Smooks editor, that build the 
model, will be Smooks depended. But because Smooks is backwards compatible you 
can use the same classes for Smooks 1.0 as for Smooks 1.2.

I think what you mean is Smooks its configuration model. That changed a lot 
between version 1.0 and 1.1. But it is still possible to use the 1.0 
configuration model with Smooks 1.1. 


anonymous wrote : Sure, but we would now be bundling how many versions of 
Smooks ?
  | What about smooks 1.0.1, 1.0.2, 1.1.0, 1.1.1 etc ? 

Smooks is backwards compatible at every level. Even when you would provide 
different strategies for different versions of Smooks, they probably all can 
use the same version of Smooks. So you don't need to include Smooks 4x times. 
Only in the theoretical case that Smooks wouldn't be backwards compatible 
between minor versions, then you would have the possibility to use two 
different versions of Smooks. That makes sure that the Eclipse Editor isn't 
Smooks version specific. 

anonymous wrote : The Reader you mention in that paragraph is from Smooks or 
from the Smooks plugin ? 

I meant the Smooks editor implementation of the SmooksReaderStrategy.

anonymous wrote : the current editor at least in theory can survive broken 
parts and still read the rest. 

Personally I am not sure if surviving a broken part would be the correct thing 
to do. But that is a something for a different discussion. If surviving a 
broken input source would be needed then we probably could implement such a 
feature in our current readers.

The biggest point of my idea is that you don't need to re-implement something 
that is already provided. I don't see the point that you guys need to 
re-implement the XML, EDI, JSON, etc readers.

Max, would you be interested to talk about this topic during a chat session? 
That would go a lot faster and probably prevent a lot of misunderstandings then 
discussing this via the forum. Do you use Skype? If you are then maybe Tom 
Fennelly would also be interested to join the conversation.

View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217639#4217639

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217639
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to