Article: Naked Objects 3.0


News: Article: Naked Objects 3.0

  1. Article: Naked Objects 3.0 (22 messages)

    We are pleased to announce, today, the release of Naked Objects 3.0. For those not familiar with earlier versions, Naked Objects is an open-source Java-based framework, that takes a POJO domain object model and turns it into a complete, executable application. It auto-creates a user interface that is a direct reflection of the domain model, offering the option of either a rich-client interface or a pure HTML interface as shown below (you can view both on our online demonstration application); and it auto-creates a persistence layer using Hibernate. How does Naked Objects differ from other frameworks that can auto-generate a user-interface and/or persistence layer from POJOs, such as Ruby on Rails, or Grails? The answer is that most such frameworks employ the MVC pattern, with the result that much of the business behavior ends up in the Controllers that sit on top of the domain entities. By contrast Naked Objects neither requires, nor permits, the specification of Controllers: all business behavior must be encapsulated as methods on the domain entities. For more information, read "Naked Objects 3.0."

    Threaded Messages (22)

  2. GPL?[ Go to top ]

    I think that many people will look at it and go away due to the GPL license. It is an interesting project (it seems too good to be true :-) ) but since it is GPL, I think I won't even consider it for enterprise development. Sorry if I seem rude. Antonio
  3. License is now Apache[ Go to top ]

    As stated in the article the license is now Apache 2.0.
  4. Re: License is now Apache[ Go to top ]

    Great! Sorry, I went directly to the website and then to the Sourceforge site, where I read it still says GPL. That's great news then!
  5. I like NO[ Go to top ]

    I have been keeping an eye on NO for a while now, and it really loooks like its finally coming together neatly. Or maybe I just didn;t appreciate its usefulness in the past ;) How does NO compare/contrast to JMatter?
  6. NOF vs JMatter[ Go to top ]

    As ever, there are pluses and minuses for both frameworks. NOF has a pluggable viewer mechanism and as such supports a rich client viewer and a web viewer. With JMatter I believe only one viewer mechanism is supported, namely a Swing-based rich client. In JMatter's favour many would say its Swing UI looks a little nicer (certainly more conventional) that the NOFs, and it does have more out-of-the-box UI elements such as galleries. That said, work is well underway to provide an Eclipse RCP viewer for NOF, which will be extensible using Eclipse's extension point mechanism. NOF has a very pure pojo-based programming model, which means that it is possible to prototype on NOF but deploy (if required) on some other JEE/Hibernate platform using a hand-crafted UI such as JSF/Struts for the front-end. That's an exciting prospect! In comparison the programming model for JMatter has much greater coupling, meaning (I believe) it is only really possible to deploy JMatter-developed domain models on JMatter itself. The NOF also has a pluggable persistence mechanism with implementations for Hibernate, XML and in-memory. In comparison JMatter (like Grails, actually) only supports Hibernate. The in-memory pluggable object store is very useful for testing and prototyping; later as the domain model is becoming stable one switches to Hibernate. The NOF has a dependency injection mechanism for all domain objects, whereas JMatter doesn't have anything similar so far as I know. The NOF explicitly has repositories/factories as first-class objects, whereas JMatter (I think) uses static methods on classes. This is the way that NOF used to work, but it's hard to make dependency injection work in that model. Proviso: I know much more about NOF than JMatter; hopefully Eitan Suez (author of JMatter) will correct me if I have misrepresented his framework at all.
  7. Re: NOF vs JMatter[ Go to top ]

    Hi Dan, interesting comparation! Can you compare NO with romaframework or OX3 ? I think all these frameworks have some things in common. What do you think ? Cheers Javier
  8. Re: NOF vs RomaFramework or OpenXava[ Go to top ]

    Hi Javier, Can't really oblige because I know very little about them. They both claim to be DDD frameworks so that is something all the frameworks do have in common. It looks like Roma focuses on only web frameworks, so NOF is broader in scope than that because it also supports rich clients. I note that Roma has a dependency on Jasper so presumably has in-built reporting; NOF doesn't target that at all. From the wording of the Roma tutorial it looks like different presentation technologies can be used in the UI (the tutorial uses Echo), so that might be something they have in common. However it seems to be mandatory to create a webflow in Roma (it reminds me of Grails here), whereas in NOF this is not only not required, but is not permitted (hence NOF being very opinionated). I also can't see any mention in Roma of anything like dependency injection or contributed actions as supported in NOF. It's hard to say much about OpenXava because the docs seem to be in Spanish. But since I see you are one of the developers, you are probably better placed to compare the frameworks than me?
  9. N.O. != the rest[ Go to top ]

    They both claim to be DDD frameworks so that is something all the frameworks do have in common.
    Well, IMHO, they are completely different. It's not because you use POJOs for representing your Domain Model that the framework is "Domain Driven"... Take RoR or Grails for example : they are nothing but code generators that help you to get started. They don't carry the same semantics than N.O *at all* ! If you think about it, when using Grails or RoR, you have nothing more than the usual "stack" : MVC + Persistent POJOs. Once you have passed the "scaffolding" stage, then you write controllers and views, just like back in the old days... The only advantage is that you stay on track easily with all the tools that they add. But they are clearly not implementing the N.O. pattern, or any other one than the good old MVC. In contrast, N.O. applies its own concepts, which are completely different than regular MVC architectures. And damn it's sexy :-) In the end, IMHO, there is 2 main tendencies for the moment : * "revamped" MVCs (RoR, Grails, Roma, etc.) : just some eye candy (and lots of marketing) on old technlology (I don't claim theyr'e useless, I just think they don't bring any new concept, only productivity tools) * Naked Objects (N.O.,JMatter) : a completely different way to design and implement OO applications I really think there is a global confusion around the term "DDD". I think Grails, RoR and the like should call themselves "RAD", instead of DDD... They help you do the old things faster, but once again, they don't do it in a new way. Anyway, in the end, I think the two main "tendencies" (MVC vs N.O.) are completely different beasts. And I really think it's the reason of the "N.O. failure" : you have to change your mind quite a lot to unlearn everything and see the light ! To me N.O. style frameworks are clearly the future, but I think the audience isn't ready for it yet... I can't understand the RoR hype when considering N.O., but it's a fact : everybody talks about RoR as somthing new, and only a few even know about N.O., which has been around for a while now. Now, for a taste of "new shit", has anyone of you DDD folks looked at Woko ? We try to do it different there... We inspire a lot of N.O. for the "automatic UI rendering" part, but have a completely different approach for implementing it, and more important, to *extend* the default behavior(s) of the framework, via "facets"... A third way ? Yeah, I think so... It's called "Facet Driven Development" :-) Cheers Remi
  10. Re: NOF vs RomaFramework or OpenXava[ Go to top ]

    I see you are one of the developers, you are probably better placed to compare the frameworks than me?
    Yes, but surely I will not be very objective. The main philosophical issue is the use of controllers. OpenXava derives the user interface from the model, but it uses controllers for the user actions. And of course, other secondary issues as that in OX3: - The model classes are defined using JPA annotations. - The result are JSR-168 applications. - The User Interface is as in a typical business application. Anyways, I think that the better comparation is from a developer that have worked with NakedObject and OpenXava. Cheers Javier
  11. Re: NOF vs RomaFramework or OpenXava[ Go to top ]

    OpenXava because the docs seem to be in Spanish.
    I need to do a little correction. OpenXava documetation is in Spanish and English. Moreover, all labels and messages of OX are in English, Spanish, German, Polish, Indonesian, French, Catalan and soon in Japanase Cheers Javier Paniza
  12. Controllers or not controllers ?[ Go to top ]

    Hi, I like NakedObject, developing using MVC frameworks is laborious. And if we want to simplify, you need to remove things and the model layers is the more beatiful. And NakedObjects have only the Model part, then it's productive and beatiful. In the other hand, the controllers can have a useful role, because you can put in them the reusable logic for every object (CRUD, report generation, copy & paste, data exporting, etc). And you can adapt your application to your user without alter your model. That is, if NakedObjects is a M frameworks, I prefer an Mc frameworks. Also, you can see the discussion about this issue in Openxava forum: OpenXava forum thread about MVC Cheers Javier Paniza
  13. Several of the capabilities you suggest are in fact provided automatically by the Naked Objects framework, but I accept the point that there may be other generic capabilities that you want to make available for all domain objects (or some significant subset of them). But my preferred approach for doing that would be to use Aspects rather than controllers. Naked Objects and Aspects are complementary. If you use controllers, you provide too much of a temptation to developers to start dis-encapsulating the business logic from the domain model - we've seen it happen. Aspects gives much less temptation.
  14. Hi Richard, do you mean 'aspects' for simulating multiple inheritance ? Using of controllers has also a philosophical motivation, you separate the behaviour of the application from the pure business logic. You can use the same business concept (encapsulate using a model class for example) in several cases. Each case need its own behaviour, but all the case share the same business logic. In this case you put the behaviour in the controller. You can use controllers and still have a simple application structure. For example, in an OpenXava application with 100 model classes usually you only need to write 5 to 10 controllers. Cheers Javier Paniza
  15. Javier "do you mean 'aspects' for simulating multiple inheritance ?" That's one possibility. I was thinking more generally. Our 'contributed actions' capability is an even easier way to simulate multiple inheritance. Richard
  16. Java or XML ?[ Go to top ]

    Javier, IMHO the main difference between Naked Object and OpenXava is not about Controllers, but that Naked Objects are written using pure Java, while OpenXava business components are written (mostly) in XML.
  17. Re: Java or XML ?[ Go to top ]

    Javier, IMHO the main difference between Naked Object and OpenXava is not about Controllers, but that Naked Objects are written using pure Java, while OpenXava business components are written (mostly) in XML.
    Hi Daniel, Since version 3 (still in beta) OX allows you to use POJO + JPA annotations + OX annotations to define business components, in addition to the classic XML format of OX. You can see it on: and also in the wiki: That is, you can develop a model using POJOs for Naked Object, and after you have your application finished you can move your model to OpenXava and see the result; and vice versa. This is a very interesting issue, because with a little of colaboration between "model driven" frameworks developer we can facilitate the migration to a framework to other of the applications. Maybe, simply using a minimun common sets of rules or annotations, this can be achieve. For example, I see that NakedObject has the annotation @Hidden, and OX3 has also the annotation @Hidden with an alike sematics. With a group of annotations (and its sematics) in common within "Model Frameworks" we can improving the portability of applications within them. Of course, this is only a vague idea. What do you think ? Cheers Javier Paniza
  18. Kudos ![ Go to top ]

    Congrats for this release ! Looks like you've been busy ! What a step forward compared to previous releases, it really becomes better and better. You're doing something amazing, Naked Objects are a great concept ! So different than usual "CRUDish" frameworks that all look like new painting on an old house... Of course, as a "competitor" (I'm behind another framework that shares lots of concepts with Naked Objects), I still think that some parts could be improved ;-P But I must admit that this release is impressive ! You have really better integration now (the IoC feature looks pretty cool), and keep the whole N.O. concept, it looks really much powerful than the previous version. Kudos to the team for this release, and keep up the excellent work ! Cheers Remi
  19. Re: Article: Naked Objects 3.0[ Go to top ]

    Wow...this is the first time i am looking at this product and it looks really great. Especially i like the UI and Persistence mechanisms. Good to see the concept of Persistenc -> Domain Model -> UI. The first thing that came to mind is the Eclipse Modeling Framework from Eclipse. Its does sound very interesting to see both of them.
  20. More Kudos[ Go to top ]

    Really good news to see that this project keeps rolling!
  21. As an open source organisation it's tough to get information about how people are using Naked Objects or why they aren't. We've composed a short (max 10 questions) online survey, and would really appreciate any responses: Thanks Richard
  22. Re: Article: Naked Objects 3.0[ Go to top ]

    Congratulations! I am very thrilled about the new release and the license changes. I've been a fan for quite a while. I hope this opens the door for more people to use it.
  23. Looks quite interestingar[ Go to top ]

    I think this 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 ( 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.