The Next Great Thing: An Application Framework

[Tom Eugelink]

I agree with that Oracle's JFX team will want JFX to be self contained and thus not use existing libraries. And that will be a big drawback for any such library. Placing it outside the core JFX does not have to limit Oracle's JFX developers to assist in the development, does it?

Tom




On 2012-02-10 00:36, Daniel Zwolenski wrote:
> 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.
>>