Re: java swing question
On 7/22/2014 9:04 AM, Chris Uppal wrote:
Arne Vajh?j wrote:
* modern GUI design where the layout is done in ML not code.
I am still completely unable to see why anyone thinks this is an advantage.
Yes, I know that practically everyone /does/ think that, but it baffles me.
Why have two code artifacts instead of one, when they are necessarily
intimately connected ?
Why use two languages instead of one ? It's not as if *ML is any /clearer/
than most languages. It may be that Java specifically -- with it's weak
ability to create DSLs within it -- is something of an exception. But even in
that case the solution isn't to shoehorn in one of the least expressive
"notations" every seriously devised !
This is not Java specific.
Examples of the split:
* Java EE
- JSP view + Java controller in original MVC Model 2 [I think
this was before CSS became common]
- JSP view + Java action + CSS styling in Struts 1 and
many other MVC frameworks
- JSP view + Java managed bean + CSS styling in JSF 1
- Facelet view + Java managed bean + CSS styling in JSF 2
* ASP.NET .aspx view + .aspx.cs controls + CSS styling
* Rails .html.erb view + .rb controller & action + CSS styling
* Flex .mxml view + .as action
* WPF .xaml layout + .cs controller
plus numerous other frameworks in various languages.
This shows that:
* the phenomenon is not caused by any missing feature in Java
* a lot of GUI framework designers think it is a good idea
It does not really show that it is a good idea. At least in
theory the majority of GUI framework designers could be wrong.
The design needs two justifications:
* one for why separating layout, action and styling is good
* one for why different languages for each are good
Separating different aspects of applications is a very well-known
technique. In Java we split up code in methods, classes, packages,
layers, source files, deployment units (jar/war/ear/rar). It is
generally accepted that code split up in logical distinct chunks
makes it more readable and easier to maintain. This applies
to classic split in presentation+business logic+data access
and model+view+controller. It also applies to layout+action+styling
in a GUI app. Those are very logical distinct:
* layout = layout of GUI widgets
* action = handling of user actions
* styling = providing common L&F in whole application or group
Actions require imperative logic. An imperative language
Layout and styling are non-imperative and leaning towards a
declarative model. An imperative language like Java is not
very well suited for that. Various experience from web furthermore
shows that different declarative languages for layout and styling
are better than a single languages, because layout and styling also are
fundamentally different. All this should not come as a big surprise. The
idea that a single language is best for everything is wrong. Languages
are typical good for what they were designed for and not so good for
what they were not designed for. So vastly different problems often
require different languages.
PS: There are actually cases where an imperative language is best for
layout and that is if the layout is determined at runtime. But that
is an exception not a typical case.