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? (Or will Oracle be making the "if we worked on it, it's ours" mistake (again)? (Hudson, open office) Because that usually backfires.)

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.
>>