Metawidget 0.85: UI generation done right

Discussions

News: Metawidget 0.85: UI generation done right

  1. Metawidget 0.85: UI generation done right (11 messages)

    Metawidget is a 'smart User Interface widget' that populates itself, at runtime, with UI components to match the properties of your business objects. Metawidget does this without introducing new technologies. It inspects your existing back-end architecture (such as JavaBeans, existing annotations, existing XML configuration files) and creates widgets native to your existing front-end framework (such as Swing, Java Server Faces, Struts, Android). The v0.85 release has something for everyone: In addition we have improved our support for RichFaces (now includes SuggestionBox, TabPanel and RichPanel), ExtGWT (now includes Slider), Swing (now includes configurable labels), and have added XML schemas for every component and lots more unit tests. Please note there are unfortunately some breaking changes, as covered in the Migration Guide. As always, the best place to start is the Reference Documentation: http://metawidget.org/doc/reference/en/pdf/metawidget.pdf Your continued feedback is invaluable to us. Please download it and let us know what you think.

    Threaded Messages (11)

  2. This seems to be akin to the Naked Objects approach. Creating the user interface (automatically) from 'domain' objects has its merits, e.g. RAD. The idea probably didn't take off because users (end-users, developers) demand more flexibility in UI design.
  3. Similarities to Naked Objects[ Go to top ]

    Hi there. You are absolutely correct Metawidget has similarties to Naked Objects and several other projects: http://metawidget.org/doc/faq/comparison.html However there are significant differences (hence the rather incendiary 'UI generation done right' tagline :). With respect to your specific point, Metawidget does not try to 'own' the entire UI. It is designed only to be a piece of the UI that sits alongside a designer's existing widgets, look and feel, choice of front-end framework etc. I believe this really addresses the problem of flexibility, but I would love to hear how you find it. Regards, Richard.
  4. Re: Similarities to Naked Objects[ Go to top ]

    Yes, Naked Objects provides a full stack whereas MetaWidget just focuses on the presentation layer. But we too recognize that for many applications a custom UI is required, and provide different deployment options to allow a custom presentation layer to be developed. Indeed, I demonstrate this in my book, using Wicket as a front-end. A RESTful web service interface is another option. Also, we're working on a new generation of viewers to provide much more flexibility. I'll be presenting on one of them - scimpi - at Devoxx 09. Also on my todo list is to develop an integration with MetaWidget. I'm impressed by the work that Richard Kennard is doing here, and I think there could well be synergy (horrible word!) between the two frameworks. That's on my todo list for the new year. All the best, Dan
  5. A Unified Theory[ Go to top ]

    Dan, Javier, It's great to hear from you both. My ultimate goal in all this is to try and make UI generation a mainstream part of everyday software development, and both Naked Objects and OpenXava are doing a fantastic job at garnering mindshare and encouraging adoption of this technique. To be truly accepted by many large development shops, UI generation needs to become standardized, just like ORM being standardized with JPA. I would love to work with you guys on thrashing out what's 'right' and what's 'wrong' with UI generation today, with an ultimate view to getting enough mainstream adoption that it makes sense to propose a JSR. I'd be grateful if you could review this blog entry I did a little while ago. In it, I try to list out, in an unbiased way, all the 'hot topics' around UI generation: http://kennardconsulting.blogspot.com/2008/10/unified-theory.html I think you'll find Metawidget, Naked Objects and OpenXava are in agreeance on at least half these issues. I'd love to get your input on the other half. Regards, Richard. P.S. Dan, I am excited to hear you may be looking at integrating with Metawidget. Obviously I will be available to help you when you do. I know Javier mulled something similar a while ago. This would certainly be one step towards standardizing.
  6. Re: A Unified Theory[ Go to top ]

    Hi Richard, Posted a reply on your blog... Yes, I'm sure we'll agree on lots of this, hence my interest in collaborating. Let's take this offline. Cheers Dan
  7. Re: A Unified Theory[ Go to top ]

    Hi Richard, and other GUI generation folks ! Your idea of an "Unified Theory" makes a lot of sense, and I'm glad there's an open discussion about this fascinating topic. Moreover, you raise very good points, which I have been investigating as well for years now... I'm Remi, author of "Woko : POJOs on the Web!", a framework for creating web applications easily, in a Domain and User-driven approach. Woko handles UI generation in a very specific manner, through the concept of 'facets'. As we share many concerns in our investigations, I thought I'd add my views here... Static or runtime I think it's not really relevant in the end. The app developer doesn't really care how the framework does it, the requirement being that it just works :P So I guess the two approaches have pros and cons in terms of implementation. Woko does it dynamically, using the concept of "facets". The idea is that it has built-in facets which generate a full CRUD web UI (we call it the Object Renderer), and that can be overriden (all or partly) in order to change the rendering. As far as I know, Woko is the only framework doing it that way, as it includes actors (app users) as a first class concept. Modeling language Predicting all possible use cases through a platform-independant model is a big challenge IMHO, and sounds quite irrealistic. It reminds some MDA attemps where you were supposed to model everything, and let the generator spit the UI. It just doesn't work, as : 1/ you can't put everything in your model, some info are way too specific 2/ sometimes you need logic, access to object states etc, and thereby code, to achieve UI customization. Again, unless you define abstractions for eveything, you'lll still have places where you have to inject something that the model doesn't know (like straight machine code routines included in BASIC :P). In Woko, we use all the meta information we can possibly use on the Java types themselves. The code is the model. Then, you just write facets so that your app displays and behaves like you want. Want a sexy widget for some property of some object ? Well, override the appropriate facet, write your own JSP fragment, and you're done. Production or prototype Very good point. Most people seem to think that OOUI and DDD frameworks are only meant to build prototypes... Woko doesn't even distinguish an app of a prototype. As soon as you started creating Domain Objects or Facets, it's an application. Then, in an iterative fashion, you build upon what's already existing, in to make the app behave as you want. Woko completely adheres to this iterative development model, so, production, definitly. Customisation Another very good point IMHO. As far as I've seen, tweaking the UI to make it display what you want is often very difficult (or even impossible sometimes) with most of so-called DDD frameworks. Woko also tries to solve this problem, through its "Facet-based Object Renderer" by : * leveraging generated HTML through strong semantics and CSS/JavaScript * allowing the developers to "plug" into the rendering process at various phases of the process, so that you can change everything, or keep most of the automatic rendering and change only a small part of the UI In woko, everything is customizable. Of course, some customizations require more coding (e.g. replacing the full page for a displayed instance or just replacing the rendering of one property), but you can really get the UI you want in the end. Again, this fits perfectly with iterative development. With woko, an iteration is about overriding the default facets and make it behave like you want. Bounds of Generation Maybe there is room for several options here. I some cases, one might just want a one-shot code generator to help building parts of the UI in an already existing environment of their own. In other situations (like starting a new app from scratch) others will prefer relying on a full stack framework that handles every recurrent aspect of application development. Woko goes the "full stack way". It (dynamically) generates a fully functional, Wiki-style (Woko is basically an Object Oriented Wiki, hence the name) UI that allows CRUD operations on your model. Then, again, you can cut pieces out, change others etc. It's fully flexible. Multiple Platforms I think support for Desktop/Web apps is not really relevant. I mean, when you develop the app you already know what kind of target you plan to support... Woko is web only. It can easily provide different representations of objects (e.g. for Web Browser or Mobile Client) via its facet system, but it clearly doesn't create swing objects. Consistency See above. Non relevant for me. Diverse Architectures The best would be to provide ootb support for a predefined stack that you can later on replace bits by bits. That's not the case for Woko 1.x, but Woko 2.0 (under dev) should handle that better. Actually only the Web MVC layer is not optional. A good example is the ORM, or should I say the persistence layer... You might not really care about the technology when you start the project, but at some point you might wanna use a different persistence provider. This is true for most of the transversal services provided by the framework to the application. Third Party Components In a web environment, you can't afford not to. The base idea behind a typical DDD framework is to provide default views, but allow developers to replace them. So of course, if the developer has this great widget that took monhts to develop, he might get angry when you tell him he can't integrate into your generated UI... Example : include a Google Maps widget into your app... Ok I think that's it... I hope the discussion will continue on this topic, and new ideas will flourish. I really think (as many of you I guess) that most apps are developed without the kind of methodological support that DDD frameworks provide. Most developers think RAD is just useable in the very first iterations of the project, whereas it's probably one of the most advanced iterative development technique. Thanks Cheers Remi Woko : http://sf.net/projects/woko The doc : http://pojosontheweb.wikispaces.com PS : couldn't post on your blog directly as the message exceeds the max length...
  8. I was all excited about MetaWidgets until downloaded the applet example and looked at the code... annotations... *shiver* What planetary alignment caused peoples' brains to collectively lose the meaning of the word "plain" in Plain Old Java Objects (POJOs)? So now you proposing that we bang presentation layer information (which is what UI annotations are) into the POJOs of the object model... To date I've managed to keep my Plain Old Java Objects "Plain", even against trend of whacking all kinds of persistent engine specific annotations in there. Luckily I use a tool that automatically manages the XML persistence metadata for me so it's a no brainer to keep it outside of the POJOs. It would be great if you offered an alternative to "POJO corruption by annotations" with your MetaWidgets stuff. Maybe you do and that would be excellent.
  9. No, you don't really have to[ Go to top ]

    Chris,
    It would be great if you offered an alternative to "POJO corruption by annotations" with your MetaWidgets stuff. Maybe you do and that would be excellent.
    Yes, we do. Quite extensive support, in fact. We have our own XML format, we can read other people's XML formats (Hibernate, Struts, etc.) and you can easily plug in your own XML format. And it's not just XML: we've got people reading stuff from Resource Bundles, database schemas, etc. Metawidget is very big on reusing your EXISTING metadata, however it's stored and however you want to provide it. I'd urge you to work through Part 1 of the tutorial, or read Chapter 2 of the User Guide (Architecture) and I'd be grateful for your feedback. Regards, Richard.
  10. has its merits, e.g. RAD. The idea probably didn't take off because users (end-users, developers) demand more flexibility in UI design.
    So, instaead of reject this approach, we can improve its weak point, that is, to give more flexibility to the "creating the user interface (automatically) from 'domain' objects" idea. In the case of OpenXava we: 1. Give a lot of flexibility by means of view annotations. This is enough for most use cases in business applications 2. can mix the hand-made UIs with automatic UI. 3. can define the way the automatic UI is generated using editors. About end-user satisfaction, really the end-users has no way to know if the UI has been is developed by hand or automatically. They only see a full featured application developed in short time. About developer satisfaction, see the their comments I can't recall when I was so excited about a framework, specially for web development. I have been in the field since 1983 and I am hard to impress. With OpenXava I am impress! See the original message. I like the idea; this is like a dream come true, as I have been wanting something like that since the day I programmed my first user interface See the original message. este último año he estado trabajando con portales corporativos sobre Liferay así que te imaginaras que OX es un sueño hecho realidad para mi See the original message. Yes, I know that it's natural to think "I don't use 'Automatic UI from domain object' so that is a not feasible option". But, you first have to try it.
  11. no[ Go to top ]

    This seems to be akin to the Naked Objects approach. Creating the user interface (automatically) from 'domain' objects has its merits, e.g. RAD. The idea probably didn't take off because users (end-users, developers) demand more flexibility in UI design.
    Yes, Ruby on Rails and Grails went absolutely no where. :)
  12. Richard is a very driven developer who really puts effort in trying to match MetaWidget with the use cases of the users. As I tested MetaWidget, and even though it worked perfectly, I ran into a number of taste-related "issues". First I did not like to annotate my business model with GUI related info, because it also is used in a SOAP service, a restful service using JAXB and Swing application. The amount of not-BM annotations would make a garbage of the code. There always is the option of using configuration instead of annotations, but conflictingly I also am a fan of compile time checking. Secondly the main portion of my BM is actually reversed engineered from the RDBMS, which would require some strange hoops to get custom annotations in and certainly make things not better readable. And last but not least, my Swing application has evolved a lot of generic support classes (aka a framework), which reduced building a form to three lines of code for each field: create component, bind to property (JGoodies binding), layout out screen (MigLayout). The exact information required as annotations if you are doing custom layout. So I did not really see a need to put in an additional layer of abstraction. I can certainly see MetaWidget give new projects a big boost when starting up, but I expect that as a application matures, more and more screens will be hand coded. And since my application already was there... Never the less: keep up the good work, Richard!