OpenXava 2.0 released: Business Application Framework

Discussions

News: OpenXava 2.0 released: Business Application Framework

  1. OpenXava 2.0 is available for download. OpenXava allows you to develop J2EE business applications easily. It's based in business components defined with XML: for example, the "Teachers" application from the OpenXava home page looks like this:
    <!--?xml version="1.0" encoding="ISO-8859-1"?-->
    This is not a complete configuration file, but this is enough to allow use of an application to display and edit lists of teachers. The new features of version 2.0 are:
    • Model layer generated using POJOs.
    • Persistence managed by Hibernate.
    • Works in a simple Tomcat.
    Other features of OpenXava are:
    • Has been used for years to develop real applications.
    • High productivity for developing business applications.
    • Short learning curve and easy to use.
    • Flexible enough to create sophisticated applications.
    • It's possible to insert your own functionality in every place.
    • Based in the concept of business component.
    • Adapted to work with legacy database schemas.
    • Generate a full J2EE application: including User Interface and model classes (with POJOs or EJBs)
    • Supports WebSphere 6.0, 5.1 and 5.0, JBoss 4.0.x and 3.2.x using native EJB CMP2 EntityBeans.
    • Supports any application server (Tomcat, JBoss, WebSphere, etc) using POJOs + Hibernate.
    • Supports JSR-168: All OpenXava modules are standard portlets too.
    • It's tested with the portals: JetSpeed 2, WebSphere Portal and Liferay.
    • Easy integration of reports made with JasperReports.
    • Some little support for aspects.
    • Licensed under LGPL.
    • The developer can use English or Spanish.
    • All labels and messages are in English, Spanish, German, Indonesian, French and Catalan, with more coming.
    What do you think about using XML to define your application? What do you think about automatic GUI generation from model? Do you really think that JavaEE 5 without additional framework is enough to afford the development of real life businees application in a productive way? What do you think about a Java5 + @annotation version of OpenXava?
  2. How about writing CODE?[ Go to top ]

    I'm in the minority I'm sure, but I'm of the opinion if someone has the programming chops to architect an application in XML, they'd probably be better off actually writing code themselves and getting on with their life. Yeah, yeah I know that if the model were to change, a 10 year old could probably work out the XML enough to make it. But let's face it, only programmers are going to be changing it. So let's ditch the extra layer of uncessary goop and all of the parity issues that come along with it. That said, XML is the perfect solution for a lot of things and I use it all the time.
  3. Re: How about writing CODE?[ Go to top ]

    I'm in the minority I'm sure, but I'm of the opinion if someone has the programming chops to architect an application in XML, they'd probably be better off actually writing code themselves and getting on with their life. Yeah, yeah I know that if the model were to change, a 10 year old could probably work out the XML enough to make it. But let's face it, only programmers are going to be changing it. So let's ditch the extra layer of uncessary goop and all of the parity issues that come along with it.

    That said, XML is the perfect solution for a lot of things and I use it all the time.
    I would agree with you when talking about app-specific business logic. But it seems much better to generate the boilerplate "goop" than rely on doing it by hand. Ideally, the generators should generate empty app-specific logic modules which can be modified by hand without requiring a regeneration. Also I prefer the idea of having the app model defined once in an XML file, rather than through annotations/metadata in the source which seems too code-centric. There a many facets of a model that cut across many artifacts. Better to define them somewhere that isn't an artifact itself. I've not looked at this project so I don't know how well it fits my needs. Looks interesting though. Question: does it have a visual model builder? Kit (ex VB monkey ;-)
  4. Question: does it have a visual model builder?
    No, at the momment. What type of visual builder is better for you? - UML? - Standalone or integragate in Eclipse? - Maybe a web application for develop web applications? - Or do you prefer to use third party tools for model OpenXava applications? Thanks

  5. Question: does it have a visual model builder?

    No, at the momment.

    What type of visual builder is better for you?
    - UML?
    - Standalone or integragate in Eclipse?
    - Maybe a web application for develop web applications?
    - Or do you prefer to use third party tools for model OpenXava applications?

    Thanks
    Hi Javier, Answer: nothing too complex. IMO, a normal scenario would be
    1. Define the structure, ie. domain classes
    2. Add domain logic by hand
    3. Add DB mapping info
    4. Pick a generation strategy, eg. EJB3, POJOs + Hibernate, whatever
    5. Generate
    6. Make any additions needed to web layer controller logic
    7. Build & run
    So the key thing is the structure, mappings and generation strategy. That doesn't even need a graphical builder really, more like a hierarchical tree view of the project. It just presents things in one place. UML may be overkill, but maybe allow for XMI imports. On a slightly different topic, the most useful tactic IMO for generation is to generate a base implementation, and an empty subclass which is the one actually instantiated and used. The base classes can be put into their own package. Modifications by hand can be made to the subclass, and the generator never overwrites any existing subclass. If this tactic is used at key points in the project (domain classes, controllers, views), it keeps things simple & productive. Hope that's useful. Kit
    1. Define the structure, ie. domain classes
    2. Add domain logic by hand
    3. Add DB mapping info
    4. Pick a generation strategy, eg. EJB3, POJOs + Hibernate, whatever
    5. Generate
    6. Make any additions needed to web layer controller logic
    7. Build & run
    Sorry, 2 should follow 5.
  6. Hi Kit
    UML may be overkill
    Interesting commentary. Time ago I used UML in this way: - Create my model using a UML tool. - Export to XMI. - Import from VisualAge using a XMI to EJB converter. Yes, this was impresive at first glance. But this approach did not convince to me. In the other hand, TogetherJ approach liked me a lot. You can use Java or UML, it the same, UML only is a viewpoint of your code. Not code generation and UML is always in sync. About development cycle, yours is like OpenXava: 1. Define businees component, using XML 2. Insert domain logic, customizing predefined calculators or creating new ones. 3. Generate 4. Choose your controllers, customizing predefined actions, or creating new ones. 5. Build & run I looking for a way for removing (or reducing) the generate step. I like touch and see, touch and see, touch and see.
    the most useful tactic IMO for generation is to generate a base implementation, and an empty subclass which is the one actually instantiated and used. The base classes can be put into their own package. Modifications by hand can be made to the subclass, and the generator never overwrites any existing subclass.
    Seems a good technique. The important thing in an active code generator is that user never touch the generated code. But, OpenXava uses other (maybe not better, simply different) approach. OpenXava uses strategy pattern to insert custom functionality using code generation. For example, if you need a custom method in you generated class you can write something as this: ... ... In this case the code for Carrier class will have a method translate which implementation is the TranslateCarrierNameCalculator. We use this technique with success for years, and we have noted that is possible to create calculators that can be reused several times. Kit, thanks for your comments Cheers Javier
  7. Re: How about writing CODE?[ Go to top ]

    they'd probably be better off actually writing code themselves and getting on with their life
    I know that a lot of programmer are more confortable with Java than with XML. Java is their native language. (In fact OpenXava itself is written in Java, and Java is my native language) The problem is when your need to write a lot of low level code for obtain a common result. Sometimes, as in case of business applications, you need a higher level of abstraction, or else the task will be impossible. XML is perfect for that. Using OpenXava you mix XML and Java in order to develop complex application. But a lot of common tasks are already done by OpenXava.
    uncessary goop and all of the parity issues that come along with it.
    In OpenXava we struggle for avoid parity. For example, the model layer is generated by OpenXava from XML definition, but you does not need to write model classes, nor modifying them. Cheers
  8. Enhorabuena[ Go to top ]

    Congratulations for this release Javier