The Next Great Thing: An Application Framework

[Daniel Zwolenski]

The things I feel are needed for an application framework are the features
I am putting into JFX Flow <http://www.zenjava.com/jfx-flow/>, but this is
targeted towards web-style, online, form-based business apps.

My feeling is that we are better off if JFX just provides a core library
with fundamental building blocks, rather than trying to provide a full
application framework that forces a specific architecture. People build all
sorts of applications, with all sorts of wonderful architectures, and no
App framework can cater to all. For example, the application framework
needed for an online, form-based business style app vs a desktop, offline
app (e.g. an IDE or graphics drawing program) are significantly different.

For my money we are much better off keeping these application frameworks as
separate, open source, free, community managed projects. We can then have a
few key ones that cater to the major flavours of apps. This also decouples
the frameworks from the JFX release cycles, and allows them to make use of
other open source projects (such as Validation frameworks, Apache commons,
Spring, Guice, logging, remoting toolkits, etc), which the core JFX library
cannot do.

This approach has worked well in web land. You have the official servlet
infrastructure as part of the core JEE library and then on top of this
people have built frameworks like SpringMVC, Struts, GWT, Seam, etc. People
can choose the framework that best solves their needs. As framework
builders have come up with new ways to do things, the servlet spec has
gradually, and carefully, evolved to support these things. The application
frameworks on the other hand have been totally rewritten, thrown away and
redone to account for new ways of doing things, new styles, new
understandings (e.g. Struts != Struts2, GWT2 is a major change from GWT1,
and HTML5 is a game changer for most of these frameworks).

So in my mind there are two topics for discussion:

