Discussions

News: The Naked Object Architecture Series

  1. The Naked Object Architecture Series (56 messages)

    The Naked Objects framework aims to improve development productivity and create more agile systems based on cleaner object models. The first two articles from this series introduce the concept of 'Naked Objects' and provide a comparison between an application designed using a conventional 4-layer/multi-tier approach with an application developed using the Naked Objects framework.

    Read The Naked Object Architecture Series: Challenging Current Assumptions About Business Systems Architecture

    Threaded Messages (56)

  2. Good news![ Go to top ]

    This is the very good idea indeed. The same approach is used in Perl-based Everything engine (http://www.everydevel.com), and it's just amazing. It's a most clear and understandable development framework I ever seen. This approach was used to build a huge Everything2 community (www.everything2.com) which outperforms all of those Wiki clones in every way. I only dreamed the same thing could be in Java...
  3. The JAC framework provides a strategy that looks quite similar to Naked Objects.
    Define a domain model + interaction methods, and let the framework wrap (via AOP) them with generic aspects that handle transparent persistence, transparent GUI (Swing, HTML, ...), transparent transaction management.

    The JAC aspects are generic and can wrap any POJO. They accept configuration file to customize their behaviour for your specific needs.

    In my opinion, the AOP approach is much more powerful than the usual OO approach.
    Simply because an aspect has a deep knowledge of what happens in the business objects and can react much more smartly.

    Anyway, coding technical behaviours by reflecting what happens in the business objects does work. JAC has proven that already.
  4. ... and at some point in the future the Naked Objects framework may explore this area.
  5. Good news![ Go to top ]

    Though not exactly alike this framework reminds me alot of the 'visual proxy' design pattern that was discussed in a TSS thread a few months back. I must say it's very interesting to say the least. In building J2EE, MVC is all you hear and in fact it's a huge improvement over the past. But who's to say it's the 'best' way. A decent argument is made when it is questioned why any other object should have access to the data (through getters/setters) of some other object, rather than requesting the target object to do the work itself.

    Having said that:

    "In certain visual respects NakedCarServ is a poorer presentation - in particular in the presentation of the diary (although we expect to include a purpose-designed diary viewer in a future version of the Naked Objects framework). "

    The User interface is the application to users. The interface shown would never do in reality.

    Mike
  6. I think in a lot of cases the UI would be acceptable, particularly for maintenance or administrative use cases which are frequently performed by a small group of users or system administrators.

    Although it may not be suited to use-cases with occasional users, this approach looks ideal for those maintenace type use-cases which often get left out of a project.
  7. Check out their site. They are using this in real environments in "regular" applications.
  8. Naked Objects is for every-day use[ Go to top ]

    Although it may not be suited to use-cases with occasional users, this approach looks ideal for those maintenace type use-cases which often get left out of a project.


    Indeed, we don't claim that Naked Objects would be suitable for a kiosk-type application. If the user needs hand-holding, then it isn't the technology.

    But when the user uses the system regularly, then Naked Objects is a good fit. Note that this goes beyond just maintenance "use cases".
  9. Good news![ Go to top ]

    The User interface is the application to users. The interface shown would never do in reality.

    >
    > Mike

    Which is pretty odd, since the web interface seems to "do". And it leaves much to be desired.
  10. The User interface is the application to users. The interface shown would never do in reality.


    We have evidence to present to the contrary for a later article in this series.

    Separately, we are looking to extend the capabilities of the Naked Objects in this regard. It is already possible to write completely new viewing mechanisms, but we are looking to provide an API to allow viewers (per domain object) to be plugged into the default viewing mechanism.
  11. The concept, IMHO, is more about the ability for a user (actor) to interact with domain objects directly and without worrying about the user interface. For example, you can invoke an operation on an object, pass it primitive or complex parameters, and receive object(s) back that you can take further action on.

    VE offers a model-driven development IDE to capture these domain objects in a technology and architecture neutral form. The presentation and persistence is auto-generated in real time, so it always conforms to the domain model. You add a public operation to an object, and a button shows up every time you serve this object, and so on.

    Now, recognizing that the same domain object might be used in different use cases and by different actors, you can customize its look-and-feel along with what its visible/accessible parts to satisfy the application requirements. The look-and-feel is controlled by a reusable and extendable library of (macro-level) widgets that you specify and customize with properties. VE supports thin-client web browser access, PDA browser access, and has a framework in place to support VoiceXML, WAP, etc.

    There is an online training class coming up next week. Check it out at http://www.intelliun.com/developers/tutorials/accs

    You can also view the online demos or download VE 4.0 SE for free. The download has several very impressive examples, but I bet you can build a quick app in your first hour. Will be interested in your feedback.
  12. The User interface is the application to users.


    I agree. The user interface is the application. But most programmers just aren't comfortable with human factors such as user interfaces so they concentrate on things like domain models which are easier to relate to programming constructs. End users don't give a hoot about doman models (or even understand what they are). But developers write software to serve their own needs or the needs of the computing environment instead of the needs of the humans who use the computer. So we laugh and call the end users dumb when they can't figure out how to use an a application or a computer in general. But it's really a deficiency of the developer. It's our job to hide all that complexity behind a user interface that fits the user's mental model of the of the task at hand. The goal should be to make it as easy as possible for the user to understand an application, quickly learn simple features and gradually discover more complex one. Basically we need to make things as easy as possible for both new users and advanced users to be as productive and happy as possible. But it's almost never done that way because that makes it harder for the developer. And it's pretty much impossible if the U/I is generated and can't be customized.

    Most non-technical people are intimidated by computers to one degree or another and most developers haven't got a clue why. We argue about things like number of tiers and what persistance framework to use and completely ignore the fact that most software is for human and not machine consumption.
  13. We're often accused of simply trying to make life easier for the developer at the expense of the user i.e. by forcing the user to accept the domain model as the UI. I'd like to put paid to that idea.

    The concept of Naked Objects grew out of my research work on Expressive Systems which sought to design UIs that empowered the user. I discovered that the concept of 'empowerment' hardly features in user interface design methodologies: go to your bookstore and see if you can find that word in the index of any book on usability, UI design, or CHI. Even the usage-centric guru Larry Constantine, one of the strongest critics of Naked Objects, has stated that if there is one thing that the usability community needs to learn from Naked Objects it is this business of treating the user as a problem solver rather than a process follower.

    I concluded that the best work on expressive systems was centred on the idea of OOUIs - starting at Parc in the early '70s. The most thorough application of these principles was in IBM's work on Common User Access in about 1990. Sadly, little of CUA survived, probably due to its alignment with OS/2. A little of it was adopted in the Windows UI, but the phrase 'cargo cult' comes to mind. But the curious thing about CUA is that despite the purity of the OOUI, there was absolutely no suggestion that this was a reflection of an underlying domain model.

    In parallel with this I was doing research on object-oriented domain modelling and agile systems development. I had concluded that we would get more agility in our systems if the objects were behaviourally complete.

    The conceptual breakthrough was in realising that the twin goals of wanting to design more expressive UIs, and wanting purer object models for reasons of agility, were not in conflict: they were actually 100% compatible. And once you accept that idea then you can start to see that the UI and the domain model can and *should* be the same thing.

    In a later article in the series, we'll present hard evidence that the Naked Objects style UI is both effective and popular with users (and I don't mean technical users).
  14. that if there is one thing that the usability community needs to learn from

    > Naked Objects it is this business of treating the user as a problem solver
    > rather than a process follower.

    Hmm, perhaps for some applications. For many applications, where the customer is a company rather than the actual end-user, there is a strong interest to have the user be more of a process follower than a problem solver.
  15. For many applications, where the customer is a company rather than the actual end-user, there is a strong interest to have the user be more of a process follower than a problem solver.


    I don't deny this - I hit it all the time. Most businesses want to treat their users as process followers, not problem solvers. It all goes back to Frederick Taylor and his 'One Best Way'. But as we showed in the Naked Objects book (and I have argued with much greater rigour in my PhD thesis) - this strategy is deeply misguided. Not only does it disempower and disincentivise the workers, but it is counter-productive even in terms of the narrow goal of efficiency.

    There are several examples explained in the book - read it online at: http://www.nakedobjects.org/section6.html

    As John Seely Brown wrote in The Social Life of Information (a great book!), it is a myth that information-intensive activieies (e.g. administration) fit well into the kind of process models that were invented for the manufacturing industry. The most valuable people in an organisation are the ones who've worked out how to get the job done (and the customer satisfied) despite the appalling constraints of the system.

    The work that we did for the Irish Department of Social & Family Affairs is a great case in point. Systems people see benefits administration as a classic form of process-following. The DSFA management took a more enlightened view and are now reaping considerable benefits from it. (There's a short write-up of this on: http://www.nakedobjects.org/section8.html but we will be describing their post implementation experience, including a user survey, in a later article in this series.
  16. Good news![ Go to top ]

    Is there doc explaining the Everything engine?
    I saw lots of bits and pieces but nothing that
    showed how it all worked.

    thanx
  17. how it all fits together...[ Go to top ]

    Is there doc explaining the Everything engine?

    > I saw lots of bits and pieces but nothing that
    > showed how it all worked.

    You can get the big picture at http://www.nakedobjects.org, where you can browse Richard and Robert's book, published by Wiley, for free. The exact link is http://www.nakedobjects.org/content.html.

    For these articles, given the audience, we deliberately wanted to take the discussion forward and focus on specific aspects and consequences of the Naked Objects approach, as well as write up work done since the book was published.
  18. Maybe I'm missing the point...[ Go to top ]

    but two words come to mind: FAT CLIENT. Been there, done that, experienced its inefficiency in a world beyond two tiers.
  19. Re: Maybe I'm missing the point...[ Go to top ]

    but two words come to mind: FAT CLIENT.


    I really don't see a reason why you can't create a web version of the same principle. Sure, it's going to look a lot different, but it sure could be made usable enough to be worth creating such a framework.
  20. and it doesn't look so different from the AWT equivalent. In particular, it is not modal.
  21. Oh my god! Fat client! Run! Run! :)[ Go to top ]

    Hey.. I actually checked it out. They have a business object server. I guess the presentation framework is the 'fat client' and the actual objects can reside on the central server (correct me if i'm totally wrong). Is this so bad?

    And maybe (i don't know) you could distribute the client with webstart?

    Seems kinda cool. A call to Alex B: have you checked this out? This just might do the trick..

    Pax,

    //ras
  22. Hey.. I actually checked it out. They have a business object server. I guess the presentation framework is the 'fat client' and the actual objects can reside on the central server (correct me if i'm totally wrong). Is this so bad?


    so, yes, you are right.

    > And maybe (i don't know) you could distribute the client with webstart?

    indeed, that's the idea.

    > Seems kinda cool. A call to Alex B: have you checked this out? This just might do the trick..

    contact us if we can help.
  23. Maybe I'm missing the point...[ Go to top ]

    Depends on how you define Fat Client. If you mean deploying drivers on the client, I feel your pain. But thick client can be deployed with out this. And the experience is much better for the user and development and maintenance for the developer is too. A thick client is not inefficient beyond 2 tiers and makes better use of network resources than a typical web client does.

    With me, it is not an all or nothing thing (web or thick client).
  24. Fat clients aren't an issue[ Go to top ]

    I hope we agree that a web interface is not the ultimate UI; it patently is not. So, the issue with fat clients is one of distribution. Technologies like Java Web Start, and similar tools such as Marimba's Castanet, mean that, at least for business enterprises, this is no longer important.
  25. Fat clients are(!) an issue[ Go to top ]

    I agree with your first statement. Web UIs are not the final answer. I also agree that Web Start and similar technologies are a possible solution. However, and here I can see us running in circles repeating what has been achieved during the last 10 years, "fat clients" create certain expectations by the user that Java does not seem to address any longer. Memory footprint, startup times, overall performance of Swing applications can typically not keep the pace of power users. I've seen that many times on client sites/business enterprises where people do not have the privilege of working with a 2GHz box. I myself consider myself a power user of IntelliJ IDEA, and I do own such a setup, but still sometimes the software seems to crawl way behind my typing--although IDEA is a marvelous piece of software.

    Having that said, I can see applications for both approaches. However, I resist to jump on the current rich-client-hype bandwagon. I thing we both agree on server-side technologies having to evolve in certain areas. IMHO, that's why we're discussing this very issue today.
  26. Fat clients are(!) an issue[ Go to top ]

    SWT can be Webstarted.

    Swing clients can be responsive. There is a point were it can be pushed to far. I've not reached it yet. Advances in the JVM and PCs have negated many issues.
  27. Responsive swing[ Go to top ]

    Swing clients can be responsive. There is a point were it can be pushed to far. I've not reached it yet. Advances in the JVM and PCs have negated many issues.


    We're currently building a complex application with multiple separation layers. The swing is a very complex framework to deal with but it's one of the most flexible ones out there. You can customize basically everything. The responsiveness is very good (with lots of threading), it's only the startup time and the memory size that are not that nice..

    BTW. the webstart is completely b0rked. we had to build our own (pure java) implementation for that to make sure that the most recent jars are loaded everytime. With webstart you were only ~90% sure that the client got the latest stuff. Webstart is also hardcoded to english, uses it's own classloader and together with locale specific methods everything breaks.
  28. Responsive swing[ Go to top ]

    Thanks for relating your experiences.

    I know Swing and Webstart have their issues but so do "Web Apps", VB, .Net, ...

    There are some OSS version of Webstart not sure how good they are. I figured Webstart was more of reference implementation. To compete with .Net we will need something between WebStart and DeployDirector.

    Any chance you can anyone can get ahold of your "webstart"? :)
  29. Responsive swing[ Go to top ]

    Any chance you can anyone can get ahold of your "webstart"? :)


    Sorry, it's closed source ;-) But I can describe the general idea.

    1. When our webstart starts (nice rhyme..) it checks for previous server configuration to connect to server via 'yeat another closed source protocol'.

    2. Upon connect the server sends a list of client libraries where each library is named 'fileSize.lastModifiedData.fileName.jar'. The server also sends the url from where these libraries can be downloaded.

    3. Client compares the list against own server specific cache, removes local files that have different names than remote files and downloads those files (via HTTP) that have different name.

    4. Client applies local files to classpath (using classloader tricks) and starts the actual application.

    It's very basic stuff that we need (clients are within same private network than server or then they use VPN tunneling). But it *must* work everytime. Sun's webstart, although more complex and supposedly more secure didn't always work. And it's english only. And it's slow.
  30. WebStart Deployment[ Go to top ]

    i am a newbiew to Naked Objects. i personally like the primary ideas behind naked objects.

    In regards to deployment, we build a deployment engine that used web services and binary64 as the deployment protocol.
    The assemblies are serialized to binary64 on the server, and de-serilaised and installed on the client. The rest is standard plumbing.

    Also the Micrsooft Application Block does a similar thing.

    This approach allows updates to occur based on:
    1. pollinh
    2. startup
  31. Is it just me.....[ Go to top ]

    ..or is this old news? The Naked Object framework has been around for quite a while now - I used it to develop an app for a client well over a year ago.
    I'm just questioning why this article is getting posted now?
  32. Re: Is it just me.....[ Go to top ]

    ..or is this old news? The Naked Object framework has been around for quite a while now - I used it to develop an app for a client well over a year ago.

    > I'm just questioning why this article is getting posted now?

    Glad you've met the Naked Objects framework, but for many it isn't yet old news.

    Even if you've encountered Naked Objects though, the point of these articles is to take the discussion forward and focus on specific aspects and consequences of the Naked Objects approach, as well as write up some more recent work and findings.
  33. The Naked Object Architecture Series[ Go to top ]

    seems like 'Naked Gun' :)
  34. The Naked Object Architecture Series[ Go to top ]

    I looked at this a few years ago and thought it was an excellent idea. If not for deploying applications, it is definitely good for training. I do believe it is viable for some applications. As with any app, certain things must be considered and sometimes the best UI doesn't win.
  35. If only it were that simple....[ Go to top ]

    While this is an interesting concept - particular for teaching - I do not think it has much practical value but for quickly building stuff only used by a small clearly confined set of users. The reason is manyfold: A lot of business application put very clear specifications in place about how the application is going to look like and exactly how it is to behave. There is not much object orientation in the interface itself which is a bit of a shame since polymorphism works excellent with GUI classes. The actual domain objects will often not suffice: How is access control happening? How much support classes will you need? How is persistence going to happen? The tragedy is that noone seems to remember that 4 tier implementations may not be the brightest idea anyway and talk a lot about "MVC" completely ignoring the fact that M-V-C are NOT horizontal layers. A still a lot of the 'M's in traditional MVC failed because they were just to complicated to handle, thus finer grained persistence layers and explicit persistence were introduced....
  36. Re: If only it were that simple....[ Go to top ]

    I do not think it has much practical value but for quickly building stuff only used by a small clearly confined set of users. The reason is manyfold: A lot of business application put very clear specifications in place about how the application is going to look like ...


    You are right in what you say, but do you agree that it is right for the emphasis to be here? We say instead that the underlying domain model is more important to have a clear specification about ... and its representation is fine tuning. Given the speed that Naked Objects prototypes can be developed, it is usually pretty easy to win the business over on this point.

    > ... and exactly how it is to behave.

    Here we agree.

    > How is access control happening?

    As an optional layer on top of the domain classes.

    > How is persistence going to happen?

    Persistence is pluggable, in the same way that the Naked Objects architecture supports pluggable viewing mechanisms.

    > The tragedy is that noone seems to remember that 4 tier implementations may not be the brightest idea anyway

    Indeed.
  37. depeche mode[ Go to top ]

    I'm a big fan of the eighties, so I'm glad to see we're going back to that naive decade with it's brilliant soundtracks...
  38. 80[ Go to top ]

    Yes you're right! This is really look like a student report...
    I have nothing against students, but come on guys, the first E in J2EE stand for ENTREPRISE...
  39. The comparative implementation is indeed an academic exercise; it's not the kind of thing that businesses put money aside for.

    However, as we hope to explain in a future article in the series, the Naked Objects architecture is suitable and has already been used for enterprise systems.
  40. 80, 90, 00[ Go to top ]

    Yes you're right! This is really look like a student report...

    > I have nothing against students, but come on guys, the first E in J2EE stand for >ENTREPRISE...

    The naming is unfortunate. It probably should have been J2SSE (Server-Side). J2SE is no less important than J2EE (except to J2EE vendors) and no less valuable to an enterprise. That is is the mistake many make. The competition's direction is back towards a rich client not only for lock-in purposes but because it is now possible with much less pain.

    How about thinking of it as "Back to the Future" and less "retro".
  41. LGPL -> GPL[ Go to top ]

    I've read several messages online which stated that this project was LGPL and recently moved to GPL, that's a bit of a shame. Why not the jboss biz model, make money with documentation (sell books) and keep the good license?
  42. LGPL -> GPL[ Go to top ]

    I've read several messages online which stated that this project was LGPL and recently moved to GPL, that's a bit of a shame. Why not the jboss biz model, make money with documentation (sell books) and keep the good license?


    From what I've seen, GPL is surprisingly more business-friendly than LGPL or BSD. That's because those who want to make proprietary enhancements to your work have to approach you for an alternative commercial license. With LGPL, they can extend your work without taking your permission. With BSD, they can take your code as well. So much for BSD being a business-friendly license! I guess it depends on whose business you're talking about - the developer's or the "exploiter's".

    Regards,
    Ganesh
  43. There was a company 10+ years ago that produced a software development application called Utah for Windows, by ViewSoft, which slanted the developers to concentrate on the domain model, and the app automatically rendered the UI. The company has been purchased by Citrix and doesn't exist anymore.
  44. I think NakedObjects looks very nice for a business/database access system. Even if you didn't like the front end, you could still prototype quickly with it and then change the front end. You could still use the java classes right?

    As well, I'm thinking about desinging a PIM. Would NakedObjects help? Would it allow me to fine tune the front end?

    Thanks!

    Mark
  45. Yes, you could use Naked Objects to design the objects and then write a conventional front-end that called their methods. The benefit you will get is faster prototyping and a cleaner object model.

    But be warned . . . we know of several people who intended to do this, but when they came to start designing the front end, the *users* expressed very strongly that they wanted to stay with the Naked Objects front end because of the freedom that it gave them to tackle each business problem in the way they wanted.

    Several responses in this discussion seem to suggest that our statement that you can write a conventional UI to run on top of the Naked Objects is somehow an admission of the inadequacy of the existing UI. Far from it. The reason we make that statement is because it encourages more developers to have a go at using the framework - i.e. developers who refuse to accept that a pure OOUI will actually prove popoular with the users. Try it and you'll discover the truth.
  46. Thank you so much for your response. I was going to write you an email but thought it would be better to discuss in this forum and get more eyeballs on the concept.

    I am most definitely going to write my application using naked objects. Hey, if I don't have to worry about the front or back ends, I should be able to get an application up and running pretty quickly, no?! I think it'll be a great exercise for me because I'm trying to improve my object modeling skills anyway.

    I do have a particular idea in mind for how the application should look, but hey, if it turns out that I can use Naked Object Frameworks' UI, don't you worry, I would! I've got a job to do (ie. functionality) so I would like to see the functionality working first, and then worry about the front and backends. I think something like NakedObjects could be just the solution for quick prototyping, and maybe the final result too! I'll make my decision after I've had a chance to play with it and I see the initial result.

    Thanks again, and thanks for your support of Open Source to let someone like me be able to try out your cool looking technology!

    Mark
  47. As well, I'm thinking about desinging a PIM. Would NakedObjects help?


    There are two things you might be interested in. If by PIM you mean a Palm-like thing, then Heikki Keränen did some work on this a while back, implementing his own viewing mechanism. It's not changed since, but Heikki is still active in the community. Check out either http://www.iie.fi/vhe/noppcdemoapplet/ or http://www.iie.fi/vhe/noppcdemoapplet/ie.html (for IE users).

    If by PIM you just mean a general contact manager, then Mark Crocker put something together, see http://www.markcrocker.com/~mcrocker/Computer/Java/com/markcrocker/pim/pimento.shtml, which has a Java web start demo.

    > Would it allow me to fine tune the front end?

    Writing a custom viewing mechanism gives you arbitrary support for a custom "front-end", but it's a lot of work. An alternative is to write plug-in viewers to the default "lightweight" viewing mechanism. Rob Matthews is finalizing the details of this at the moment, scheduled to be released in Naked Objects v1.2.
  48. The Naked Object Architecture Series[ Go to top ]

    Why not use a tool to auto-generate the domain layer? There are many good SQL clients out there that allow you to use interface your application by manipulating the persistence layer directly.

    Seriously, though, Naked Objects isn't a revolution in development, but only one in user-interface. They admit that you will have to go back to developing your own UI (within the bounds of their current framework, which is not yet possible) if you want something different.

    I think there may be a place, though. How much of our domain layer coding seems boilerplate, because it is just a gap between our UI and persistence. By combining the domain data & logic and presenting a way to manipulate them directly forces a paradigm shift in usability, and I for one am sick of the 'forms' based user interface approach that had forced everything into input fields and buttons.
  49. Please note that version 1.2 incorporates a brand new user interface. This has been available to the development community for many months, but not previously in the public release.

    The new user interface is a huge improvement over 1.0. For example, all object views now display within a single application window. The comments in the above threads criticising the Naked Objects UI are likely to be based on the 1.0.2 release.

    (Apologies, it would have been better to release 1.2 to coincide with the start of the Naked Object Architecture series, but we were a couple of days out with our timing.)
  50. In past days I´ve been reading Naked Objects book (online version). I am very excited about the whole approach and inherited benefits. In fact I think I "adopted" something similar in some past projects : identify domain objects, complete with data and behavior and then prototipe a very simple UI that has direct maps (access) to domain objects interfaces. BTW this wasn´t done with Java, but FoxPro for DOS...

    This really help me to better understand the domain and comunicate with business owners/users, provide tests and simulations with the user, etc. I just came to learn about formal use case modeling 3/4 years ago and the project I mentioned was 7/8 years ago and even today I am not totally convinced about use cases "ROI" in development process.

    So I am really happy to see Naked Objects, but I have some points :

    The current implementation is Java 1.1 based. Ok this may be good for small devices and even .NET compatibility (using MS converter) but IMO this is simply unaceptable for using it in enterprise java projects. A small and concise UI framework (based on JGoodies Forms/Looks or even Swing or SWT) would be great to "render" the UI widgets and firing UI events.

    I mean, in the NO approach the UI actually is first product we deliver to the user and all the iterations runs around UI so I think it´s make sense to deliver it with a professional look and feel, at least.

    Web based frameworks like Millstone or Echo would do it for browser too but it would be a lot of work.

    The other benefit to implementing the UI rendering engine using a high level UI framework like these is that the developer could extend the application look and feel and may be some funcionality, for example providing object queries and the resulting views in a recordset format (relational view).

    Sun´s pattern catalog has a pattern their call "Fast Lane Pattern". This is just a plain SQL access to relational data where the objects are stored. Oracle´s BC4J framework provides a nice funcionality that automatically instantiate POJOs/EJB´s based on user actions/updates in the relational view. BC4J can fire POJO´s events (NO actionXX) because it knows the objects metadata and relational mapping.

    I saw something about Prevayler in NO download page. Prevayler would be a nice complement to NO for doing users first iterations but for production level 90% of the applications use plain old relational databases.

    Concluding, there are two main issues IMHO NO has to improve to get better aceptance in enterprise : UI rendering engine implementation must be based at least on current standarts implementations and must be customizable by the developer. This feature would turn possible to the developer to deliver at least one missing funcionality (as far I know) in NO : users customizable queries and views.

    Rodolfo

    PS : Sorry about my shameless typos. I will keep trying..
  51. The current implementation is Java 1.1 based. Ok this may be good for small devices and even .NET compatibility (using MS converter) but IMO this is simply unaceptable for using it in enterprise java projects. A small and concise UI framework (based on JGoodies Forms/Looks or even Swing or SWT) would be great to "render" the UI widgets and firing UI events.


    There already is a prototype Swing viewing mechanism for Naked Objects, written by JohanCStoever and JochenBedersdorfer see:

    http://development.nakedobjects.org/wiki?SwingGUI

    This gives visual compatibility with other Swing apps for those who need it, and the possibility to extend with other Swing constructs. The great thing about the Naked Objects architecture is that swopping from the default viewing mechanism to the Swing viewing mechanism (or the DHTML VM) is just one line in the configuration file: zero changes are required to your application code.

    > I saw something about Prevayler in NO download page. Prevayler would be a nice complement to NO for doing users first iterations but for production level 90% of the applications use plain old relational databases.

    A alpha release of the Prevaylor object store for NO is available on:

    http://development.nakedobjects.org/wiki?DevelopmentDownloads

  52. > The other benefit to implementing the UI rendering engine using a high level UI framework like these is that the developer could extend the application look and feel and may be some funcionality, for example providing object queries and the resulting views in a recordset format (relational view).
    >

    Sort of like Hibern8IDE does for Hibernate?
  53. I think that Hibernate ie a good compliment to Naked Objects and I'd like to see someone who knows Hibernate well do an integration. Naked Objects currently has no form of dedicated querying or reporting and it would be nice to take advantage of their work in that area.
  54. Is it good comparison?[ Go to top ]

    I read that Data Access Layer code can be even 40% of application code.
    Maybe the comparison of Naked Objects with 4L architecture + Hibernate would be not so obvious.
    On the other hand - more data-aware UI can speed up development.
    What if we have something like object-aware UI?
  55. Nice implementation of the old idea[ Go to top ]

    I was glad to find out that one of the ideas that was very popular about 25 years - two decades ago in the AI community and AI research circles found a solid implementation in the Naked Objects approach.
    The idea of creating domain objects that will allow to automatically construct applications to serve different tasks in a specific domain was discussed in many articles and books many years ago.
    The only problem that was not solved then and does not seem to be solved with the Naked Objects is the validation of the domain or the coverage of the domain by the objects.
    It was clear many years ago that this approach can produce good results for simple well explored domains, and it cannot be a silver bullet for all possible domains based on the expertise in the respective area.
    It is pretty much the same problem as was with the expert system shells that were created for a certain vary narrow domain and then the developers attempted to expand them to other domains, but with very little luck.
    Nevertheless, it is interesting to see how the upcoming articles expand the approach and how more complex examples or experiments can fit into this framework.

    David
  56. Wrong image url (gif not jpg)[ Go to top ]

    The final figure has the wrong url; it now reads:
    http://www.theserverside.com/articles/content/NakedObjectSeries_2/Figure6.jpg

    the correct url is:

    http://www.theserverside.com/articles/content/NakedObjectSeries_2/Figure6.gif
  57. Hello[ Go to top ]

    Good