Discussions

News: OpenXava 3.0: JPA Application Engine

  1. OpenXava 3.0: JPA Application Engine (45 messages)

    OpenXava 3.0, released recently, is a framework to develop Java Enterprise applications in a different way: OpenXava avoids MVC. It's a JPA Application Engine in that you provide only your POJOs annotated with JPA and you obtain an application ready for production. With OpenXava 3.0, you only need to write your model, POJOs and Java 5 annotations. (Prior versions required XML.) You do not need to write the view, and the controller (for CRUD, printing, etc) is reused. That is, you only write a class as this one:@Entity public class Teacher { @Id @Column(length=5) @Required private String id; @Column(length=40) @Required private String name; public String getId() { return id; } public void setId(String id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } } And you have an application (see it here) for CRUD, report generation in PDF, export to Excel, searching, sorting, validations etc. Uou only need to write a simple Java class, no XMLs, no JSPs and no code generation. OpenXava is not only for writing simple CRUDs for simple classes, you can create sophisticated applications with complex logic and advanced UI. OpenXava supports references, collections, inheritance, nested tabs, nested frames for grouping, etc. More info: http://www.openxava.org/ What do you think about this way to develop applications? Do you think that MVC frameworks (Struts, SpringMVC or JBoss Seam) are as productive as VisualBasic, 4GLs, RPG, etc? Do you think that MVC is always the best solution? OpenXava has been released under the LGPL.

    Threaded Messages (45)

  2. How can people still be writing applications which require a complete roundtrip and a server page refresh? Has anyone heard of AJAX? Do you know about Javascript? This is an excellent idea but the implementation suffers from the same basic flaw that all JSF, JSP, and Java Web frameworkks have suffered from for the past 6 years. They refresh the entire page every time you burp. It is a pathetic testament to the tunnel vision of the authors of these "programs". They are all completely useless because of this flaw.
  3. How can people still be writing applications which require a complete roundtrip and a server page refresh? Has anyone heard of AJAX? Do you know about Javascript? This is an excellent idea but the implementation suffers from the same basic flaw that all JSF, JSP, and Java Web frameworkks have suffered from for the past 6 years. They refresh the entire page every time you burp. It is a pathetic testament to the tunnel vision of the authors of these "programs". They are all completely useless because of this flaw.
    I don't think I'll bother mentioning the irony of TheServerSide using this same paradigm... Actually, I think you're being a little demanding. Not much, but a little.
  4. How can people still be writing applications which require a complete roundtrip and a server page refresh? Has anyone heard of AJAX? Do you know about Javascript? This is an excellent idea but the implementation suffers from the same basic flaw that all JSF, JSP, and Java Web frameworkks have suffered from for the past 6 years. They refresh the entire page every time you burp. It is a pathetic testament to the tunnel vision of the authors of these "programs". They are all completely useless because of this flaw.
    I don't think I'll bother mentioning the irony of TheServerSide using this same paradigm...

    Actually, I think you're being a little demanding. Not much, but a little.
    Did you say JSF requires a refresh to the entire page? Sorry but this hasn't been required for sometime now. Most JSF component libraries now provide AJAX enabled components or AJAX support for ones that are not.
  5. Has anyone heard of AJAX?
    Yes, I heard You are right! The next OpenXava version will suport AJAX, and all OpenXava applications written with OpenXava 3.0 will be AJAX enabled without touch a line of code. The very first version of OX was a Swing application generator, the current one is HTML, the next AJAX, and the in the future maybe FLEX. But, the IDEA is that you can write the application without bother about user interface technology. Cheers
  6. The "demo" is underwhelming. I didn't see any legitimate functionality in it. Frameworks for slapping up thin client applications like this offer high productivity provided that you don't stray outside of the way they intend for you to do things. If 10% of your application falls outside of their development paradigm you can spend 50% of the development time trying to make that 10% work. Thin client cookie-cutter applications are a thing of the past. To be competitive today you need some richness in your client which usually means JavaScript / AJAX or Flex. OpenXava claims to support legacy databases, but I am skeptical about that. I'd want to see how broad a range of legacy databases it can handle well, and if you are left with any significant productivity gains in these cases.
  7. Hi Dean,
    The "demo" is underwhelming.
    The goal of the MySchool demo is to explain the concept of OpenXava quickly, not to show all the OpenXava features. Unfortunately most OpenXava application are comercial application, and use it as demo for OpenXava. Applications as accounting, inventory, census, payslip has been developed using OpenXava. These are not toy applications.
    high productivity provided that you don't stray outside of the way they intend for you to do things. If 10% of your application falls outside of their development paradigm you can spend 50% of the development time trying to make that 10% work.
    Do the 90% with OpenXava, the 10% with X and integrate both with a JSR-168 portal with the same look & feel and user management.
    OpenXava claims to support legacy databases, but I am skeptical about that. I'd want to see how broad a range of legacy databases it can handle well
    There are OpenXava application in production against AS/400, Oracle, Postgres, MySQL, Informix and MS SQL Server at least. Really all database supported by Hibernate JPA implementation can work. About legacy schema integration, look at: http://openxava.wikispaces.com/mapping_en Cheers
  8. Do the 90% with OpenXava, the 10% with X and integrate both with a JSR-168 portal with the same look & feel and user management.
    That's might be acceptable in a brainstorming session, but requiring a Portal to get the final 10% of your project done isn't feasible in my world.
  9. I want to say to the OpenXava team congratulations for your project is a neat idea, I will try to use it in the future for next projects. to Dean Schulze: Why isn't feasible to use a Portal for you? OpenXava with Liferay portal you can create great enterprise applications, You can focus on the Model 90% and 10% let to the portal(JSR-168 portlets) manage it with authentification's, authorization's, session's , roles's, Look and feel, layout's so on. That way you don't need to code JSP or view's code by hand, That way you reuse with the portal system.
  10. It's not feasible because I don't know of any clients who are willing to add a Portal, which is a big heavyweight thing, to make up for the shortcomings a some development framework. That's like adding an 18 wheeler to make up for your hybid's limited cargo hauling capability.
  11. It's not feasible because I don't know of any clients who are willing to add a Portal, which is a big heavyweight thing
    Some OpenXava developers with this problem have used a lightweight portal as StringBeans, with good results. WebSphere Portal is heavyweight, but there are lightweight portals, Jetspeed is another example. Anyways, you can deploy OpenXava applications without a portal, but you have to write the navigation and the security in this case. Cheers
  12. Do the 90% with OpenXava, the 10% with X and integrate both with a JSR-168 portal with the same look & feel and user management.


    That's might be acceptable in a brainstorming session, but requiring a Portal to get the final 10% of your project done isn't feasible in my world.
    You can generate regular servlet applications (a .war to deploy in a tomcat) using OpenXava. Usually we use this for testing, but this allows you to integrate your custom web application with OpenXava. In this case you must have your own navigation and user management system. Cheers
  13. Maybe you could better describe motivation for this new framework. For me OpenXava is very similar to naked object http://www.nakedobjects.org, also nakedobjects do not use JPA for domain modelling. I have created similar framework, look at http://vpda.org. It does not use domain models for views and control, but rather defines 'view providers'. I really think you cannot mix model, view, controller in one component.
  14. Hi Roman,
    Maybe you could better describe motivation for this new framework
    OpenXava born in 2001 to create J2EE application with the same productivity level of RPG programmer. But, OpenXava has had its own evolution.
    For me OpenXava is very similar to naked object
    For me too. I like nakedobject. And I think that it's possible to have sinergy between both projects: Look at this comment: http://www.theserverside.com/news/thread.tss?thread_id=47096#240821
    I really think you cannot mix model, view, controller in one component.
    I disagree. The philosophy behing OpenXava is the Business Component concept. That is, to organize the code about Business Component, instead about Model View and Controller. That is, all about Invoice concept must be in the same place, better if in the same file. This is a pragmatic approach if you develop and maintain business application, when you add, a property of Invoice you only need to touch in a file Invoice.java, and not in seven. Look the comment in wikipedia: http://en.wikipedia.org/wiki/Openxava#Business_Component_versus_MVC Cheers
  15. Maybe you could better describe motivation for this new framework. For me OpenXava is very similar to naked object
    http://www.nakedobjects.org, also nakedobjects do not use JPA for domain modelling. I have created similar framework, look at http://vpda.org. It does not use domain models for views and control, but rather defines 'view providers'. I really think you cannot mix model, view, controller in one component.
    And don't forget Roma Framework :-)
  16. Hi Antonio,
    And don't forget Roma Framework :-)
    I don't forget it! See my comments: http://www.theserverside.com/news/thread.tss?thread_id=48503#247917 http://www.theserverside.com/news/thread.tss?thread_id=45698#234136 Cheers
  17. Do you think that MVC is always the best solution?

    OpenXava has been released under the LGPL.
    I'm at the moment doing third full rewrite of a CRUD framework, and i think that finally, after 4+ years, i'v got my CRUD nailed just right. Most important thing that i'v learned is that customers always require customization. If the framework does standard crud 100% automatically, but increases the effort for creating customized views and functionality, the end result will be +-0 or even negative. Having only the model is not going to work. The choice i'v found the best is to use MVC, but with views and controllers optional. I.e. if you don't write the controller manually a default generic CRUD controller is used, likewise for views. /Henri Karapuu
  18. Hi Henri,
    The choice i'v found the best is to use MVC, but with views and controllers optional. I.e. if you don't write the controller manually a default generic CRUD controller is used, likewise for views.
    That is just the OpenXava way. You can use whatever controller you want: Look at http://openxava.wikispaces.com/controllers_en In the most case real life OpenXava application usually have its own controllers for CRUD, in order to adapt the customer and application idiosyncrasy. About view, in OpenXava are highly customizable, but you have always the option of write your view (or part) at hand: Look at http://openxava.wikispaces.com/view_en and http://openxava.wikispaces.com/customizing_en Cheers
  19. The choice i'v found the best is to use MVC, but with views and controllers optional. I.e. if you don't write the controller manually a default generic CRUD controller is used, likewise for views.
    That is just the OpenXava way.
    Um.. but just about 7.5 centimeters above you wrote: The philosophy behing OpenXava is the Business Component concept. That is, to organize the code about Business Component, instead about Model View and Controller. That statement sounds like total opposite? Note, i'm not criticizing, i'm just trying to understand your software... /Henri Karapuu
  20. The choice i'v found the best is to use MVC, but with views and controllers optional. I.e. if you don't write the controller manually a default generic CRUD controller is used, likewise for views.
    That is just the OpenXava way.


    Um.. but just about 7.5 centimeters above you wrote:

    The philosophy behing OpenXava is the Business Component concept. That is, to organize the code about Business Component, instead about Model View and Controller.

    That statement sounds like total opposite?

    Note, i'm not criticizing, i'm just trying to understand your software...

    /Henri Karapuu
    This is my viewpoint: M > MC > MVC Do you understand my message?
  21. The philosophy behing OpenXava is the Business Component concept. That is, to organize the code about Business Component, instead about Model View and Controller.

    That statement sounds like total opposite?

    Note, i'm not criticizing, i'm just trying to understand your software...

    /Henri Karapuu


    This is my viewpoint:
    M > MC > MVC

    Do you understand my message?
    Honestly, it this statement seems to suggest a misunderstanding of MVC. The most important part of MVC has always been the model. The whole point of MVC is that the model doesn't depend on the view or the controller so that you can create more than one way of viewing the model. OpenXava seems to require a specific approach to modeling objects, something that I see as a fundamental flaw. I know a lot of development managers and developers welcome tools like believing that they allow them to increase their bonehead quotient or otherwise decrease development costs but my experience suggests otherwise. There have been so many tools developed to try to make development simple. And in every case (that I've been aware of) they grow in complexity to address users' needs until they become nearly general development platforms but without the advantage of having been designed for that purpose from the ground up. I'm not going to say that there's ever going to be a tool that achieves the elusive goal of dead-simple development (though I doubt it) but nothing about this tool suggests it's substantially different from prior attempts. IMO the gains in developer productivity have largely come from improving Turing-Complete languages and not from constraining features. Others in this thread have mentioned the problem that constrained tools pose when needs are outside of the tool's intended purpose. This doesn't mean those tools can not be used but too often people mistakenly believe their requirements can fit into a development model and have a nasty surprise (often delayed) when they do not.
  22. Honestly, it this statement seems to suggest a misunderstanding of MVC. The most important part of MVC has always been the model. The whole point of MVC is that the model doesn't depend on the view or the controller so that you can create more than one way of viewing the model.
    OpenXava does not aim to be pure from a MVC viewpoint, rather it has a Business Component orientation. That is, we first sort by Invoice, Customer, Product, etc. and then by MVC. That is, it's not a sin that Invoice.java has data about the View. If you want, does not call it a model class but a business component class. In other hand, you can create several view for each model, each view are tips to render in order to know what is the better way to display it.
    OpenXava seems to require a specific approach to modeling objects, something that I see as a fundamental flaw.
    Sorry. I don't understand. A standard JPA model can be use for OpenXava. An user of OX3 (still using the beta), has used Hibernate Tools to generate a JPA model from an existing Oracle database, then put the generated model in an OpenXava application, and he has have all CRUDs and report generation working.
    I know a lot of development managers and developers welcome tools like believing that they allow them to increase their bonehead quotient or otherwise decrease development costs but my experience suggests otherwise.
    I'm a simple programmer, this tool have been developed initially for my team and for me. The evolution of the tool has been a hill climbing process. All features have been developed on demmand, and always with a pragmatic viewpoint. This is not a tool for selling to a manager.


    There have been so many tools developed to try to make development simple. And in every case (that I've been aware of) they grow in complexity to address users' needs until they become nearly general development platforms but without the advantage of having been designed for that purpose from the ground up.
    It's true. Just use several tool, just like a plumber, and combine the result using a Java portal.
    but nothing about this tool suggests it's substantially different from prior attempts.
    Developing complex applications is a complex task. No matter the tool. OpenXava help to do some 'repetitive' tasks. OpenXava will help you, but also you will need time, money and above all good people.

  23. OpenXava seems to require a specific approach to modeling objects, something that I see as a fundamental flaw.

    Sorry. I don't understand. A standard JPA model can be use for OpenXava.
    JPA is a specific approach to creating a model. That's my point. If your model doesn't fit into the JPA approach (or you prefer not to make it so) it does nothing for you. So in fact your View is defining the approach to modeling. Moreover putting annotations in your model for the view is coupling things in the wrong way. It's better to make the view specific to the model than to make the model specific to the view. I think this tool may be useful to a lot of people but it's a little confining for my taste.
  24. This is my viewpoint:
    M > MC > MVC

    Do you understand my message?
    Not even close :)
  25. This is my viewpoint:
    M > MC > MVC

    Do you understand my message?

    Not even close :)
    Sorry. The ideal would be write only the model part (M), but this is not always possible usually you have to write the controllers (MC), this is worse, but needed, and in some very secial case you need to write also some user inteface at hand (MVC) this is the worst case, but sometime there no other way. It's difficult to write a real life application only with model, you always need write your controller logic. But, it's possible to write a big complex application without write your IU at hand. I see it everyday. That is, I'm not against MVC, simply I'm working to remove the V, and reduce the C in some type of application. Cheers Javi
  26. The ideal would be write only the model part (M),
    but this is not always possible usually you have to write the controllers (MC), this is worse, but needed,
    and in some very secial case you need to write also some user inteface at hand (MVC) this is the worst case, but sometime there no other way.
    Okey thanks, now i understand your point of view. However, i disagree with the view part. The idea in MVC is that the model can be presented in different ways. How OpenXava currently uses view customization (annotations in the model class, right?) means that there is one 'endorsed' crud view, whose definition is mixed with the model. The first version of the crud framework i'm developing had the same approach, and it really didn't work well in practice (for us). Basically the annotations cluttered the model's code, and yet annotations were not flexible enough to meet the customization needs of the customers. The way how i'm addressing this now, in the 3rd version of the CRUD framework, is having coarse grained, data-aware, crud specific components (i.e. a single component can manage a many-to-many association entirely). In the end you usually layout and group the components manually, either programmatically or in XML, but you work with high level components 'declaratively', typically writing single line per property/association. Again, my intent is not to put down your framework, only to offer comments what worked for us and what didn't. /Henri Karapuu
  27. Hi Henri,
    Okey thanks, now i understand your point of view.

    However, i disagree with the view part.

    The idea in MVC is that the model can be presented in different ways.
    The view definition is always at an high abtraction level. And you can declare several views for each entity. Look at http://openxava.wikispaces.com/view_en
    How OpenXava currently uses view customization (annotations in the model class, right?) ... the annotations cluttered the model's code,
    Yes. But it's the same case of ORM, using JPA annotations you mapping data is mixed with the model. The .java is bigger but you have only a file. The model code is a little more comple, maybe. But ALL information about a business concept is in the same place. This brings agility when changes on business logic or structured is needed.
    in the 3rd version of the CRUD framework, is having coarse grained, data-aware, crud specific components (i.e. a single component can manage a many-to-many association entirely).

    In the end you usually layout and group the components manually, either programmatically or in XML, but you work with high level components 'declaratively', typically writing single line per property/association.
    At first glance, it seems as JavaBeans for UI dessigner of IDE (for Swing), but not visual. The question is: when you will want migrate to FLEX, or JavaFX, or whatever , do you need to rewrite your applications ? or only your framework/components ?


    Again, my intent is not to put down your framework, only to offer comments what worked for us and what didn't.
    I know it. And I like take your ideas. There a lot of ways to do the things, and many of them are beatiful. Cheers
  28. Yes. But it's the same case of ORM, using JPA annotations you mapping data is mixed with the model.
    Well ORM meta data belongs naturally with model, while meta data used to set presentation details of view layer really does not, and putting it with model is a fundamental violation of MVC. But of course MVC is not a strict law that must be obeyed. And also if you remember, i mentioned earlier that our 1st generation CRUD framework used the exact same approach as OpenXava, so i definitely also accept that your choice has it's advantages. Basically i'm just trying to say: i'v been there, i'v done that, and FOR US it was not optimal choice.
    The question is: when you will want migrate to FLEX, or JavaFX, or whatever , do you need to rewrite your applications ? or only your framework/components ?
    Our 3rd gen framework is based on GWT so there is very little pressure to migrate to Flex. But if we had to, the answer would be strong NO, at least for all non-trivial real life applications. And the biggest problem would not be the pure-CRUD view definitions, which are relatively high level and can be considered a nicely portable DSL, but all controller logic and those custom views that contain platform native markup etc. (to begin with, custom controllers would need to be ported from java to action script, ugh..). Perhaps the difference could be viewed like this: you try to achieve 75% quality for 10% effort, i'm trying to achieve 100% quality with 50% effort. Both have their places. /Henri Karapuu
  29. Hi Henri,
    Both have their places
    I agree with you Cheers
  30. You can use whatever controller you want:
    Look at
    http://openxava.wikispaces.com/controllers_en
    In read world applications you need to do a lot of stuff like enabling/disabling components, initalizing lists etc. based on component events. So pretty quickly you end up writing controllers with this framework too, right? I don't know if the difference is so huge compared to traditional web application framework. OpenXava has pretty nice default implementation, but will it save your time in the end when the view logic gets complex? Tomi
  31. read world applications you need to do a lot of stuff like enabling/disabling components, initalizing lists etc. based on component events. So pretty quickly you end up writing controllers with this framework too, right?
    Right! But, usually you reuse your custom controllers across your application, and sometimes across several applications. You can found an example of a reusable controller here: http://openxava.wikispaces.com/multischema_en For multischema applications. But, usually you need create your own controllers.


    I don't know if the difference is so huge compared to traditional web application framework. OpenXava has pretty nice default implementation, but will it save your time in the end when the view logic gets complex?
    The view is automatically generated. This saves a lot of work. Usually you write few controller logic. For example, you can have 60 entities and 10 controllers. In a RnR appplication, for example, if you have 60 entities you have 60 controllers. Yes, generated by the RnR scaffolding, but 60 controllers to update, extend, etc.
  32. Well after reading some information about OpenXava there are some things not quite clear to me: - what is your argument to choose OpenXava over Grails and what would be the benefits (besides the language)? - does OX support roundtrip-engineering? I can not imagine a single real-world project that does not require some custom coding - and if its only some minor layout issues. - since your web framework is not MVC based - do you have plans to integrate JSF, Struts or any other web frameworks? Else how do I get designers to layout/modify webpages? - how is security/authentication/authorization supported? - OX handles i18n with standard property files. Is there a way to apply i18n to data as well - i.e. have contents in different languages? Sorry if any of these questions are answered on your website which seems to be very well documented. Markus Plesser [fleXive] core developer http://www.flexive.org -- UCS - unique computing solutions gmbh http://www.ucs.at
  33. Hi Markus,
    - what is your argument to choose OpenXava over Grails and what would be the benefits (besides the language)?
    Grails is a MVC framework, indeed you have to write or edit .gsp pages. In OpenXava the user interface is generated automatically on fly.

    - does OX support roundtrip-engineering? I can not imagine a single real-world project that does not require some custom coding - and if its only some minor layout issues.
    OpenXava does not use code generation, hence it's not possible touch the code. But you can customize the view, look at: http://openxava.wikispaces.com/customizing_en
    - since your web framework is not MVC based - do you have plans to integrate JSF, Struts or any other web frameworks?
    Currently, using a portal you can integrate your struts or JSF application with a OX application. Both will have the same look & feel and the same user management.
    Else how do I get designers to layout/modify webpages?
    -
    Using Java 5 annotations in the POJOs. Look at: http://openxava.wikispaces.com/view_en
    how is security/authentication/authorization supported?
    -
    The modules generated by OpenXava are JSR-168 portlets, hence they are deployabled in any compliant Java Portal with its own security and navigation features. OpenXava site is powered by Liferay Portal, therefore in this case the Liferay security is used, but you can choose another portal or create your own security and navigation framework for OpenXava modules.
    OX handles i18n with standard property files. Is there a way to apply i18n to data as well - i.e. have contents in different languages?
    It's not supported, but it's easy to extend OX for supportin g it, using stereotype. You can create a stereotype (with its associated editor) named I18N_TEXT for example. Look at: http://openxava.wikispaces.com/model_en#toc4 Cheers

    Sorry if any of these questions are answered on your website which seems to be very well documented.

    Markus Plesser
    [fleXive] core developer
    http://www.flexive.org
    --
    UCS - unique computing solutions gmbh
    http://www.ucs.at
  34. Gross Exaggeration[ Go to top ]

    "It's a JPA Application Engine in that you provide only your POJOs annotated with JPA and you obtain an application ready for production." To the author: this is just a ridiculous claim and making it totally undermines your credibility.
  35. Re: Gross Exaggeration[ Go to top ]

    Hi Cliff
    To the author: this is just a ridiculous claim and making it totally undermines your credibility.
    Why ? OpenXava is just that. Sometime it's difficult to find a way for describe your work in a way simple and exact. How would you describe OpenXava in only one sentence ? In other hand, OpenXava is not a silver bullet. There are not silver bullet, I read the Brooks paper, and also I'm working for many year developing software. Developing a complex application is, and will be, always complex. OpenXava only removes some of the accidental difficulties of Enterprise Java. Cheers
  36. NakedObjects[ Go to top ]

    Approach is quite similar to NakedObjects project... any comparison?
  37. Re: NakedObjects[ Go to top ]

    Approach is quite similar to NakedObjects project... any comparison?
    I like nakedobject. I think that there are more resemblances than differences. Maybe the differences: - The controller part separated from Model in OpenXava. - The resulting application. - Some technology differences. For me the ideal would be to achieve some level of unity between NakedObject and OpenXava (and other similar frameworks) in order that developer can move its model from one to another with a low migration cost. Image that your team develop an application with OpenXava, then the application must be deployed as a Swing application (and not as JSR-168 portal application) then you can move you model code to NakedObject, and obtain you Swing application. Of course, this is only a dream.
  38. I tried this approach many times, at the end you only get a bored inefficient GUI, just like NakedObjects. Why do you think the GUI is not as important as the Model? I Think the user experience is very very important, it is a determinant for the acceptance of a product. A well defined efficient GUI can not be just generated.
  39. Agree. but in many cases you need to have a crud operation in quick clean way (ofcourse the GUI can be altered using some CCS). in such cases OpenXava fits 100%. in our case we have a cusomer with Content Managment requirment, but they also ask if the end user can submit two forms to be saved into database for later processing. and ofcourse we do it using OpenXava and deploy it as a portlet on liferay portal. The result was really very good, in alomst fraction of time needed to build everything from scratch. Overall, i still agree that for large application with efficient GUI OpenXava and other code generator tool will not survive!
  40. Why do you think the GUI is not as important as the Model?
    I think that the GUI is important, I want: 1. When I improved some part of my user interface, i. e., the search of a reference, I want the improvement in all my application (for all reference search) without touch the application code. 2. I want migrate to AJAX and FLEX without touching my application code. I can do it using a handmade User Interface ? How many things around you are handmade, and how many are industrial made ? Are the industrial ones so bad ? Cheers
  41. 1. When I improved some part of my user interface, i. e., the search of a reference, I want the improvement in all my application (for all reference search) without touch the application code.
    I can do it using a handmade User Interface ?
    When defining UI declaratively using coarse grained components the answer is yes, as long as the improvement is within the components.
    How many things around you are handmade, and how many are industrial made ?
    Are the industrial ones so bad ?
    That analogy is completely broken. The industrial household items are human designed, they are just mass produced. How many things around you are 100% *designed* by computer? Not just human using computer program, but actually completely designed by AI? /Henri Karapuu
  42. How many things around you are 100% *designed* by computer?
    Do you know Xenakis ? It's a joke! The OpenXava UI is dessigned by humans, but applied automatically to the model. When you compile your C code to assemble, it's done automatically. It's just the same case. Although an assembler programmer possibly does not agree. Cheers
  43. I have few questions: 1. What does the created DB look like? I am asking because, half the application will be reports, for which I can use the reporting tool available at my work space, or even Pentaho if you need something open source, if the database is not relational and by that i mean follows the relational data modeling rule, well, this complicate things 2. Where are the tools the IDEs and web interfaces? CRUD applications like the ones Openxava wants to create (pdf, excel exports etc ...) will be very cool if I allow the Business users to create them themselves, something ala ECM or something list Sharepoints Lists Sharepoint is really a beast, in a good way, is does so many things right Openxava could have been more Sharepoint like, a Content/Record/Document Management Framewrok with GUIs for the simple CRUD work and IDEs for the more complex work. Anyway, I like what I saw, and I will definitely follow up on this framework progress, it seems to get many idea right, I like they only make me define the least amount of requirement needed and set well select defaults for the rest In my old work they had created something similar, the requirement thought were defined in Word Files (this was nasty)but they eventually turned this into a form based program/ide and the framework would compile the business components in those files into screens with basic CRUD and Filters, their filters were very powerfull thought, they were for all the fields by default and you could save all the filters you had used or created
  44. What does the created DB look like?
    In my work space we map entities against legate database, usually in an AS/400, and designed by RPG programmers. OpenXava uses Hibenarta as JPA implementation by default, hence any database that can be managed by Hibernate can be managed by OpenXava. The ant task 'updateSchema' of OpenXava simply call hibernate tools for generate/update the database schema. The result is good enough, I think.
    Openxava could have been more Sharepoint like, a Content/Record/Document Management Framewrok with GUIs for the simple CRUD work and IDEs for the more complex work.
    That is a brilliant idea! Or something as a wiki, for edit the application by the user in hot. I think in that sometimes, but.. Is this attractive enough for the programmer ? I say it, because it's needed that the developer enjoy his work, if you want a fine result. Currently, the user can add,remove and move columns (click on the pencil) for list mode, and this is reflected and the report. And of course, the developer can create custom reports: http://openxava.wikispaces.com/controllers_en#toc11
    In my old work they had created something similar ... their filters were very powerfull thought, they were for all the fields by default and you could save all the filters you had used or created
    Fantastic! I invite you to improve the list mode of OpenXava, if you want. Look at OpenXava credits: http://www.gestion400.com/web/guest/credits As you see, OpenXava it's open for the developers. And improving the list and filtering maybe a very good gif for OX. Thanks for your thoughful comments. Cheers
  45. looks interesting[ Go to top ]

    I had meant to reply on this post but ended up posting on the NakedObjects post. Here it is again: I think this (OpenXava) looks interesting for those developers who want to go bid for work that the can do quickly for smaller clients. As long as the way to customize and add functionality is not tremendously effect. I recently went to a presentation on AppThena (http://www.appthena.com/) and that had the same intention. Only, in AppThena they did away with the whole model class altogether and started from the database. This might not look ideal to us model driven programmers but if you think about how many organizations have some database or other over which to modify or build applications on, that is probably a wise approach. The application uses MVC but does not replicate the model classes in pojos or anything like that. You lose in having strong types for the model objects but you gain in that you have an instant application that offers crud and searching. Also similar to OpenXava, AppThena does not generate any code. It'd be interesting how these frameworks evolve hereon. Sarwar Bhuiyan Software Engineer Morse Group Ltd.
  46. Re: looks interesting[ Go to top ]

    Hi Sarwar,
    I recently went to a presentation on AppThena (http://www.appthena.com/) and that had the same intention. Only, in AppThena they did away with the whole model class altogether and started from the database.
    AppThena = Hibernate Tools + OpenXava Using Hibernate Tools you can obtain a model annotated with JPA from a existing database, add it to OpenXava, and you have your instant application. But, the idea of OpenXava 3 is that the Java classes, not the database are the core of the application. This has some advantages: - You can use inheritance, polimorfism and aspects for model your application. - You can put your logic in the same place of your data structure. - You can develop multidatabase applications. - You can use not relational database (as ODBMDS). Personally, I like more Java than SQL. Cheers