cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: CM Thoughts
Date Mon, 11 Jan 2016 13:41:39 GMT
On Tue, Jan 5, 2016 at 5:34 PM, Aristedes Maniatis <ari@maniatis.org> wrote:

> On 5/01/2016 11:58pm, Michael Gentry wrote:
> > - Java Entities
> >     - Class Level:
> >         - Ability to add extra imports.
>
> This seems like something that should go into the velocity templates
> rather than the model.
>

Well, if we are going to support annotations in the modeler (class,
attribute, or relationship), it would be much nicer, at least in my
opinion, to specify the imports for the annotation in the modeler instead
of having to go off and create a custom template whose information is
essentially hidden from the CM viewer/user.




> >         - Ability to add interfaces implemented.
>
> What would be the purpose of adding an interface to the _superclass when
> you need to implement the methods in the subclass?
>

Mainly organizational (keeping everything grouped together).  This isn't a
big one, though.



> > We've also previously chatted a bit about if we even want to keep
> > maintaining the current form of CM.  If we did want to overhaul the
> > implementation, what route should we go?
> >
> > - JFX  (Seems like Oracle's ugly stepchild and I question their
> commitment
> > to it.)
>
> I wouldn't judge it so harshly. I'm slowly moving a project from Swing to
> FX and there seems to be a good amount of support and new functionality
> added in each Java release. Plus it doesn't have to be an all at once
> migration.
>

Last time I glanced at JFX, Oracle required you to build some of the
developer tools (at least Scene Builder) yourself instead of supplying
packages you could download/use.  This screamed of a solid "meh" to me, at
best.  Perhaps this has changed, though.  I admit to not having put a lot
of effort into it, but a couple years ago when I played with JFX/SB a bit
more seriously, it seemed interesting.  The Oracle site still says:

*JavaFX Scene Builder is released under the Oracle BSD License. The source
code is provided and developed through the OpenJFX Project in the OpenJDK
Community. Please consult the OpenJFX Wiki for instructions describing how
to download and build its source code. Please note that the source code for
this application can be found in the "apps/scenebuilder" directory.*


> - SWT
>
> I have no opinion there, but I didn't think that was a framework still in
> active development.
>
> > - Eclipse Plugin (The WOLips route.)
>
> JasperStudio went the same way and it seems to work for them. And I think
> Apache Directory Studio might also be an Eclipse plugin. Being bound to
> someone else's application does seem potentially dangerous (does the plugin
> break with every major release of Eclipse?).  Does it increase the
> difficulty of new people hacking at the code... I think  that should be our
> number one criteria: what's the easiest environment for new people to get
> involved?
>

I think Apache Directory Studio uses SWT.  It looks Eclipsish, but is a
standalone application.


> - Electron (Used by Atom and Visual Studio Code, among others.)
>
> Never played with it.
>

To even realistically consider Electron, this would have to work well in
order to interface to Cayenne JARs:

https://github.com/joeferner/node-java

Nutshell: Electron gives you a way to create platform-specific applications
(like we currently have separate builds for OS X and Windows) running
inside a Chrome shell with Node/JS and you write your application with
HTML/CSS/JS.  It seems to be gaining popularity with some "younger"
developers.


The main reason to even consider a CM rewrite is to upgrade it to more
modern UI frameworks and make it more approachable, both from usability and
developer viewpoints.  Everything else I mentioned can be done in the
current Swing version, but probably some of it would be quite
difficult/cumbersome.


Thanks again,

mrg

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message