An FXML Browser (topic branched from Re: High performance text component)

[Greg Brown]

Ah, OK. Thanks for clarifying.

Just to be clear, script code in FXML is not required to be inline. In fact, the preferred approach is to keep script and FXML separate (e.g. place script code in external .js, .groovy, or whatever files). Inline script tends to create markup that is more difficult to read and maintain, among other disadvantages. Externally-defined script can be delivered dynamically just like inline script, but doesn't suffer from the other problems associated with inline code.

Greg


> When I started at NeXT, we had this wonderful "Display Postscript" that turned out to be problematic. I think PostScript itself was a problem for Adobe, since it was both a page description format and a programming language. People could do very clever things with it, but it was hard to add simple PostScript support to an app (or a new device) without including a runtime that could dwarf the host app. Both Adobe and Apple have since moved to a PDF model, which is a concise version of PostScript, without the language constructs.
> 
> Datapoint 2 would be JavaFX 1.0. Very cool language that totally mixed graphics description with application logic. It made it hard to write an JavaFX editor that didn't also know a bit about programming language constructs. Thankfully we now have FXML.
> 
> I'm sure a lot of people think HTML with embedded JavaScript is beautiful, so I won't touch that. :-)
> 
> Jeff Martin
> 
> 
> On Sep 4, 2012, at 10:08 AM, Greg Brown wrote:
> 
>>> I'm a big believer in the separation of presentation and logic
>> 
>> This is probably a bit off-topic for the thread (as well as the list), but I've always been an advocate of separating "presentation and data", which has some well-known and clear benefits. I'm not sure what advantage you might derive from trying to separate presentation from logic (at least, logic that is associated with the presentation), but maybe I misunderstand the intent.
>> 
>> G