The Next Great Thing: An Application Framework (original) (raw)
Daniel Zwolenski zonski at googlemail.com
Sat Feb 11 21:59:06 PST 2012
- Previous message: The Next Great Thing: An Application Framework
- Next message: The Next Great Thing: An Application Framework
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: The Next Great Thing: An Application Framework
- Next message: The Next Great Thing: An Application Framework
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]