The Next Great Thing: An Application Framework

Tue Feb 14 02:26:31 PST 2012

I think the below was intended for the discussion forum as a whole but came
direct to me so I'm resending. I will respond with comments in a separate
email.

On Tue, Feb 14, 2012 at 5:54 AM, Jeff McDonald <deep.blue.6802 at gmail.com>wrote:

> Some of the conversation is clouded by the vague meaning of an
> "Application Framework." Dumping something like Eclipse or Netbeans into
> JavaFX is like bringing a nuke to a spit wad fight. Maybe by giving the
> project a different name might help avoid some of the confusion ... how
> about calling it an "app kernel." Honestly, the name isn't that important,
> but the term is more descriptive. What an app kernel should be is a small
> layer that sits between the world outside of the app and all of the
> components inside the app. Another descriptive name could be "Application
> toolkit."
>
> Interestingly, the app framework discussion came about as a discussion
> Richard and I were having about the Application menubar. In JavaFX 2.1 the
> way to set an application menubar is to call some method such as
> "useApplicationMenuBar(boolean)" then, magically the menu from the focused
> window show up in the Application menbar. This design opens the door to
> lots of inconsistent behavior. For instance, if each menubar has an "open
> file" menu item then duplicate code might be required or the code could be
> centralized, but if the action requires a knowledge of of which component
> (or selected item) has focus then the solution becomes more complex. In
> short it makes development much easier when there is something above the
> window level to both unify window to window interactions as well as OS to
> application interactions.
>
> I am willing to put code and time into an app framework as well.
>
> Here are some of the core level things that would make for a compact
> efficient App Kernel:
> 1. Provide a single point of abstraction for window to window interactions
> 2. Handling application targeted events.Receive and send OS to application
> events / messages
> 3. Provide application context information. A single point of access to
> query and interact with settings and environment information. Some of the
> information would be architecture specific, but not limited to such
> information. For instance, calling getRenderingPipleline() would return the
> rendering engine that JavaFX is using. That choice is made at runtime and
> based on other native and non-native conditions.
> 4. Provide commonly used functionality to simplify application development
> and promote basic greater consistency for
> standard application functionality.
>
> Random thoughts about aplication level events:
> - Component targeted events are already handled by JavaFX, however, there
> is no means of handling application targeted events such as a "Quit"
> command that is issued through the OS. You can call it an eventbus, or
> messagebus, or an App.handleEvent(Event) singleton or whatever):
>  1. Windows, macOS, iOS, and Android support them for handling system
> calls for closing down an App, opening documents, going into hybernation.
> Those are events that are already in the OS's. Can you write your own code
> to handle this? Yes, but that's like saying there's no need for adding XML
> parsing because Java already handles strings.
>  2. How does a developer "quit" and application? Is it when you close a
> window? In a single window environment on the Windows platform it
> (typically) means quit. On the Mac it means dismiss the window, but the app
> is still alive (oops ... no calls to System.exit() on WindowClosed event if
> you want to be Mac friendly). In a multi-window environment it could mean
> many things. On a mobile platform moving to a new window (or rather a page)
> means just changing context. On a mobile device the "quit" action or event
> comes from pressing a physical button on the device. Where is the support
> for "quit" in JavaFX?
>         3. ScreenOrientationChangeddEvent - This is an application level
> event that should be handled above the window level.
>
> On Sat, Feb 11, 2012 at 10:59 PM, Daniel Zwolenski <zonski at googlemail.com>wrote:
>
>> I like all the thinking on this front and the different initiatives (and
>> the enthusiasm). I think there is a lot of room for us to exchange ideas
>> (and code!) and either make sure each of the platforms is doing something
>> unique, or merge efforts if they are not. One of my fundamental goals
>> however is to not tie a developer into a specific development
>> toolset/environment as much as possible (as a developer I hate it when I
>> can't use my tools, so I try to make it so everyone else can use their
>> weapon of choice too), so the frameworks based around Eclipse (or any
>> specific IDE) are unfortunately not of direct appeal to me.
>>
>> Having said that, I'd love to keep abreast of the features being added,
>> how
>> they are being implemented, architectural patterns and motivations,
>> etc. Perhaps there is even room for a project like JFXtras to become a
>> spot
>> for us to put common toolkits that our frameworks can all share, rather
>> than each of us reinventing wheels. If there is anything in JFX Flow that
>> people would like to use in their toollkits, let me know and we'll see if
>> we can section stuff off. Likewise I will look through your frameworks as
>> much as time allows and see what overlaps (e.g. maybe we could all work on
>> a form validation framework together that our application frameworks then
>> share and add to, etc).
>>
>> Richard, on the topic of what the JFX platform should/shouldn't include,
>> can I add another way of thinking into the mix for you to mull over:
>> although there is a strong case for keeping the JFX platform as the 'core'
>> library, just because other modules/elements are not part of the 'core'
>> doesn't mean that Oracle can't produce them, sponsor them, contribute to
>> them, etc. It would be great to see Oracle champion initiatives on each of
>> the logical extension fronts (full app frameworks, game platforms,
>> form/wizard frameworks, navigation/event-bus libraries, high-level
>> animation libraries, PDF/doc browsing/editing, voice/video conferencing,
>> etc). This approach would achieve the goal of getting all these needed
>> value-add frameworks built in a consistent, 'official' way, but would
>> remove the restrictions implied by a core framework (e.g. can't use 3rd
>> party, tied to core release timeline, legal issues, etc). Also the cost to
>> Oracle would be massively reduced, allowing them to achieve far more with
>> limited resources. If Oracle is driving initiatives they can still keep
>> their brand on it - Google uses a similar approach and it only adds to
>> their brand and their platform (see http://code.google.com/).
>>
>> In some (few) cases this could be in the form of Oracle putting together
>> it's own closed team (like the JFX team is now) on a project if Oracle
>> feels that area is of critical importance/urgency to the JFX platform. My
>> preference however would be for Oracle to instead either lead or support
>> open source community efforts. Perhaps by providing a project lead for it
>> and getting members of the community to sign up and join in (perhaps even
>> sponsoring some community developers - like a 'key contributors' model or
>> something).
>>
>> Alternatively (or as well) it would be awesome if Oracle had an internal,
>> dedicated team of 'community supporters' who's full time job it is to
>> assist community projects that Oracle sees as value add to the platform.
>> This team would help guide/support projects that look to add value to the
>> JFX platform, possibly by providing direct development resources, or
>> otherwise by providing publicity, official 'sanctioning',
>> infrastructure/hosting support, and communication links to funnel requests
>> back to the JFX team for core support/enhancements, etc. Additionally this
>> team could also help identify duplicate efforts and try and foster/guide
>> collaboration and effort-merging to limit the number of similar
>> initiatives
>> (for us garage developers working out how to collaborate is a lot harder
>> than it sounds, and having a trusted third-party assist with this would be
>> useful).
>>
>> In a better world, the java.net developers site would be the ideal
>> infrastructure for these sorts of projects, but unfortunately (in my
>> opinion at least) it is a dog's breakfast of a system with a horribly
>> unusable UI, outdated/limited features and poor performance. I've tried to
>> use it in the past and found it too painful and ended up switching to
>> google code. If some energy were to be expended on making java.net more
>> like a modern day collaboration suite (the Atlassian toolset for example)
>> then this could be the perfect platform for this sort of community effort,
>> all to the mutual benefit of Oracle and the JavaFX community as a whole.
>> Win-win.
>>
>> For what it's worth, I would volunteer what spare time I could find to
>> work
>> with guys on your end to make something like this a reality.
>>
>>
>>
>> On Sat, Feb 11, 2012 at 8:55 AM, Tom Schindl <tom.schindl at bestsolution.at
>> >wrote:
>>
>> > In my thinking is an IDE is simply a large large RCP-Application?
>> >
>> > In this sense like you as an die hard Eclipse users I've started
>> > developing an RCP framework built on top if Eclipse 4 Application
>> > Platform which provides the completely new runtime layer the Eclipse 4.x
>> > IDE is built upon.
>> >
>> > The key things are:
>> > * extensibility by using OSGi
>> > * event bus built on OSGi Event Admin
>> > * service architectur built on OSGi
>> > * theming via CSS
>> > * programming model based upon JSR 330 (javax.inject)
>> > * DOM like Application Model providing clean seperation between
>> >  application state and rendered UI
>> > * commands/handler framework
>> >
>> > Kai Tödter is also doing work in this area (he also builds on the
>> > Eclipse 4 Application Platform) and has published nice screenshots of
>> > applications [1].
>> >
>> > I'm currently working on a demo application which we'll demonstrate at
>> > Eclipse Con North America in March showing how a collabrative
>> > application can be built using the Eclipse 4 Application Platform and
>> > JavaFX (because it's at EclipseCon we'll even mix SWT into the game but
>> > that's a minor thing) [2].
>> >
>> > Coming back to my above assumption that an IDE is nothing more than a
>> > big RCP application - the RCP the framework built by us - can easily be
>> > expanded to an IDE e.g. by mixin in other Eclipse technologies like e.g.
>> > JDT-Core, Xtext for DSLs, ... .
>> >
>> > I think the important thing for efx and the e(fx)clipse runtime
>> > platforms is that they build upon hardened frameworks because other big
>> > products (Netbeans and Eclipse) are built upon them.
>> >
>> > This makes those 2 frameworks share resources with others (e.g.
>> > e(fx)clipse runtime platform currently has around 20 classes and
>> > supports all important UI paradigms starting from menus to toolbars to
>> > tabs) while inheriting all other features from the framework developed
>> > at Eclipse.
>> >
>> > BTW if you are not happy with the UI-Paradigms currently defined in the
>> > Eclipse 4 Application Platform you are able to expand and mix in your
>> owns.
>> >
>> > All our sources are provided under EPL [3].
>> >
>> > Tom
>> >
>> > [1] http://www.toedter.com/blog/?p=709
>> > [2]
>> >
>> >
>> http://www.eclipsecon.org/2012/sessions/eclipse-4-meets-cdo-now-you-see-it-and-so-do-they
>> > [3] http://github.com/tomsontom/e-fx-clipse
>> >
>> > Am 10.02.12 22:00, schrieb Sven Reimers:
>> > > Seems there is more than one approach out there for getting a JavaFX
>> RCP
>> > in
>> > > shape. As a die hard NetBeans RCP user I started an open source
>> > > java.netproject called efx, which tries to reuse a lot of the NetBeans
>> > > RCP pattern
>> > > while getting rid of the Swing UI.
>> > >
>> > > So the focus is more on RCP not on an IDE or something similiar, but
>> with
>> > > first class support for development of such RCP based applications..
>> > >
>> > > Sven
>> > > Am 10.02.2012 21:35 schrieb "Richard Bair" <richard.bair at oracle.com>:
>> >
>> >
>> > --
>> > B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
>> > ------------------------------------------------------------------------
>> > tom schindl                 geschäftsführer/CEO
>> > ------------------------------------------------------------------------
>> > eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512
>> 935833
>> > http://www.BestSolution.at                      phone    ++43 512
>> 935834
>> >
>>
>
>