Making JavaFX Development Faster
Mark Fortner
phidias51 at gmail.com
Sun Oct 28 09:55:49 PDT 2012
Getting back to the original topic for a sec, one of the things I've
observed with JavaFX is that there are some areas where I think the basic
development workflow aren't being helped by JavaFX, and I think these
problems are eminently solvable. Here's my workflow (the bits in boldface
are the gaps that JavaFX could fill in and make easier):
1. It starts with a spreadsheet. It's the de facto tool that any user
uses to collect data (be they scientists or wizards of wall street). They
show me the analysis that they want to be able to do with that data. I
want to use that spreadsheet as a model for my prototyping work.
2. Create a prototype. I sketch out the result of our conversations,
and use SceneBuilder to quickly put together a prototype. At this point I
want to be able to *bind the spreadsheet to a tableview, or bind a
couple columns to a combobox* so that the users can see real data in the
app. Sometimes we get lucky and the data they asking for is already in the
database, if that's the case we just need to *bind the widgets to
existing RESTful services*.
3. Get approval to create the app.
4. Create POJOs. *Generate forms, controllers, services* (at least for
the server side). It would be really helpful to be able to generate JavaFX
forms, and controllers as well. At a minimum I need to bind controllers to
widgets so that I can populate a comboboxes and charts with values.
5. The remainder of the work revolves around creating and testing the
business logic behind the analysis -- the real work that the user's want
automated.
6. Deploy the app. This last step is critical to us since it allows the
users to give us feedback and do any last minute course correction. It's
also the step that threw us for a loop on our last project, since we didn't
anticipate that a long-standing technology like webstart would have been
broken, and that Oracle would release JREs that continue to be broken.
Unlike the native packaging options, webstart means that we don't have to
contend with users not updating in a timely manner, nor do we have the
manpower to run around to desktops and do the installs ourselves, or use
multiple platform specific tools to push apps to the desktop. One thing
that I would really like to see fixed, is that when we deploy apps
internally, we shouldn't have to jump through all of these hoops to do it.
Why do we have sign other people's jars (or even our own jars) for
internally deployed apps? There are inherently at least three modes for
this kind of deployments (internal, b2c, and b2b). In the latter two cases
I would expect to have to sign apps, but not for internal apps.
I'm sure there are other workflows, and I'd like to learn more about how
other people are doing development.
Regards,
Mark
On Sat, Oct 27, 2012 at 9:28 AM, Tom Schindl <tom.schindl at bestsolution.at>wrote:
> Hi,
>
> I really like JavaFX properties but their concept really only makes
> sense on the client.
>
> Main points:
> * They waste memory
> * are not supported on all JVM (people tend to forget that javafx is
> not JSRed and only part of openjdk/oracle jdk).
>
>
> On memory:
> ----------
> We can talk about laziness as much as we want but when reading a bean
> from the database 95% of the fields are none null, hence lazy creation
> is a nightmare.
>
> In my opinion VM properties are very different to what we have in JavaFX.
>
>
> On standard:
> ------------
> As outlined and confirmed by Richard, Oracle does not guarantee that
> things work on all JVMs (e.g. j9) it might or might not work and can be
> broken any time.
>
> JavaFX will be JSRed by Java9 not sure if vendors are forced to
> implement the started. When you state other JSRed technologies should
> adapt to the JavaFX bean standard the they can before Java9.
>
>
> General statement:
> ------------------
> I'm not even sure why people have such a big problem with using a
> different object on the server (Plain POJO) and Java(FX)-Bean on the
> client, writing POJOs by hand is a boring and senseless task using some
> meta format or tool and generate the POJOs and JavaFX-Beans out of that
> is not rocket sience.
>
> Tom
>
> Am 27.10.12 16:29, schrieb Tom Eugelink:
> > About using JavaFX beans server side; can you explain why that would be
> > a bad idea beside the fact that there isn't any support in frames like
> > JDBC?
> >
> > There has been a big demand from the community for real properties in
> > Java. Now JavaFX has become part of the standard JDK, I expect people to
> > start using these properties in other area's as well. The binding
> > concept is rather powerful and once the concept sinks in... This then
> > would have consequences; some bindings no longer can be lazy, we need
> > bean level listeners, etc. But this can all be added quite easily. Then
> > JDBC and JPA need to be enhanced to support them and we're pretty much
> > done.
> >
> > Tom
> >
> >
> > On 2012-10-27 15:55, Tom Schindl wrote:
> >> If I remember correctly it had to do with listeners and how to manage
> >> that they are not leaked but I could be wrong.
> >>
> >> Anyways nobody guarantees that OpenJFX will run on other vendors JVMs,
> >> am I right? I generally think using JavaFX-Beans on the server side is a
> >> bad idea.
> >>
> >> Tom
> >>
> >> Am 27.10.12 15:24, schrieb Richard Bair:
> >>> I cannot imagine what internal stuff Michael could be using or when
> >>> that was added.
> >>>
> >>> On Oct 26, 2012, at 7:42 AM, Tom Schindl
> >>> <tom.schindl at bestsolution.at> wrote:
> >>>
> >>>> Not only the memory argument is import.
> >>>>
> >>>> What if a customer says i have to run on his j9-jvm?
> >>>>
> >>>> I can be wrong but IIRC Michael told me at JavaOne that the properties
> >>>> code is even using internal (sun....) stuff so even simply dropping in
> >>>> the jar to the j9 classpath is doomed to fail.
> >>>>
> >>>> And beside that using FX-Observables and e.g. JPA don't like each
> other
> >>>> i guess because of all those lazy list stuff, ... .
> >>>>
> >>>> Tom
> >>>>
> >>>> Am 22.10.12 19:23, schrieb Werner Lehmann:
> >>>>> Richard,
> >>>>>
> >>>>> On 22.10.2012 17:38, Richard Bair wrote:
> >>>>>> MyObject obj = new MyObject();
> >>>>>> obj = BlackMagic.makeObservable(obj);
> >>>>> I'd like to see the implementation of BlackMagic ;-) (cglib stuff?)
> >>>>>
> >>>>>> However, the javafx beans package and collections and such are part
> >>>>>> of the "base" module -- ie: they could be separated from the rest of
> >>>>>> javafx and safely used on the server side or elsewhere. Why not just
> >>>>>> use properties and such on the server side definition of classes? Or
> >>>>>> are those classes being auto-generated and thus not taking
> observable
> >>>>>> properties into account?
> >>>>> Currently I want to avoid requiring customers to install the FX
> >>>>> runtime
> >>>>> serverside. That will be a moot point with JRE 7+. Which does not
> help
> >>>>> the 6.x customers, especially if they are on WebLogic which is
> usually
> >>>>> tied to a specific major version.
> >>>>>
> >>>>> Another aspect is the footprint regarding memory and bandwidth.
> >>>>> Obviously a StringProperty requires more bytes than a String. This is
> >>>>> not an issue (usually) when I want to display a relatively short
> >>>>> list of
> >>>>> beans in the UI. It gets noticeable when the server suddenly needs +X
> >>>>> megabytes, the instantion of objects needs +Y ms (also affects
> >>>>> deserialization), and sending them over the network takes +Z ms...
> >>>>>
> >>>>> Werner
> >>>>
> >>>> --
> >>>> 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
> >>
> >
>
>
> --
> 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
>
More information about the openjfx-dev
mailing list