First look at JetBrains Visual Fabrique


News: First look at JetBrains Visual Fabrique

  1. First look at JetBrains Visual Fabrique (16 messages)

    JetBrains murmured about the fact that they were working on a web UI tool. Visual Fabrique is that tool, and they put up a page that explains a little about it. There are various parts to Fabrique: core frameworks, active libraries, and tools themselves. This seems like a direct competitor to JavaServer Faces (as well as other web frameworks).

    See more at:

    JetBrains also opened up their new personal information management tool, code named "OmniaMea", to their early access program.

    "OmniaMea is a Personal Information Management tool that provides one convenient environment for working with email, instant messages, newsgroups, bookmarks, RSS feeds, local files and contact lists. With OmniaMea you can browse all information resources, use full-text search and organize everything according to your needs, tasks or habits."

    I like the "WorkSpaces" element, where blogs, email, newsgroup, contacts, ... about a certain topic can appear in one view. This sounds a bit like Chandler

    View more about OmniaMea

    Threaded Messages (16)

  2. I hardly understand Jetbrains plans, these days. "With the help of Fabrique, the deployment of web applications to a variety of supported platforms is transparent and smooth.": wouldn't it be better thinking about providing the same feature for IDEA, before planning a new product? They've already built a controversial GUI builder with a proprietary XUL engine built-in (which very few people use and spreads a bad reputation about the feature and IDEA itself), are they going to produce a controversial web-gui builder on a proprietary web framework ignoring that there are a lot of mature open source projects they could base the development on? Are they going to ignore JSF? I don't know: in the meanwhile I've subscribed for the EAP start notification. ( :) ) I really hope they will put a little more effort in IDEA and work in order to keep it on par with eclipse (especially plugins, application server support, etc.), but I'm afraid all those new software products really mean that they are going to give up the "battle" against eclipse, and abandon IDEA soon. :/
  3. Strategy[ Go to top ]

    Maybe their strategy is to lock their customers into their proprietary solutions. I don't know. But as you say, it's the second time I get this impression after their Idea GUI builder. It also reminded me a bit of Apple's Webobjects.
  4. Ease up on the GUI Builder Bashing[ Go to top ]

    I've been implementing Swing UIs for about as long as they have existed and I have used lots of solutions. JBuilder, VisualAge, Netbeans, Jelly, hand coding, and now my own framework. I loved NetBeans implementation the best for the longest time, but the code it produced was terrible. It got really bad the more you used its powerful features.

    Idea takes the minimalist approach and I admit it is designed for experience Swing/Java developers. Its made for the guys who know the names of all the event listners, models /adapters, and other features found in other GUI builders because it does none of that by default. The only thing that takes a long time and can't be coded elegantly by hand is laying the darn form out. Form layout involves a lot of experimentation which is fundamentally different than coding up an implementation you have mapped out in your mind's eye. I personally want to see how the real components behave and not use paper.

    Idea's solution is digital paper. The layout manager is very natural and I'm very productive because of it. The best thing is that you are not tied to idea at all. The binding class is all your gui/business logic minus a private layout method which initializes all the UI components and lays them out. You can even layout the components by hand after you have shown your boss a demo using simple JTextField everywhere instead of JFormattedblahblah.
  5. Ease up on the GUI Builder Bashing[ Go to top ]

    Take a look at the documentation of the option "Generate GUI into" at

    Especially at the IMPORTANT notice. That doesn't look like "The best thing is that you are not tied to idea at all". In fact it looks like it's a one way solution where GUI design should be done in IDEA and any changes should be done in IDEA (although results can be imported in other IDEs but not easily changed). But if you use IDEA maybe you could tell us how I can start a layout in IDEA, export it to Eclipse, change it in Eclipse and then reimport it in IDEA? Is the .form format and API documented well enough for hand coding?

    The other issue: Why do you prototype GUIs at the computer? I use paper prototyping + JGOODIES forms layout. Paper prototypes are much quicker to do than any GUI builder clicking orgies.
  6. Why would you something that strange? Wouldn't IDEA alone, or Eclipse alone be well enough? How many teams have you seen that work on the same component using different IDEs?
  7. Design in IDEA, import into Eclipse?[ Go to top ]

    That viewpoint is a bit naive. Coding is but one stage of software development; maintenance is an equally big issue. And that's where being locked into proprietary frameworks may hurt a lot. At my workplace, a lot of GUI development was done early on in JBuilder (ver 3 at the time). Nobody uses JBuilder 3 anymore and most of us don't use JBuilder at all, but because the results of their GUI builder was close to standard swing code, it's easy enough to understand and modify, and for most small changes it's not necessary to fire up the GUI builder.

    Even forgetting the maintenance aspect, it's equally naive to expect all developers to use the same IDE these days. Again, JBuilder is the officially supported IDE at my workplace, but the developers basically use the IDE they like. With higher productivity in IDEs that are freely available, why would they not?

  8. Design in IDEA, import into Eclipse?[ Go to top ]

    Hi Sumit,

    I can only agree with you. Not so long ago we had a currency change in Europe. There were quite a few cases where the GUI had to be changed because of this. Changes in the GUI happen quite often during the maintenance of an application, e.g. changing legal requirements, changing customer wishes, changing customer environments/joint ventures...
  9. Fabrique, IDEA GUI, come on folks![ Go to top ]

    Interesting reading, never seen most of the people complaining about the GUI builder in EAP, complaining about the GUI builder's "downfalls". Some comments made are innacurate, and of course with anything new and radical, comes controversy. Some comments make it seem like they looked at the gui builder in its infancy.

    Here's what it's like to work with it:

    I don't know that Fabrique is a competitor to JSF. JSF is not a product, rather a standard by which to write mvc-based web apps. JSF provides the things both Struts and Spring Framework do (Actions, Controller, Error handling etc...), and these existed way before JSF. Struts supports JSF extensions, not sure about Spring.

    As to the comment about JetBrains wanting to lock their customers into their products... well... DUHHHH! We use the product because we like to be dependant on it, we like using it because it somehow improves our processes over other products, and because of that, none of use would view this as being LOCKED into a product. If you feel you're being locked, then you have a need for something else.

    Is Fabrique a competitor to Struts or Spring framework, I think so, and so what? Yeah Struts and Spring are free and Open Source, Fabrique is not, but we don't know how much Fabrique will cost, and how much it will do. You really thing it's fair to judge a product before it's released? Spring documentation not withstanding, I think having documentation and support alone might be worth the price of admission, if they are up to par or better than the others feature-wise, when it's released.

  10. Fabrique, IDEA GUI, come on folks![ Go to top ]

    Once again, this is somewhat naive, and focusses too much on the present. Things change with time. Who knows 3 years down the line what shape IDEA's GUI Builder would take, or even if IDEA would still be as compelling a buy then, or if you would be forced to upgrade in order to use this functionality in a meaningful way.

    Nevertheless, I view JetBrains' move to be the shape of things to come, and I feel a declarative way to build GUIs a la XAML is going to find its way into core java.
  11. Naivety versus ignorance[ Go to top ]

    It's one thing to be naive about using an IDE vendor's customized extensions to build GUIs, thus creating a dependency on the vendor. It's another thing altogether to be totally ignorant about what it is that a product does.

    The IDEA GUI Builder doesn't lock you into a dependency on any custom JetBrains GUI libraries. They have developed an XML layout file that is used by the editor to define a GUI layout within it. The GUI source code can be generated based on this file without any dependency on IDEA or JetBrains libraries. The GUI Builder is simply a tool that eases the development of a Swing/AWT GUI. Expecting the IDEA .form layout file to be portable to other IDEs is like expecting Eclipse to use JBuilder project files, or Windows OSs to use linux/unix .rc files.

    As for Visual Fabrique, I have no experience with or indepth knowledge of it, so I can't comment on whether, or to what degree, the product is based on vendor lock. However, if you want to talk about vendor lock, let's talk about Microsoft Longhorn XAML. Perhaps you meant XUL? Or maybe you'd be more comfortable over in

  12. Naivety versus ignorance[ Go to top ]

    I know; and I am not arguing against the IDEA GUI Builder. I myself am not completely aware of how the IDEA GUI Builder works. But in their demo I didn't see a code-generation step; so I'm assuming that some IDEA libraries do have to be shipped to parse the .form. I may be horribly wrong there. Anyway, to be able to open the GUIs again in the GUI builder, you have to check in the .form as well, and you're basically giving up on code generation even if it's available. That's lock-in all right.

    Such GUI builders may make perfect sense to some projects, particularly new and GUI-centric ones. But the ease of maintaining GUIs not built using a proprietary
    builder will influence decisions in some places.

    The fact that JBuilder resources are not interoperable with IDEA .forms and so forth is unfortunate rather than impossible. The fact that even Netbeans has to use .form resource files, and the competition from MS's XAML, makes me think Java too might move to a declarative GUI building process. There's a reason the intelligent guys at JetBrains, NetBeans and numerous smaller projects are deciding that pure Java doesn't cut it for easy, maintenable GUI construction.
  13. Judge for yourself![ Go to top ]

    Judge for yourself.

    I'll paste a few lines of code generated with IDEA:

    GUI initializer generated by IntelliJ IDEA GUI Designer
     * Method generated by IntelliJ IDEA GUI Designer
     * >>> IMPORTANT!! < * DO NOT edit this method OR call it in your code!
    final JPanel _1;
    _5 = new JPanel();
    _5.setLayout(new com.intellij.uiDesigner.core.GridLayoutManager(3, 2, new java.awt.Insets(0, 0, 0, 0), -1, -1));
    _1.add(_5, new com.intellij.uiDesigner.core.GridConstraints(0, 0, 1, 2, 0, 3, 3, 3, null, null, null));

    As anyone can see the UI-Manager uses non-standard classes (com.intellij.uiDesigner...). Generation of source code happens optionally at make time from the XML specification of the user interface in the .form file (by default only binary .class files are generated).
  14. Judge for yourself![ Go to top ]

    Please replace "UI Manager" with "GUI Designer".
  15. Judge for yourself![ Go to top ]

    as an alternative, iv seen and tried a plugin for IDEA 4 that generates code which uses GridBagLayout instead of the "com.intellij.uiDesigner.core.GridLayoutManager". Its in early development but can now be used for generating codes. In my opinion, Forms, like VB forms, should not be mixed your code. IDEA made it easier for developers, but purists are whining to death. you can still code you UI by hand OR switch to JBuilder (hehe)
  16. I plead "No Contest"[ Go to top ]

    Anybody got a towel? I've got an awful lot of egg on my face that
    I need to clean up, right after I take my foot out of my mouth...
  17. Fishy business[ Go to top ]


    As a long-time user of IDEA for web app development it's nice to see the toolset evolving in this way. I'll wait for an EAP before I go bashing it though...

    As an aside, there is already a framework called SOFIA from Salmon LLC that offers many of the same features. It integrates IDEA (or Eclipse) with Dreamweaver and some natty extensions to allow visual composition of pages (JSP based) with a palette of components.

    I'm expecting something similar from Jetbrains, with the exception of the Dreamweaver extensions of course. In fact their approach appears to have much more in common with the upcoming "Project Rave" from Sun.

    Given that Fabrique will need a persistence layer, MVC action framework, and a page building language it will be interesting to see whether or not they incorporate existing frameworks. Personally, I'd love a visual editor for Velocity templates...

    - Graham