今天偶然撞見兩個大師在討論MDA的理念，收穫頗多，特轉帖於此。
source: http://sourceforge.net/forum/forum.php?thread_id=2014199&forum_id=544071
|
By: Javier Paniza (javierpaniza) - 2008-04-21 18:08 |
| Hi all, I'm Javier Paniza, project lead of OpenXava project, http://www.openxava.org/ and I have a proposal for Naked Objects team and community. OpenXava and Naked Objects are very alike products, in fact, OpenXava compete against Naked Objects. Even though, I think that Naked Objects and OpenXava can cooperate in some way, and this can be profitable for both, this can help us to gain ground against MVC frameworks. But, How ? We can concentrate in portability. The idea is that a develeper develops an applicaton for OpenXava, and in any moment he could migrate it with a minimun effort to NakedObjects. The same application, different engine for running it. Even, if we will achieve a high level of portability, the developer can have the application on OpenXava (to use it inside a java Portal) or in NakedObject to use it as a java Client Application. How we can obtain this portability ? We can start using standard java API as JPA for persistence, and bean validation (JSR-303) for validation. Removing from our frameworks all propietary annotation about these issues. Then, we can try to create a "common" specification for layout, currently OX does it in this way: http://openxava.wikispaces.com/view_en and controller, OX does it in this way: http://openxava.wikispaces.com/controllers_en Maybe, this proposal is technically impossible, or it's outside of the Naked Objects strategy. But, maybe not. This offer can include other model driven frameworks as Trails, RomaFrameworks or JMatters. What think about this the Naked Object team ? What think about this the Naked Object community ? Regards, Javier Paniza |
|
By: Dan Haywood (dkhaywood) - 2008-04-22 00:08 |
| Hi Javier, Thanks for the post. What you'll be interested to hear is that we (and by 'we' I mean Robert Matthews, the chief architect of NOF, and myself as the only non-NOGL employee who is also a committer to the NOF) have been working to make the NOF more flexible in precisely this regard. We use the term "programming model" for the set of naming conventions and annotations that make up the meta-model. Unlike some of the frameworks you mentioned, the NOF builds its own meta-model independently of - say - Hibernate's HBM. This is done using a component called the "reflector", because it, erm, uses the java reflection APIs to build up said meta-model. I suspect that OpenXava works the same way. In Naked Objects 3.1 the reflector has been rewritten so that it is extensible. Basically each annotation or similar convention is represented as a facet. So, saying that a property "FirstName" has a @MaxLength(15) would be picked up by a MaxLengthFacetFactory which would attach a MaxLengthFacet onto this property in the metamodel. Similarly, if one writes a validateFirstName(String) supporting method then this is picked up as a ValidateFacet, again attached to the FirstName property. (You might recognize this as the extension object pattern, much used in the Eclipse API with its adapters). The extensibility comes in because new facet factories can be easily plugged in as required. If we wanted to support the Hibernate Validator @Length(max=...) annotation, we would just need to write a new implementation that would install its own MaxLengthFacet (assuming that the semantics are the same). You mentioned JSR-303. I've just had a quick look at the early access draft. For those reading this who aren't familiar (as I wasn't), the idea is to annotated one's own annotations (eg @NotNull) with a @javax.validation.ValidatorClass annotation that references an implementation of javax.annotation.ConstraintValidator. Thus, prior to saving/updating, all constraints are checked. To me, this looks exactly like the kind of thing that we would want to support, and facets should make this pretty easy to support. What I suggest you might want to do is go ahead and add support to OpenXava for JSR-303, and I will look at adding this as an (optional) component for Naked Objects. In fact, it'd make a good chapter in the book I'm currently labouring on covering Naked Objects. Regarding your broader idea of defining a standard programming model across all NO-like frameworks, that really is one for Richard and Rob (the founders of NOGL) to answer. However, I would doubt that it is that high up their agenda. What I can say is that in general we're really quite happy with the programming model that we have in NOF 3.0; it's taken a long time to evolve to where it is. Looking at the OpenXava programming conventions, I suspect for example that Richard wouldn't be that keen on having separate action classes (as opposed to simple public methods which is what the NOF itself uses). That said, there are a few ideas in OpenXava that I really quite like. One is your @View and @ReferencedView annotations - that's a nice approach (though repeating the names of properties in these annotations strikes me as fragile and violating the DRY principle). You also have support for suppressing properties in table views, which NOF doesn't yet have. Notwithstanding, there would be nothing to prevent you teaching the NOF about the OpenXava programming conventions by writing some facet factories yourself, once we release NOF 3.1. There is actually another deeper synergy which might exist, which would be to combine your meta-model builder with our reflector, perhaps by basing it on our reflector. In fact, I've been toying with the idea that the NOF reflector ought to be a mini-standalone project in its own right, so that one could write an Ant task to validate a collection of domain models as part of a build. For example, in OpenXava you would want to make sure that every @ReferencedView does indeed reference a @View that exists. HOWEVER, I'm getting somewhat above my station here; such a reworking really need agreement from Rob. I suspect that Richard and Rob will follow up with their own thoughts on your proposition. For myself I'm happy to continue the discussion either here on the forum or via email. Cheers Dan |
|
By: Javier Paniza (javierpaniza) - 2008-04-24 10:33 |
| Hi Dan, > ... uses the java reflection APIs to build up said meta-model. > I suspect that OpenXava works the same way Yes. OpenXava works in that way. > The extensibility comes in because new facet factories can be easily plugged in as required OpenXava has not so great flexibility for the parsing of classes and annotations, it just parse a fixed meta-model. But, NO extensibility is an open door to take the first step of my proposal. Only if NakedObjects would implement JPA and Hibernate Annotation, we will have some degree of portability for applications between two frameworks. > What I suggest you might want to do is go ahead and add support to OpenXava for JSR-303, > and I will look at adding this as an (optional) component for Naked Objects. It's a very good start. > Regarding your broader idea of defining a standard programming model across all NO-like frameworks > I would doubt that it is that high up their agenda Yes. I know. But, We can work in order to grow the common part. That is, we can start with JPA and JSR-303 (or Hibernate Validator?), then try to use a common annotations for defining way, and left the controller part as not shared. > prevent you teaching the NOF about the OpenXava programming conventions Me, or someone from NakedObjects or OpenXava community. > to combine your meta-model builder with our reflector OpenXava parser read the OX meta-model from java + Annotations and from XML business components. Is the later supported by your "reflector"? Two question about NO 3.1, Will it support JPA ? Will it support Hibernate Validator annotations ? Thanks Dan for listen the proposal, and for your comments. Cheers Javier |
| Javier Thank you for your posting. I have been aware of OpenXava for some time, though I haven't used it. There is now a large, and growing, number of frameworks that claim some similarity to Naked Objects. Some of these have explicitly been inspired by Naked Objects, but aim to change or extend the idea in some way. (We have always encouraged this.) Others have been inspired independently. However, I am not always convinced of the similarity. A lot of these frameworks I would categorise as providing an 'Auto-generated CRUD UI'. That label isn't intended as a criticism: auto-generated CRUD UI is an idea whose time seems to have come. The basic idea is, of course, not new, but what is new is that most of these frameworks are now doing it by reflection rather than by code generation. More recently they have started to add the reflective recognition of validation/constraint logic, and, to a lesser extent, for adding functional behaviour. Because Naked Objects was one of the first frameworks to push these ideas this is where they see the similarity. However, Naked Objects did not arise from the question of how can we generate a UI automatically from either a database or an entity object model. It arose from two things: 1. Trying to understand why people paid only lip-service to the idea of encapsulating all business behaviour as methods on those entity objects, which was the clear original intent of OO. This was the starting point for my PhD thesis (http://www.nakedobjects.org/downloads/Pawson%20thesis.pdf ). 2. Trying to understand how to build more 'expressive' (problem-solving) styles of user interface. This research, which I conducted in the late 1990s, concluded that the key was true object-oriented user interfaces, of which the best work ever done, IMO, was IBM's ill-fated CUA. The Naked Objects pattern arose from the single insight that these two problems could actually be the solution to each other! Sorry for the mini history lesson but it is important that you understand that the idea of behaviourally-complete objects is absolutely definitional to Naked Objects. As Dan said in his posting, we have evolved the Naked Objects Progamming Model over the last eight years with this single goal in mind. Most of the frameworks that compare themselves to Naked Objects do not share this goal. That doesn't make them wrong (necessarily!) but it is important to bear in mind. Interestingly, the one framework that really did share this obsession was called Essential and was started by Dan himself, who was extremely familiar with Naked Objects having worked with us (and still does) at the Irish government. With Essential he wanted to take the ideas even further, but in the same direction. I was eventually able to persuade Dan not to pursue an independent framework but rather to contribute the best of his ideas into Naked Objects. Some of the key changes between Naked Objects 2.0 and 3.0 came from that joining of forces, as have many of the key ideas in the forthcoming 3.1, which I think we can safely say is far better than either Essential or Naked Objects would have been on their own. I am spelling this out because I don't want you to think that we are resistant to outside influence, even to substantial outside influence. That collaboration has ultimately worked because, though we often argue about particular ideas, we were convinced that Dan was in fact passionate about the same fundamental ideas. We are keen to open up Naked Objects further, indeed we recognise that we must. But all proposed changes in direction will be judged against that very clear vision. If you think that OpenXava really does share that clarity of vision, then I would strongly encourage you, as Dan did, to throw in your towel with Naked Objects and add to Naked Objects those unique capabilities that you have that could take it further. If you don't share that same vision, then I wish you all the very best for OpenXava. In the short run I predict that the auto-generated CRUD UI, extensible with functional behaviour, will prove to be a more popular than Naked Objects, which has been described as the most opinionated of all the 'opinionated frameworks'. But we have seen the promised land, and we ain't turning back from it now ;-) Kind regards Richard |
|
By: Javier Paniza (javierpaniza) - 2008-04-24 11:25 |
| Hi Richard, > Others have been inspired independently. I think OX is in this group. OX started as an active code generator from XML definitions in 2001. > Most of the frameworks that compare themselves to Naked Objects do not share this goal. OpenXava does not share the Naked Objects 2 basic principles. About 1: All behaviour in model objects. Look at the comment in OX documentation: http://openxava.wikispaces.com/model_en#toc17 Yes, I encourage OX developer to put all business logic in method of model classes. But, some logic is behaviour logic, NOT BUSINESS LOGIC, and it's more practical to put this behaviour logic in another place other than model classes; in the controller. For example, when you save an object to database, the way you use for saving is not business logic, you can saving using JPA or JDBC, or calling to a web service. Moreover, this logic can be reuse for all model classes. Therefore it's better separate this logic from model. Or, after save maybe you want to clear the view, or maybe not. Also, this is not business logic. It's useful separate business logic (in model classes) from behaviour logic (in actions). About 2: OO user interface. This is a good idea. I like it. But if you have a controller layer, you can choose to use an OO user interface, or whatever other, and you can change it. I want create from the same model an OO User Interface, a classic business applicationn style user interface, and a simple web wizard style user interface. That is, an OO user interface is only an option, but not the only one option. The OpenXava principles are: 1. Business Component: All resources about a business concept in the same place. As opposite to the classic MVC approach. 2. Declaring instead of programming: A way to obtain productivity. All above comments are my personal opinion, and I know that your opinion is different. Really, our frameworks have different histories and principles, but you have to admit that currently (at least in April 2008) the shape of the source code for producing a NO and an OX application is very alike, is it ? We can concentrate in this "common" part. > If you don't share that same vision, then I wish you all the very best for OpenXava. Yes. I don't share that same vision, although this is not impediment for synergy betweedn NO and OX. Keep these ideas in your mind. Who's know ? Maybe in the future you change your mind, or maybe I change my own mind. Cheers Javi |
