Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Beautify XML for extension activities

Hi Bob,
 
your solution is dangerous, as a child element may contain text nodes with more than whitespaces in it and you remove any text nodes, even those with real text in it.
 
I didn't noticed the equals and hashCode methods up to now, you are right, the current implementaion is incorrect for many use cases. I removed them now.
 
Greetings,
Tobias
 
p.s. I just noticed: After loading the pipeline the InvokePipelet-Object has the <extensionActivity> element connected and not the <invokePipelet> as expected. Thats confusing, especially in DOM updates and should be documented.

________________________________

Von: bpel-dev-bounces@xxxxxxxxxxx im Auftrag von Bob Brodt
Gesendet: Fr 28.1.11 18:53
An: BPEL Designer project developer discussions.
Betreff: Re: [bpel-dev] Beautify XML for extension activities


Hi Tobias,

Good news everyone! I've found the correct place in the BPEL editor code where XML beautification is handled (in the ElementPlacer class) so there should be no need to construct anything but Element objects in your serializers. I've also added some bulletproofing to BPELWriter to make sure only the first child Element of an extensionActivity is added to the <extensionActivity> (as it should be!), in your case the <proc:invokePipelet> element along with all of its descendants.

Another thing I noticed is that your InvokePipeletImpl and InvokeServiceImpl classes override Object#equals() - this is NOT a good practice (in fact, it's VERY BAD ;^) because the GEF EditPart hierarchy uses "equals" on the contained model objects to determine where to place new EditParts when they are created. Currently, your "equals" overrides return true for ALL instances of InvokePipelet and InvokeService. This causes all kinds of problems in both the editor's Diagram page as well as the Outline (which is also a GEF based viewer). You can see the effect of this by opening the Outline view, then adding a couple of Pipelet objects - you should see that the Outline viewer only shows a single Pipelet and throws a bunch of IndexOutOfBounds exceptions. I suggest you change the name to something less intrusive, like "compare".

Anyway, the fixes are in CVS and we should have a new build tonight (if all goes well ;) Let me know if this works for you, and I'll close this bug.

_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat


________________________________


	Hi Tobias,
	
	I'm trying to come up with a fix for this, but I'm not sure what exactly you're trying to do. Can you please send me your latest versions of the InvokePipeletSerializer and InvokeServiceSerializer classes that insert the text nodes?
	
	Thanks!
	_______________________________________
	Robert ("Bob") Brodt
	Senior Software Engineer, JBoss Riftsaw
	JBoss by Red Hat
	
	
________________________________


		Hi Bob,
		 
		we are currently finishing our SMILA extensions for the BPEL designer. One of our goals is to beautify the generated XML. 
		 
		Now we have the following problem: When adding a new extension activity the serializer has no knowledge of the current indention - the "parentNode" parameter is just an empty document fragment. Additionally we can't indent our root element, as BPELWriter#extensionActivity2XML (line 1338) expects an element as first child of that fragment and throws a class cast for any (whitespace) text node.
		 
		Any suggestions?
		 
		Thanks,
		Tobias
		 

		_______________________________________________
		bpel-dev mailing list
		bpel-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/bpel-dev
		



	_______________________________________________
	bpel-dev mailing list
	bpel-dev@xxxxxxxxxxx
	https://dev.eclipse.org/mailman/listinfo/bpel-dev
	


<<winmail.dat>>


Back to the top