1. What are the flavours of applications that people will want to use JFX
to build, and what open source projects should we create to provide for
these and what features should they contain? Who's keen to do this work and
can we get a collaborative community effort going on this front (I'd be
more than happy to get more community involvement on Flow and if someone
has a better way of doing things, I'd also happily merge efforts).

2. Based on the discussions from #1 what are the core elements that JFX
needs to provide in order to support these frameworks and features? What
fundamental building blocks need to be fixed/improved or need to be added?

I feel like a lot of the points you've raised in your email are
good contributions to the second topic, but there are a few that for me
should not be part of JFX and instead should be part of extension libraries:

- Eventbus (there are a hundred different ways these can be implemented and
plenty of app architectures that don't use them)
- Application environment (not exactly sure what this means but it sounds
architecture specific?)
- Application controls (as above)
- Application naviagtion (as above)
- Automatic application state saves (there is generally a lot of business
logic associated with this, not JFX's domain in my opinion)
- Automatic document saves (as above only more so)
- Actions / Actions manager (these were not applicable in Swing for a MVP,
browser style architecture, they solve only a subset of architectural
problems, e.g. undo when using remoting)
- A superpowered decendant of the Swing AbstractAction class &
Action interface (as above).
- Conditional state actions (Ex. If the "control" key is depressed then
an alternate action is made visible or the text of a menu item might
change). - (as above)
- Toggle actions (Ex. bold/un-bold or hide/show) - (as above)
- Multi-state actions (as above)
- Inter-application communication (this is a Java issue, not a JFX issue.
It could be a JSR for inclusion in the Java platform or just a separate
library, it is not part of a GUI framework)
- Allow apps to communicate to each other using a common architecture (as
above)


I think also that a lot of the things people require (and hopefully most of
the things you listed), should already be in JIRA and if not, should be
added to JIRA. I do wonder how the JFX team choose the issues to be
fixed/worked on? I don't believe much notice is taken of the voting system,
perhaps it should be used more solidly, to allow the community to drive the
feature sets they see as important? It would be great if there was a bit of
love put into the JIRA setup to define some filters for the following:

1. Listing issues in order of votes (highest to lowest)
2. Listing issues for the next releases/milestones

It would be really great if actual dates were put into JIRA for
release/milestones so we could see a roadmap of what's being done when and
when releases are due. It is not obvious to me (and I am fairly active in
the whole thing) which releases are happening when, what features are in
which - all I really know is 'lombard' means 'not any time soon mate' and
everything else could happen sometime in the next year or two. It's all a
bit confusing and vague.

One final comment, the absolute fundamental issue that affects all
platforms and for me is of such critical importance (it is the weakness
that hamstrung Swing), is the whole deployment issue. This needs to be
clean, smooth, simple. I can't emphasize this one enough. I feel like we're
going to lose the battle to HTML5 if we don't address this issue up front
and quickly (like in the next couple of months). I don't want JFX to spend
the next 10 years playing second fiddle to crappy web-apps, like Swing has
had to. Please don't make me write more JavaScript.



On Thu, Feb 9, 2012 at 3:36 PM, Jeff McDonald <deep.blue.6802 at gmail.com>wrote:

> Now that JavaFX is delivering on it's promise of delivering the components
> and pieces need to make an application, it's a perfect time to take a
> higher level look at what's needed to make a complete application.
>
> Here is your chance to add your ideas, comments, criticisms, insights,etc,
> and say what's on your mind. I don't work for Oracle nor do I speak for
> Oracle, however, the JavaFX team has shown great interest in listening to
> developers and delivering what's important to the developer community.
> Having an application frameworks integrated into the JavaFX library would
> be a huge advantage to Java developers.
>
> Below is a simple bullet list of ideas and features that could be useful to
> application developers:
>
> - Application types to consider:
> - Desktop
> - Tablet
> - Phone
> - Command line
> - TV
>  - Set-top box / Bluray player
> - Service or daemon
>
> - Application tooling needs?
>
> - Application level / lifecycle events
> - Exit event (From JSR 296)
>  - Shutdown event  (From JSR 296)
> - Sleep event
> - Pause event
>  - Show help window event
> - Show help hints (ala Apple style help)
> - Eventbus: allow any component to send message and listen to messages from
> any other component. Message consumers only have to listen to events and
> are not required to have references to any other objects (other than the
> eventbus) in order to receive event notices.
>  - Screen resolution change event
> - Monitor added / removed events
> - Screen orientation change event
>  - Full screen mode / normal screen mode.
> - App dock icon menu event / taskbar menu event / start menu event.
>  - Application environment
> - Supports 3D?
> - Supports hardware acceleration?
>  - LCD text supported?
> - Bidi text supported?
> - Supports full screen mode
>  - Supports App menubar?
> - Supports dock?
> - Supports taskbar?
>  - Application controls
> - App menubar (setter & getter) (The application level is really where the
> Application menubar should be handled, and not on the Stage/Window level.)
> - App taskbar
> - App dock
>        - Set application name (This is app name, not stage or window name.
> Could be set to display Scene name when focus changes or to show static
> text.)
> - App dock icon menu / taskbar menu / start menu.
>
> - Application naviagtion
> - Get window (by id)
> - Bring window to front
>  - Send window to back
> - Move window to location
> - Expose for FX stages to aid in navigating and organizing multiple windows
> (MacOS style functionality see: YouTube : MacOS X Expose
> Video<http://www.youtube.com/watch?v=fhcqxDIfG-o&feature=related>
> )
>  - Application focus
> - Get current focused window
> - Get current focused component
>  - Application state / session management
> - Save & restore window size & location
>  - Automatic application state saves
> - Automatic document saves.
>  - Actions / Actions manager
> - A superpowered decendant of the Swing AbstractAction class & Action
> interface.
> - Conditional state actions (Ex. If the "control" key is depressed then an
> alternate action is made visible or the text of a menu item might change).
>  - Toggle actions (Ex. bold/un-bold or hide/show)
> - Multi-state actions
>  - Application print support?
>
> - Inter-application communication
> - Allow apps to communicate to each other using a common architecture.
>