Comments on: Fusebox XML Flowchart Generator https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: barneyb https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-199578 barneyb Wed, 16 Dec 2009 15:47:57 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-199578 Panos, I'm not sure what the issue is, but you can avoid the error by replacing 'verb.verbs' with iif(structKeyExists(verb, "verbs"), "verb.verbs", arrayNew(1)) which will just synthesize an empty verb list. It's entirely possible that I've missed some edge case with the XML format and that's the root issue; this was just an ad hoc project I threw together so I didn't do any sort of edge analysis. If you wrap line 13 with a cftry..cfcatch and just dump the 'verb' struct if an error is raised, that'll probably give you some insight as to what the problem might be. Panos,

I'm not sure what the issue is, but you can avoid the error by replacing 'verb.verbs' with

iif(structKeyExists(verb, "verbs"), "verb.verbs", arrayNew(1))

which will just synthesize an empty verb list. It's entirely possible that I've missed some edge case with the XML format and that's the root issue; this was just an ad hoc project I threw together so I didn't do any sort of edge analysis. If you wrap line 13 with a cftry..cfcatch and just dump the 'verb' struct if an error is raised, that'll probably give you some insight as to what the problem might be.

]]> By: Panos https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-199559 Panos Wed, 16 Dec 2009 11:50:54 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-199559 Thank you very much! Really good work and I really appreciate it! Helped me a lot with my new projects in order to understand the flow I have one issue though.. If i give the fusebox.xml and I check Pre/Post Fuseactions i get the following error <code> Element VERBS is undefined in VERB. The error occurred in /flowgen/inline.cfc: line 13</code> Thank you very much!
Really good work and I really appreciate it! Helped me a lot with my new projects in order to understand the flow

I have one issue though..
If i give the fusebox.xml and I check Pre/Post Fuseactions i get the following error
Element VERBS is undefined in VERB.

The error occurred in /flowgen/inline.cfc: line 13

]]> By: Dan O'Keefe https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-198260 Dan O'Keefe Thu, 03 Dec 2009 21:45:39 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-198260 This is amazing. I removed the " + getTextHeight()" but in place of that I added " -15" which lifts it up even higher and makes it more readable. Thanks much! This is amazing. I removed the " + getTextHeight()" but in place of that I added " -15″ which lifts it up even higher and makes it more readable.
Thanks much!

]]> By: barneyb https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-198250 barneyb Thu, 03 Dec 2009 19:35:41 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-198250 removed the " + getTextHeight()" from line 50 of fork.cfc and it should be above the lines. removed the " + getTextHeight()" from line 50 of fork.cfc and it should be above the lines.

]]> By: Dan O'Keefe https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-198249 Dan O'Keefe Thu, 03 Dec 2009 19:33:45 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-198249 I see what you mean. Yeah, that sounds pretty hairy to make all of those changes to try and accommodate the condition. Actually, if there was a way to bump it up 1 space, the text outputted would be above the horizontal lines coming off of the decision symbol. I see what you mean. Yeah, that sounds pretty hairy to make all of those changes to try and accommodate the condition. Actually, if there was a way to bump it up 1 space, the text outputted would be above the horizontal lines coming off of the decision symbol.

]]> By: barneyb https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-198248 barneyb Thu, 03 Dec 2009 19:27:40 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-198248 Dan, On line 26 of fork.cfc the variable 'txt' is set to the text that should be displayed in the rhombus. Currently the value is #my.verb.type#, which will always be "if". If you were to change that to #my.verb.attributes.condition# instead, you'd get the condition displayed instead. Note that that's not going to resize the rhombus based on the length of the condition, it'll just draw different text, quite possibly overflowing. If you want to change the rhombus's size, you'll need to dig into the guts of the draw() and measureInternal() methods to not only resize the rhombus, but also make all the arrows, spacing, and positions of the nested verbs correspond to the new rhombus size. Loops would benefit from similar display, though it's significantly more complicated, because you need to label the break/continue arrows, and the way they are controlled is varied amongst the different types of loops. Dan,

