On Tue, Jan 5, 2016 at 4:35 PM Aristedes Maniatis <a...@maniatis.org> wrote:
> On 5/01/2016 11:58pm, Michael Gentry wrote: > > Hi, > > > > I'd like to start a conversation about future improvements for CM. > > Cool! > > > > My current wish list: > > > > - Java Entities > > - Class Level: > > - Ability to add extra imports. > > This seems like something that should go into the velocity templates > rather than the model. > > > - 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? > > > - Ability to add JavaDoc. > > https://issues.apache.org/jira/browse/CAY-400 is the beginning of this > concept. I put some time into it ages ago. And then I used it as a test > when hiring a couple of new developers. Bad sadly I never went back to tidy > it all up and get it finished. > > > > - Ability to add annotations. > > Yes, that would be cool. > > > > - Attribute Level: > > - Ability to add JavaDoc. > > - Ability to add annotations. > > - Relationship Level: > > - Ability to add JavaDoc. > > - Ability to add annotations. > > - Ability to drill-down through relationships.* > > That would be really useful. > > > > - DB Entities > > - Table Level: > > - Ability to add comments (for DBs that support comments). > > - Column Level: > > - Ability to add comments (for DBs that support comments). > > - Relationship Level: > > - Ability to add comments (for DBs that support comments). > > I think that's https://issues.apache.org/jira/browse/CAY-400 again. > > > > - Ability to drill-down through relationships.* > > > > * Llike EOModeler, in the left-hand navigation pane. You could keep > > expanding the relationship tree to expose other entities/relationships. > > > > > > 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? > Unless someone is committing to do all the work I doubt this is really feasible. But it's ok to dream. What is there to gain in switching platforms? > > > > - 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. > I don't think JavaFX is going to disappear, but it's not gaining popularity or usage either. But the fact that it integrates with swing makes it possible migrate slowly, which is a big benefit. Still, what is to gain? > > > - SWT > > I have no opinion there, but I didn't think that was a framework still in > active development. > SWT is the UI framework that powers eclipse. It gives you platform-native widgets, so the appearance and interaction is top-notch and feels native. SWT isn't widely used outside eclipse, but it is very much alive. Also there is a web-based version of the same API that can be used to turn your java app into a native-web app; however, this is even less widely used. > > - 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? > This is similar to SWT, but with more on top. Since there is already a prototype of CayenneModeler in eclipse this would be a realistic path. But are there gains that are worth it? > > > > - Electron (Used by Atom and Visual Studio Code, among others.) > > Never played with it. > Electron is the shell for the Chrome web browser. It allows you to package a web app as a native application (like Chrome). It allows you to develop your app using web technologies (HTML/CSS/Javascript) which could be very productive. But I'm not convinced that's a plus even though I like the platform. > > > Your thoughts greatly appreciated! > > To my mind, there is only a small gain in moving away from Swing and quite > a bit of work. But if you had the time to put into it, JavaFX is most > likely to survive another 15 years from the options you give above. > > > Ari > > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
