Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Naked Objects Version 1.0 Released 28

Posted by michael from the need-more-stories-about-nudity dept.
Rober Matthews writes "Naked Objects is an open-source Java-based framework that makes it easy to develop business systems from 'naked objects' - behaviourally complete business objects that are exposed directly to the user. By simply writing Java classes that represent the business entities, and including only business behaviour, this framework provides a unique user interface that allows the user to directly manipulate the objects, and a mechanism to automatically persist them. See nakedobjects.org for details."
This discussion has been archived. No new comments can be posted.

Naked Objects Version 1.0 Released More

Naked Objects Version 1.0 Released

Comments Filter:
  • Does anyone know of some real-world applications that use this framework?

  • The idea is really great I think, cause coding GUI in Java, and in any other language, is really time consuming ! With this little help, which still stays very flexible, great work can be done in less time !

    • I just check out the demos, which are not very convicing :(. I have to rethink migrating to Naked Objects very thoroughly.

      Kind a bad surprise !

    • The idea is really great I think, cause coding GUI in Java, and in any other language, is really time consuming !

      Whaddya mean? The VB/Delphi IDE style makes most of GUI creation a snap. Perhaps you are talking about something different.

      • Compared to any other part of a project, the GUI developement is most of the time a pain in the ass. I'm talking about multi-platform apps, not M$ stuck kinda stuff.

        Well, Delphi, has become multi-platform too lately, it's true.

        Nevertheless, Nakedobjects's not the hype, see my own reply :).

  • Demoed it... (Score:4, Interesting)

    by roblight ( 116400 ) on Friday December 13, 2002 @10:56AM (#4880383)
    ...and didn't like it.

    Heavily OO (lots of drag and drop with mouse movements which is slow IMHO) at the expense of the end user, which they say they avoid somehow:

    The idea of auto-generating the user interface from the business model definition is not new, but the resulting user interfaces have often been poor in terms of usability. Critics say that this approach is merely making life easier for the programmer at the expense of the user. We believe that the naked objects approach avoids such criticism. We do not mean that the user interface of a naked object system scores highly on every aspect of usability. However, we do argue that naked object systems are overall more usable than most traditional systems, even those where a great deal of attention has been paid to usability. This derives from the fact that object-oriented user interfaces better match the way that most people think about the tasks they are performing.
    I disagree with their assertion that OO UIs are a better match. Programmatically maybe, but I don't think it lends itself well to efficient user interaction. I encourage people to download the demo and run through the user stories. I think you'll quickly understand what I mean about its inefficiencies.

    I'm still investigating the Millstone user interface library for development of networked Java applications that was posted in a eariler article. This seems like the type of framework I've been looking for: the ability to swap in-and-out different presentation layers without affecting the business logic (classic MVC pattern).

    • Re:Demoed it... (Score:3, Interesting)

      by scrytch ( 9198 )
      Drag and drop, bad. But I don't know about the GUI being so inherently bad. I mean look at the current awful mess, where you have to write descriptors and access methods and implement interfaces all over the place, put this xml file here, package it up there, and so on. So what does one do to get away from this mess? They usually use something fairly pointy-clicky to build their EJB's instead, and/or they use an XML editor that's also fairly visual.

      I like to think I'm a quick learner, but the massive amount of crap one has to do by hand to do anything worthwhile in J2EE makes me feel just completely overwhelmed and stupid. I'd rather write code than spend all my time with the bloody scaffolding that an application server is supposed to be doing its damn self. Hot deployment and autocompilation are making servlets as easy as CGI now, but EJB and CMP have a long way to go before I want to stop throwing up my hands and write a solution from scratch in perl in less time and with about 1/100th of the code.
    • If you dislike drag and drop.

      You could develop a command line (or a more keyboard based) interface to the same object model.

      The advantage of this model it that it is much more transparent to the user than traditional applications (this is historically a strength of UNIX much more than windows).
    • The fact that Naked Objects have generated to much attention is an indicator of the sorry state today's software industry is in. Anyone who knows anything about how humans interact with software can plainly see that any system whose internals are allowed to 'bleed through' all the way to the end user is doomed to failure. Such attempts have been made before. Simply put, users absolutely don't care how was the system built, how was it put together. All that users care about is how can the system make their jobs/tasks easier. Let's examine the following quote that talks about the benefits of Naked Objects: "Because the user can see exactly how the system works, working with it is extremely straightforward." The user *doesn't* want to see *how* the system works. Same as the user doesn't want to see how a car works. The user only wants to use the car, and to be spared the gory details. Maybe the professional mechanic/engineer wants to see how the system works, but these users are in such an extreme minority, that we can safely ignore their wishes. Also, the 'empowering the users', rather than expecting them to be the 'process followers' mantra is inapporpriate. Users don't want to be empowered, they simply want to use products that will make their jobs/lives easier, or more bearable. Alex
      • Same as the user doesn't want to see how a car works. The user only wants to use the car, and to be spared the gory details.
        Maybe the user doesn't want to know how a car works, but that doesn't mean they "can be spared the gory details" before they're allowed to use it. It's thinking like that which leads to bozos (appologies to Bozo [yesterdayland.com]) assuming that because their SUV can go in the snow it can also stop in the snow (clue for the clueless: it can't).

        And it's thinking like that which leads to Customer Service calls asking why the change they just submitted at your web page wasn't instantly implemented in their account. If they understood how your system works (their request is queued up along with those of hundreds of other customers, and will be processed -- in order received -- in a few minutes) they probably wouldn't call.

      • I agree with Rick the Red's response. I think you're forgetting how powerful an accurate conceptual model can have on a user's ability to get work done.

        Good user interfaces present a metaphor that allows a user to form a mental picture of what's happening underneath. The better a user understands the abstraction they're dealing with, the more likely they are to find new ways of working with the system to accomplish their goals. Good UI design guides a user by plainly showing the consequences of an action before that action is performed.

        For example, a command button that is visually grouped with a text entry box immediately suggests to a user that operating the button causes the software to act on the text in the box.

        Properly exposing underlying business metaphors (implemented with classes) through a user interface should allow the user more freedom to compose behaviors to accomplish work. There's also the potential to produce a community of users that are more clued in to what they're doing and why. This allows them to have a greater stake in the system by contributing meaningful requirements.

        I can't tell you if Naked Objects does this the right way, but the idea is good. Rather than show a 'sorry state' as you put it, I think it shows a willingness to experiment with enabling users rather than thinking of them as stupid cash generators.

  • Multiple Dispatch languages and "Naked Objects" (Score:1, Interesting)

    by Anonymous Coward
    Java is one of the many "crippled" OO languages in which methods specialise only on their first argument (the bit before the dot). This results in a sort of "shoehorning" of natural language noun/verb stuff into an artifical object/method structure.

    This manifests itself in the Java Naked Objects by the presence of classes encoding abstract operations analogous to abstract nouns, where the instance of the class represents a "verb", rather than just using methods to represent the verb.

    I'd like to see a naked-objects like interface for a multiple dispatch OO language. Multimethods could simply be on the right-mouse-click, select two or more objects and the right-click could display applicable multimethods that are part-filled as you do stuff.

    This would be closer to natural language use.

  • OS/2 WorkPlaceShell (Score:2, Interesting)

    by trajano ( 220061 )
    Actually this system looks something like the WorkPlaceShell of OS/2. I actually liked the system when I was using OS/2 a while back, it was quite interesting but programming for it using C (or even C++) was fairly complicated with all the resource files and other language "extensions".

    Since this is written in Java it may be easier to develop than it was in OS/2.

    Hopefully there won't be any copyright violations.

  • Questions (Score:4, Insightful)

    by Hard_Code ( 49548 ) on Friday December 13, 2002 @11:51AM (#4880874)
    The first thing that screams out to me is:

    SECURITY SECURITY SECURITY

    Let's hope this has a sophisticated security API (could not tell from either web site or manual). Otherwise your security is reduced to the "security" of visibility levels of methods (i.e. none).

    The second question is, can a website be autogenerated instead of a Swing GUI? Nobody wants to drop apps down to the client. Otherwise, very interesting idea.

  • javapro article (Score:2, Informative)

    by fuzzbrain ( 239898 )
    There was a good article about Naked Objects in java pro [fawcette.com] last April. It's an interesting idea I think, maybe not for final-products but allowing end-users to see something early on so they can get a better idea as to what they really need in the end product (maybe feature x isn't really that important).
  • This is, like, so less interesting than I thought it would be when I saw "naked" in the subject line. Oh well, back to work...
  • This is exactly what Smalltalk was supposed to be, back in the 70's.

    The novelty here is the intention to show only bussiness logic and replace the interpeter with the desktop (Smalltalk was language-oriented). A great effort has to be done in hiding the GUI-management code.

    Hope that they succeed with this project. I've been pondering for some time now that the whole idea of applications is almost always wrong, and something like this is the correct way to go. At least the concept is far better than the applications+scripting language that Gnome is pursuing.
    • As posted before, OS/2 WPS was a desktop built on some of the same ideas (although it didn't go as far).

      I know that as an ex-WPS user, after getting used to it, every other desktop simply is not on the same level, despite the fact that WPS is about 10 years old.

  • Pimp OS (Score:2, Funny)

    by VoidEngineer ( 633446 )
    Yep, I can see the slashdot headline now: "Pimp OS uses Naked Objects foundation"...

    Hmmm, I'm looking at the screenshot [nakedobjects.org] which is posted on the article, and I'm a little amused...

    Customer?
    Communication?
    ChildBenefitScheme?!?!
    Case?
    Payment?
    Officer?

    I mean, I can understand that a PimpOS or a SlutOS would want to be object oriented and all. But isn't keeping a record of all your activities going to get you into trouble in most places?

    I suppose that the developers are located in Nevada or Amsterdam or someplace.

  • User Model = Program Model (Score:1, Insightful)

    by Anonymous Coward
    To quote Joel Spolsky from his book "User Interface Design for Programmers": "...if the program model corresponds to the user model, you have a successful user interface."

    From what I can see, NakedObjects enourage the differences between these models to be minimized at every step in the design process.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close