On line 26 of fork.cfc the variable 'txt' is set to the text that should be displayed in the rhombus. Currently the value is #my.verb.type#, which will always be "if". If you were to change that to #my.verb.attributes.condition# instead, you'd get the condition displayed instead. Note that that's not going to resize the rhombus based on the length of the condition, it'll just draw different text, quite possibly overflowing. If you want to change the rhombus's size, you'll need to dig into the guts of the draw() and measureInternal() methods to not only resize the rhombus, but also make all the arrows, spacing, and positions of the nested verbs correspond to the new rhombus size.

Loops would benefit from similar display, though it's significantly more complicated, because you need to label the break/continue arrows, and the way they are controlled is varied amongst the different types of loops.

]]> By: Dan O'Keefe https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-198247 Dan O'Keefe Thu, 03 Dec 2009 19:17:11 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-198247 Barney, Very cool tool, especially when you start working with an app you are not familiar with. Whats your thoughts on possibly displaying the condition for the ? Dan Barney,

Very cool tool, especially when you start working with an app you are not familiar with. Whats your thoughts on possibly displaying the condition for the ?

Dan

]]> By: imageTranslateDrawingAxis is Your Friend at BarneyBlog https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-196645 imageTranslateDrawingAxis is Your Friend at BarneyBlog Thu, 19 Nov 2009 08:49:10 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-196645 [...] Contact « Fusebox XML Flowchart Generator [...] [...] Contact « Fusebox XML Flowchart Generator [...]

]]> By: John Allen https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-196578 John Allen Wed, 18 Nov 2009 14:13:59 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-196578 That is pretty darn sharp. That is pretty darn sharp.

]]> By: barneyb https://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/comment-page-1/#comment-196554 barneyb Wed, 18 Nov 2009 04:19:13 +0000 http://www.barneyb.com/barneyblog/?p=1136#comment-196554 It depends on what you mean by "controller". Like in Model-Glue or Mach-II, the circuit.xml file in Fusebox represents a "flow" descriptor. You can embed logic in the XML, of course, but generally it's packaged into either fuses or CFC methods. You end up with XML that looks rather like MG or M-II XML, except that it's explicit invocation instead of implicit invocation. The typical verbs are INCLUDE (include a CFM, usually a view), SET (set a variable or invoke a CFC method), XFA (define an self-referential exit link), and DO (invoke another fuseaction). So your controllers usually end up as either CFMs or CFCs, your views as CFMs, and the XML is used to acquire the data you need to render the view and little else. To sum all that up, if you have a "real" Fusebox app with circuit.xml that looks like that example, you're probably doing it wrong. ;) And it's worth mentioning that XML is totally optional; you can do everything with convention and/or CFCs anymore. Regarding Groovy, it's been a while since I've done much raw painting with Java, but from what I recall, it's pretty much identical to what CF provides. The CF functions are relatively thin wrappers, though they smoothed the input/output stuff. So I don't know that it'd be much different, though I do know with Groovy I'd be able to go from my BufferedImage to the output stream without having to use the filesystem like I have to do on CF. imageDrawLine(img, 0, 0, 10, 10); versus g.drawLine(0, 0, 10, 10); Pretty much a wash, though I like the OO style better. It depends on what you mean by "controller". Like in Model-Glue or Mach-II, the circuit.xml file in Fusebox represents a "flow" descriptor. You can embed logic in the XML, of course, but generally it's packaged into either fuses or CFC methods. You end up with XML that looks rather like MG or M-II XML, except that it's explicit invocation instead of implicit invocation. The typical verbs are INCLUDE (include a CFM, usually a view), SET (set a variable or invoke a CFC method), XFA (define an self-referential exit link), and DO (invoke another fuseaction). So your controllers usually end up as either CFMs or CFCs, your views as CFMs, and the XML is used to acquire the data you need to render the view and little else. To sum all that up, if you have a "real" Fusebox app with circuit.xml that looks like that example, you're probably doing it wrong. ;)

And it's worth mentioning that XML is totally optional; you can do everything with convention and/or CFCs anymore.

Regarding Groovy, it's been a while since I've done much raw painting with Java, but from what I recall, it's pretty much identical to what CF provides. The CF functions are relatively thin wrappers, though they smoothed the input/output stuff. So I don't know that it'd be much different, though I do know with Groovy I'd be able to go from my BufferedImage to the output stream without having to use the filesystem like I have to do on CF.

imageDrawLine(img, 0, 0, 10, 10);

versus

g.drawLine(0, 0, 10, 10);

Pretty much a wash, though I like the OO style better.

]]>