RIFE/Crud 1.0: CRUD scaffolding for RIFE released

Discussions

News: RIFE/Crud 1.0: CRUD scaffolding for RIFE released

  1. RIFE/Crud 1.0: CRUD scaffolding for RIFE released (60 messages)

    RIFE/Crud is an extension for RIFE that automatically creates CRUD web applications from POJOs. No files are generated, everything is performed at runtime. Individual parts can easily be overridden and thanks to RIFE's flexible site structure, integration into your own application's data and logic flows is seamless and intuitive.

    While several efforts already exist in this area, this is the only one that's completely run-time based without code generation. The benefit is that you can actually rely on the automated behavior without having to manually merge changes when new versions of the project are released.

    Below is a list of some of RIFE/Crud's features:
    • Automatically generates administration functionalities for tedious, repetitive CRUD operations
    • No code generation
    • Completely runtime-based
    • Driven by your domain model beans
    • RIFE's powerful meta-data facility gives total control over the data and content formats
    • Builds on RIFE's web component model
    • Optionally generates your database structure
    • Supports association, aggregation and many-to-one relationships
    • Optionally generates the navigation menu of all CRUD operations
    • Can be integrated into any other RIFE site
    • Clearly defined nomenclature to refer to run-time generated components
    • Fully customizable:
      • built-in support for localization
      • layout through well-structured CSS
      • markup is driven by templates, they can be replaced in different levels of granularity
      • CRUD API for reusing most of the automated run-time features during customization
      • replacement of individual CRUD components
      • customizable menu generation
      • RIFE features like callbacks are still available
    • Scripting support
      • Groovy
      • Janino
    A simple and quick overview can be found in the Getting started section of the documentation.

    We created an introduction and tutorial video for EuroOSCON 2005 that provides a more complete overview of the capabilities.

    The downloads section contains a large collection of examples and a complete real-world application, eCalendar, as a demonstration of the customizability and the integration with custom components.

    Threaded Messages (60)

  2. Code generation[ Go to top ]

    Why is so bad code generation?

    JSP technology uses code generation and a lot of people use it without falling dead.

    Yes, yes. Using xdoclet for generating 50 EJb beans code with its xml files, is not agile. I admit that.

    But in some cases code generation has advantage over instrospection. For example, imagine that your need that your CRUD module runs inside a portal, maybe generate the portlet.xml is good idea. Or your need that your pojos uses Hibernate instead EJB3 (or viceversa) maybe generate the mapping xml files is good idea.

    Anyways, congratulations for you CRUD generator.
  3. Code generation[ Go to top ]

    Nothing prevents you of course to use any code generators to generate something from the same sources.

    The downside of code generation for reusable logic is that you want to extend or override parts of it. If you do that in the generated source code, you'll have to carefully merge your modifications with any newly generated code when a new version of your tool is released.
  4. Code generation[ Go to top ]

    The downside of code generation for reusable logic is that you want to extend or override parts of it. If you do that in the generated source code, you'll have to carefully merge your modifications with any newly generated code when a new version of your tool is released.

    The solution is to use a pure active code generation, that is, the generate code is never touched by the programmer. And for inserting custom behaviour in to generated system, you can use the GoF strategy pattern.
    This technique works for me for years, you can see it in OpenXava

    I think that the ideal is mix introspection with code generation.
  5. When source code have to be generated, you can generate something what we call cross inheritance. We are generating from UML than for simple explanation: In your model you have two classes A and B. B is inherited from A. You will generate A, AImpl extends A, B extends AImpl, BImpl extends B. Classes A and B are always fully regerated and classes AImpl and BImpl should be rewriten by programmers. All generated methods like getters, setters, abstract declarations are generated to A and B. Using this trick for more than 6 years now.
  6. Code generation[ Go to top ]

    The downside of code generation for reusable logic is that you want to extend or override parts of it.
    There is a simple workaround for that: only generate base classes and have users subclasss and override them.

    It's so simple and flexible I'm surprised not more frameworks use this technique.

    --
    Cedric
  7. Code generation[ Go to top ]

    The downside of code generation for reusable logic is that you want to extend or override parts of it.
    There is a simple workaround for that: only generate base classes and have users subclasss and override them.It's so simple and flexible I'm surprised not more frameworks use this technique.-- Cedric

    or also generate the subclasses when they not already exist. Those are empty ready to be extended. Very comfortable.
  8. Code generation[ Go to top ]

    The downside of code generation for reusable logic is that you want to extend or override parts of it.
    There is a simple workaround for that: only generate base classes and have users subclasss and override them.It's so simple and flexible I'm surprised not more frameworks use this technique.-- Cedric
    or also generate the subclasses when they not already exist. Those are empty ready to be extended. Very comfortable.
    Indeed. When you start going down that road, the only challenge is to decide what parts should be subclassed and what hooks you should expose. But it's a much easier problem to solve than making sure the user is not overwriting code that will be deleted at the next iteration.

    --
    Cedric
  9. Code generation[ Go to top ]

    Well in this case, this isn't needed, the implementations a generic and adapt to the constraints. The views are generated at runtime, but there you don't have Java inheritance with base classes and such. You could figure out some way to still do that, but it's not needed for RIFE/Crud. So have a lot less artifacts to worry about.
  10. Code generation[ Go to top ]

    I forgot another big advantage, since everything is done at runtime, you don't have to restart or recompile anything to see your changes. Just modify something and reload.
  11. Code generation[ Go to top ]

    I forgot another big advantage, since everything is done at runtime, you don't have to restart or recompile anything to see your changes.

    ... and you also see any errors at runtime. But maybe RIFE/Crud has built-in facilities to test the non-existing code. Of course, at runtime.
  12. Code generation[ Go to top ]

    ... and you also see any errors at runtime. But maybe RIFE/Crud has built-in facilities to test the non-existing code. Of course, at runtime.
    Yes, most errors you see will be related to the meta-data you attach, so they can almost always only be evaluated when trying out the results. Since your domain model drives the CRUD logic, you can use your beans as usual to test anything related to them. As far as the functional testing goes, you can certain add tests for these, but all CRUD functionalities will be auto-generated, that's the point, no? Any additional logic or components can be tested as usual.
  13. RIFE and AJAX?[ Go to top ]

    Does RIFE have AJAX support?
  14. RIFE and AJAX?[ Go to top ]

    Does RIFE have AJAX support?
    There are no Rails-like helper classes that are in the core of the framework, however, it's very easy to use any Ajax library. Prototytpe and Scriptaculous have been used successfully, and it looks like integrating DWR is very easy. I might look at bundling a standard component for that in the next version.
  15. Excellent. I shall try it out.
    Driven by your domain model beans
     
    Optionally generates your database structure

    Definitely doing things the right way, from my point of view.
  16. POJOs?[ Go to top ]

    What's so POJO about this?

    From the eCalendar example application:

    <code>public class Author extends CmfValidation</code>

    Requiring the extension of a framework class is not exactly supporting POJOs.
  17. POJOs?[ Go to top ]

    I will work with POJO's except that you have no additional meta-data.
    You can also implement the Constrained interface and use composition for instance to provide the constraints, extending the base class is just a handy shortcut if you can use it. We're also working on supporting annotations.
  18. Re: POJOs?[ Go to top ]

    Using annotations is your best bet, IMHO. If you use annotations, you can put in annotations to adapt your domain model to other frameworks (like Trails). If you use framework class extension, your domain model is stuck with one framework!

    Being able to "webify" a totally isolated (don't have the source code) domain model would be pretty cool, too! I can see a couple of options there:

    1. Introduce a configuration file (probably XML-based).

    2. Expose your configuration objects via some API so that I can write code that describes my model classes.

    Many folks have complained lately that we're using too much XML these days, though. Of course, if all of these options are available, you can maybe please everyone! :-)
  19. Re: POJOs?[ Go to top ]

    Using annotations is your best bet, IMHO. If you use annotations, you can put in annotations to adapt your domain model to other frameworks (like Trails). If you use framework class extension, your domain model is stuck with one framework!

    Correct, there is some interesting talk going on between us web framework authors to try to standardize a set of 'standard annotations'. That will be a nice step forward too.
    Being able to "webify" a totally isolated (don't have the source code) domain model would be pretty cool, too! I can see a couple of options there:1. Introduce a configuration file (probably XML-based).2. Expose your configuration objects via some API so that I can write code that describes my model classes.

    I was actually thinking of using a convention-based approach here+ For instance if you have your Foo bean, a FooMetaData class would provide the additional information. This should provide the expressiveness of doing it in Java, while still decoupling it from the actual domain model implementation.
    Many folks have complained lately that we're using too much XML these days, though. Of course, if all of these options are available, you can maybe please everyone! :-)

    Hehe :-)
  20. Re: POJOs?[ Go to top ]

    Chris Nelson (creator of Trails) and I have discussed trying to come up with some standard annotations that describe the "visualization" attributes of classes/properties and using those in Trails. Then, other frameworks (maybe one that generates Swing GUIs) could use the same attributes.

    I like the MetaData class idea. That could work, too. Maybe you could come up with some discovery logic:

    1. Check your metadata repository to see if the class' metadata is already there.

    2. Look for a <class name>MetaData class in the same package as the class.

    3. Look for a global META-INF/MetaData.xml file as a classpath resource.

    4. Look for a <class name>MetaData.xml file as a classpath resource in the same package as the class.

    Once you "discover" the metdata, you'd put it into the repository. Of course, you would also need to expose your repository via some API, allowing users to put the metadata in by hand.
  21. Re: POJOs?[ Go to top ]

    I like the MetaData class idea. That could work, too. Maybe you could come up with some discovery logic:1. Check your metadata repository to see if the class' metadata is already there.2. Look for a <class name>MetaData class in the same package as the class.3. Look for a global META-INF/MetaData.xml file as a classpath resource.4. Look for a <class name>MetaData.xml file as a classpath resource in the same package as the class.Once you "discover" the metdata, you'd put it into the repository. Of course, you would also need to expose your repository via some API, allowing users to put the metadata in by hand.
    Sounds like you picked my brain and sucked my plan right out of it ;-)
  22. annotations as decorations[ Go to top ]

    I tried to do an auto-CRUD thingy in my spare time. Aside from the vagaries of various ORM mappings, the problem of code-decodes, field validations (and providing hooks for complex ones outside of the validation operations of say, the struts validator) throws the autogeneration sky-high in terms of configuration/annotation.

    The amount of annotation required to decorate a domain class became too ugly, to the point I didn't like annotations at all because they really represent the intrustion of an external concern upon an object. In real-world terms, this is an appropriate compromise for objects whose raison d'etre is simply a data deserialization and nothing else, but the practical value of placing so much configuration into a simple bean became ugly and I started getting that weird feeling I get when something is being done fundamentally wrong, and I've been getting that consistently whenever annotations are suggested.

    I think they should only be used in the context of java code when they are done in a purely decorator pattern, as in the original code to be annotated is extended, and the annotations placed there, with pass-through methods as necessary.

    But that's not any different than a separate decoration xml file.

    Round and round I go.
  23. Re: POJOs?[ Go to top ]

    Adapters ?
  24. Re: POJOs?[ Go to top ]

    1. Introduce a configuration file (probably XML-based).2. Expose your configuration objects via some API so that I can write code that describes my model classes.

    Why don't we store configuration in the database. That configuration is then persisted by hibernate or whatever. That way you instantly have your API to program to.

    The biggest problem currently for writting true runtime CRUD, that is with subtables reflecting collection data, is that you don't know the type of class data that the collections hold. I store all this meta-data in a tablemodel configuration wich is just another POJO bean stored in the database. That tablemodel can be used to generate hibernate.xml or ojb.xml or ejb annotations. This way you can work ORM independent.
  25. Re: POJOs?[ Go to top ]

    Why don't we store configuration in the database. That configuration is then persisted by hibernate or whatever. That way you instantly have your API to program to.
    because then we would have to config hibernate metadata to store pojo metadata... metadata of metadata!

    Jokes aside, I've already thought about some way of unifying all these mappings we have now (from domain to DB for persistence, domain to screen for client/web apps, domain to domain for EAI...). All of them include some way of data validation, data conversion, and other common stuff. I hope some day it will be possible to have one dynamic metadata to rule them all.

    Regards
  26. Re: POJOs?[ Go to top ]

    because then we would have to config hibernate metadata to store pojo metadata... metadata of metadata!Jokes aside

    that actually is not a joke you make there. You enter meta-meta area then. Can get very confusing but xtrmly powerfull. A tablemodel's Tablemodel is a tablemodel Tablemodel;-)
  27. Re: POJOs?[ Go to top ]

    because then we would have to config hibernate metadata to store pojo metadata... metadata of metadata!Jokes aside
    that actually is not a joke you make there. You enter meta-meta area then. Can get very confusing but xtrmly powerfull. A tablemodel's Tablemodel is a tablemodel Tablemodel;-)
    I know! I once said here that the ultimate solution to every IT problem is to just add another layer of indirection (higher abstractions), but some laughted at me... ;)
  28. Howdy All,
    While several efforts already exist in this area, this is the only one that's completely run-time based without code generation.

    That's a pretty broad claim - "the only one."

    What context are they referring to - "in this area"?

    I believe WebObjects has had completely run-time based CRUD for Web applications with a HTML-based interface for many years now. It's called DirectToWeb and allows full rule-based customisation.

    Not to mention the completely run-time based CRUD for Web applications with a Java client interface (ie the Java GUI is generated at run-time too). It's called DirectToJavaClient and allows full rule-based customisation.

    Cheers,
    Ashley.

    --
    Ashley Aitken
    mrhatken at mac dot com
    Perth, Western Australia
  29. Right, I suppose I had to specify the 'open-source web application' context.
  30. BTW this auto CRUD stuff is a really good thing. A web framework without it should be considered useless and should not even be looked at. This should be standard.
  31. BTW this auto CRUD stuff is a really good thing. A web framework without it should be considered useless and should not even be looked at. This should be standard.

    +1. I'd like thank the RIFE team for their hard work! I'm really impressed.
  32. I'd be curious about best ways to integrate new code using rife for an existing application that uses struts.
    Struts isn't going away and there must be creative ways to introduce these new frameworks
  33. I'd be curious about best ways to integrate new code using rife for an existing application that uses struts. Struts isn't going away and there must be creative ways to introduce these new frameworks
    Actually it depends on which level of integration you're talking about, but since RIFE works with one gateway servlet or filter, you can use web.xml and integrate application parts just there. RIFE also has an abstracted way to do dependency injection, which means that you can use the same reference factories (Spring, Pico, ...) as the rest of your application, if that's appropriate.
  34. Thanks for the great tutorial. It made it much easier to understand the ideas behind the framework.

    Looking at your other sub project RIFE/Laszlo, I got curious about whether there has been any discussions/thoughts on creating the scaffolding with OpenLaszlo?

    To be able to generate the swf file automatically would be very powerful...
  35. Thanks for the great tutorial. It made it much easier to understand the ideas behind the framework.Looking at your other sub project RIFE/Laszlo, I got curious about whether there has been any discussions/thoughts on creating the scaffolding with OpenLaszlo? To be able to generate the swf file automatically would be very powerful...
    Hi,
    we've been looking into using the same meta-data to generate declarative UIs for rich internet applications. This could map to OpenLaszlo's LZX or to Thinlet, for instance. We're still in the initial phase of this and only made a prototype for the data-binding through REST services. After meeting Keith Donald at Java in Action though, we noticed that some of the goals were the same as Spring RCP, so we're going to look first at the possibility to combine the efforts there.
  36. declarative UIs[ Go to top ]

    so we're going to look first at the possibility to combine the efforts there.

    +1 for efficiency. while you are at it, would you consider XUL or derivatives thereof? it might not be the best but it's open-source.

    Regards
  37. declarative UIs[ Go to top ]

    so we're going to look first at the possibility to combine the efforts there.
    +1 for efficiency. while you are at it, would you consider XUL or derivatives thereof? it might not be the best but it's open-source.Regards
    We've had bad experiences with XUL performance-wise, so I'm quite reluctant to put any effort into supporting it.
  38. This is a great effort, and I'm happy to see other frameworks entering this space. I would respectfully ask that you not claim RIFE/CRUD is the "only" framework to do it's thing without code generation. Trails has done this since the project started over a year ago.

    Very nice work though, and I'll chime in with Jim and say that if there was a way to collaborate and come up with a "standard" way to do metadata I'd be all for it.
  39. Trails my have this capability but it's not released yet. Generally, firsts and whatnot are granted to released versions of products only.
  40. This is a great effort, and I'm happy to see other frameworks entering this space. I would respectfully ask that you not claim RIFE/CRUD is the "only" framework to do it's thing without code generation. Trails has done this since the project started over a year ago. Very nice work though, and I'll chime in with Jim and say that if there was a way to collaborate and come up with a "standard" way to do metadata I'd be all for it.
    Afaik, Trails generates code and there are actual ant tasks for this. To see the changes you also need to rebuild and redeploy the entire project. For me that's not run-time based.
  41. No, Trails does NOT generate code[ Go to top ]

    Geert,

    No, Trails does not generate any source code at all. The ant targets give you a basic directory structure for your project and give you a skeleton for a custom page template. They are conveniences only. Trails builds the UI at runtime based on metadata and reflection. Some of the metadata currently comes from annotations, so yes, you do need to recompile to see it. However, since the metadata service is injected via Spring, it would certainly be possible to build one that got it's metadata from elsewhere. I'm not sure how the rebuild issue is significant though, since if I am building a UI based on a POJO and I change it (add a property for instance) I am ALWAYS going to have to rebuild to see those changes. Maybe I am missing something?
  42. No, Trails does NOT generate code[ Go to top ]

    Ok, sorry, that didn't come over correctly to me then. Yes, currently in Java, you need to redeploy if you change the methods of a class. However, if you merely change the meta-data, you can use hot-swap and RIFE/Crud will detect the changes.
    Apart from this, we also support Groovy and Janino for implementing your domain models, in that case they are automatically reloaded for any change you make (including added properties). We still need to figure out a way to make it easy to migrate the DB schema according to property changes though.
  43. No, Trails does NOT generate code[ Go to top ]

    Yes, currently in Java, you need to redeploy if you change the methods of a class.
    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods. I'm looking forward when sun allow even those classes to be replaced on the fly in JVM. What than will be advantage of dynamic languages?
  44. No, Trails does NOT generate code[ Go to top ]

    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods.

    That's what I meant.
    I'm looking forward when sun allow even those classes to be replaced on the fly in JVM. What than will be advantage of dynamic languages?

    Me too, it would be really cool to have that. Did you vote on the bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812
  45. Yes, currently in Java, you need to redeploy if you change the methods of a class.
    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods. I'm looking forward when sun allow even those classes to be replaced on the fly in JVM. What than will be advantage of dynamic languages?

    there will be no advantages. We will then have the best of both worlds and I will never leave.
  46. No, Trails does NOT generate code[ Go to top ]

    Yes, currently in Java, you need to redeploy if you change the methods of a class.
    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods. I'm looking forward when sun allow even those classes to be replaced on the fly in JVM. What than will be advantage of dynamic languages?
    there will be no advantages. We will then have the best of both worlds and I will never leave.

    Then, quick, go and vote for bug 4910812 :-)
    (Enhance Hot Code Replacement):
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812
  47. No, Trails does NOT generate code[ Go to top ]

    Yes, currently in Java, you need to redeploy if you change the methods of a class.
    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods. I'm looking forward when sun allow even those classes to be replaced on the fly in JVM. What than will be advantage of dynamic languages?
    there will be no advantages. We will then have the best of both worlds and I will never leave.
    Then, quick, go and vote for bug 4910812 :-)(Enhance Hot Code Replacement):http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812

    I already did so a while ago, Geert blogged about it. I didn't know it was a bug. It is not really a bug because it is in the top 25 rfe now, so it is considered a feature. It being in the top 25 does mean shit though, it can be number one for ten years and still nothing happens. We should make SUN aware somehow that we cannot live without this, at least i can't. DOS attack's until they surender might be a valid option, or am i going to far now;-)
  48. ClassLoaders ?[ Go to top ]

    Yes, currently in Java, you need to redeploy if you change the methods of a class.

    It make sense IMHO.
    If you change body of method it is no problem to replace class in memory. Only problem is when you introduce new methods. I'm looking forward when sun allow even those classes to be replaced on the fly in JVM.

    Well you can already do this using ClassLoaders in most of the situations. OK it's quite a burden, but you *can* do it.
    Goold old JSPs do this since the beginning too btw.

    Can't you simply "re-create" the UI layer (it's dynamic so I guess you can) using a fresh new classloader when you want ?
    What than will be advantage of dynamic languages?

    It's already hard for me to see what *are* the real advantages of "dynamic" languages yet !!
    :-)

    Have fun,

    Remi
  49. ClassLoaders ?[ Go to top ]

    using a fresh new classloader when you want

    That road somehow always ends up dead. You will have to manage global vars or don't use 'm. And forget static vars. Even JUNIT can do this right, then why should i even try. I want my full hotswap and nothing else!
  50. ClassLoaders ?[ Go to top ]

    That road somehow always ends up dead. You will have to manage global vars or don't use 'm. And forget static vars. Even JUNIT can do this right, then why should i even try. I want my full hotswap and nothing else!

    I agree that dealing with Class Loaders almost always sucks, and believe me I hear your concern. Having this would open new doors...
    "We're currently updating your application from the network, but you can continue your work" !
    This would change from the usual "You have to restart for the changes to take effect" :-)

    Have fun,

    Remi
  51. ClassLoaders ?[ Go to top ]

    It seems that Sun is starting to hear the requests, they ask for input and a discussion about the subject in this forum:
    http://forum.java.sun.com/thread.jspa?messageID=3949087
  52. ClassLoaders ?[ Go to top ]

    It seems that Sun is starting to hear the requests, they ask for input and a discussion about the subject in this forum:http://forum.java.sun.com/thread.jspa?messageID=3949087

    Let us all mingle ;-) Really cool that we are heared.
  53. Do these vids have sound?[ Go to top ]

    I'm not getting any sound, although I had to install QT7 to get H.264 support.

    Otherwise, these are some seriously bloated ppt slides.
  54. Do these vids have sound?[ Go to top ]

    I'm not getting any sound, although I had to install QT7 to get H.264 support.Otherwise, these are some seriously bloated ppt slides.
    Sorry, there is no sound, and without H.264 these would be 70MB instead of 11MB. I plan on adding narration later though.
  55. POJOs or RDBMS?[ Go to top ]

    The tutorial brings up an issue in frameworks that provide CRUD operations

    - "RIFE/Crud can automatically create the database structure that corresponds to the constraints that your declared. Note that this is not mandatory and that RIFE's persistence layer can map the properties to existing tables."

    I completely agree that development frameworks need to include CRUD tools. But is it best to from Objects->RDBMS? Ruby on Rails seems to be embracing the opposite approach. While programmers generally think in terms of objects rather than relational tables, I haven't sensed much resistance to the notion that the database tables will define the objects...

    The best approach, as usual, depends on the task, so it seems that a flexible framework would need to give a developer the ability to move in either direction.
  56. POJOs or RDBMS?[ Go to top ]

    But is it best to from Objects->RDBMS? Ruby on Rails seems to be embracing the opposite approach. While programmers generally think in terms of objects rather than relational tables, I haven't sensed much resistance to the notion that the database tables will define the objects...

    There is at least some resistance and, in my view, with very good reason. I believe that basing data models on databases is potentially limiting in many ways. There have been major projects by Java developers to provide efficient and effective independence from databases or even from relational forms of persistence. With JDO 2.0 and EJB 3.0 we have mechanisms to do this. Some of us have waited years for such mechanisms. It would be a shame if the hype over RoR drove things backwards to a more database-centred way of working. Fortunately, it appears that there are RoR-type projects in languages other than Ruby that don't take the ActiveRecord route.
    The best approach, as usual, depends on the task, so it seems that a flexible framework would need to give a developer the ability to move in either direction.

    Agreed. I currently use a JDO 2.0 implementation that allows me to do just this.
  57. POJOs or RDBMS?[ Go to top ]

    But is it best to from Objects->RDBMS? Ruby on Rails seems to be embracing the opposite approach. While programmers generally think in terms of objects rather than relational tables, I haven't sensed much resistance to the notion that the database tables will define the objects...
    There is at least some resistance and, in my view, with very good reason. I believe that basing data models on databases is potentially limiting in many ways. There have been major projects by Java developers to provide efficient and effective independence from databases or even from relational forms of persistence. With JDO 2.0 and EJB 3.0 we have mechanisms to do this. Some of us have waited years for such mechanisms. It would be a shame if the hype over RoR drove things backwards to a more database-centred way of working. Fortunately, it appears that there are RoR-type projects in languages other than Ruby that don't take the ActiveRecord route.
    The best approach, as usual, depends on the task, so it seems that a flexible framework would need to give a developer the ability to move in either direction.
    Agreed. I currently use a JDO 2.0 implementation that allows me to do just this.

    Or Hibernate. I just don't agree with that approach With the Hibernate/Xdoclet approach it even appear possible(with some of the limited testing I've done) to have reuse our domain objects across different projects even if they have to map to different database tables.

    And you get the freedom to name what you want *what you want*.
  58. POJOs or RDBMS?[ Go to top ]

    The tutorial brings up an issue in frameworks that provide CRUD operations - "RIFE/Crud can automatically create the database structure that corresponds to the constraints that your declared. Note that this is not mandatory and that RIFE's persistence layer can map the properties to existing tables."I completely agree that development frameworks need to include CRUD tools. But is it best to from Objects->RDBMS? Ruby on Rails seems to be embracing the opposite approach. While programmers generally think in terms of objects rather than relational tables, I haven't sensed much resistance to the notion that the database tables will define the objects...The best approach, as usual, depends on the task, so it seems that a flexible framework would need to give a developer the ability to move in either direction.

    If the data in only used for display, chances are it's probably ok, but from first hand experience, other cases it doesn't work well.

    Specifically, if a system has some complex business flow/process which handles jobs in batches, a view model most likely won't be appropriate. In that case, designing the object model based on the database tables can be a real problem and cause cascading issues.

    peter lin
  59. POJOs or RDBMS?[ Go to top ]

    I big downside of basing anything on your database is that you can only express the constraints that your database offers. None of the rich meta-data is supported. You also miss the possibility to declare properties that don't map to a table column. Did you notice how we can handle file uploads and automatic transformation and storage of images into a content management framework?

    Independent from that, meta-data that's provided through JDBC drivers is very limited and most of the information that you'd expect isn't even there in many implementations.
  60. POJOs or RDBMS?[ Go to top ]

    "I big downside of basing anything on your database is that you can only express the constraints that your database offers."

    I think you just summarized why writing web applications with an rdbms backend can be such a hassle. Programming languages have n data types (int, double, String, array, etc...), rdbms's have m data types (int, varchar, text, date/time, etc...) and form input from the web has one data type - a string. No surprise that apps get messy and complicated.

    When I started learning about Ruby on Rails, it was eye-opening, and it showed me that Java programmers desperately need a better approach to scaffolding. There's a lot that the Java world can learn from ROR - and starting with the RDBMS, and making some assumptions (convention over configuration, as they say) looks very promising.

    For instance, if you have a database with a Recipes table with fields for name, description, etc... along with a one-to-many relationship with another table named Categories, then odds are exremely good that you'll want a fairly predictable class structure. The next 20+ hrs of programming are going to be very dull. But if the scaffolding can give you a skeleton of this code by making some reasonable assumptions, *along with the flexibility to alter it however you need!*, you'll be more productive. Same goes for the other direction - if you have a class named Recipe with a string for name, a int for amount,... and some kind of container for multiple instances of another class named Category, a framework that can "propose" an rdbms for you would improve productivity. Both directions seem alright to me, as long as they are flexible.
  61. Excellent stuff as usual, Geert. Congratulations.