0 votes

ORM Designer2 becomes more stable and better by every release. Although we have still several things to improve (nicer application icon, weird font on license screen,..) we would like to hear your opinion what to implement next.

Currently we're working on annotiations. It is definitely the most required function since we've released Doctrine2 support first time. We expect to have first public results during next week, but don't want to promise it because there are still few challenges awaiting.

We also want to know how many of you uses Propel or CakePHP. Based on feedback we're receiving it looks like that most of users are Doctrine2 and Doctrine programmers.

Please help us to prioritize feature development in ORM Designer2. Shall we implement CakePHP support, Propel support, Print or PDF export as first? And what next?

Do you have some ideas for a new feature? Share it with us!

asked in Information by (1.1k points)
recategorized by

3 Answers

0 votes
Best answer

Based on twitter and email feedback we're now working on Propel ORM support.

This is our now priority list:

  • PropelORM
  • Doctrine2 annotations
  • Print/PDF
answered by (1.1k points)
selected by

I don't care for Propel, but the rest of the list is fine with me! PDF or Print is really the same (as long as it's vector based), as pointed out by pbowyer.

We have plans to implement PDF and Print driver as well as it is implemented in ORMD1. The only exception is the use of native Qt PDF library instead of buggy HaruPDF.

PDF export implemented in version 2.1.4.655. http://support.orm-designer.com/31/download-orm-designer2-beta-here

0 votes

Once importing bundles with annotations is completed (so I can import the object structure from FOSUserBundle for example, or Symfony's ACL), I need some way to export the diagrams to share with management and discuss with other architects.

I don't mind if it's print or PDF (both lead to the same point as far as I'm concerned - I have a PDF creator installed on my system).

I'm only using D2 FWIW

answered by (1.1k points)

Thank you for answer. PDF and Print export will come right after annotations, because it's highly requested feature.

0 votes

Hi guys!

I would like to maybe introduce a new feature that hasn't been discussed much. It's basically a rip of something they do in MySQL Workbench, but it would be a very cool feature for ORMDesigner to have: the implementation of multi-diagram support (am I missing this as an already implemented feature?).

I bring this up because working on an enterprise level application, there might be 80-100 tables (at least) to cover all the scenarios.. I'm up to 25 and I haven't even touched on most of my requirements. Anyways, the ability to break some of these areas down into smaller chunks helps to keep focus on particular ideas within the overall schema.... for example I have a 'config' table that has a FK in most every table in the database... I don't want to have to see 40 different relationships surrounding the table when I'm working on the e-commerce portion only.

The way MySQL Workbench does it lets me create a diagram with just the tables and relationships I want to see at that time... for the e-commerce example I can limit the display to the tables that are only related to the e-commerce system.

Forgive me if this is just a feature that I didn't notice yet. I do know that there is module/bundle support though, but that's not really what I'm talking about because so many of the tables in my system have relationships to entities outside of their bundle.

Fellow beta testers, your input here would be appreciated, too! :)

Thanks, Geoff

answered by (1.1k points)

You can organize your model into modules. What's missing now is only a feature to hide other modules and their connections. We have a huge model in one of our projects as well and what I do with tables like Language (i18n-heavy application) and Status, I select "Split associations" on them to make the model not look like a motherboard circuit diagram.

Our original plan was to implement some kind of multi view model support. Unfortunately because of time pressure and because we were not exactly sure what would be the best way how to implement this feature, we have omited it and implemented only the basic model view like in ORMD1. We want to implement this feature later. Now we would like to discuss the best way how to make this feature friendly and effective for users.