Hi James! > -----Mensaje original----- > De: James Strachan [mailto:[EMAIL PROTECTED]]
[...] > One other thing to keep in the back of your mind when you're > refactoring things. Once its in CVS somewhere - hopefully the > sandbox or > failing that sourceforge - I'd be quite interested in adding > support for > 'real' beans. Yes, I also think that coding beans is better than writing XML files. My original query was along these lines. If you remove a field from a bean and keep using it elsewhere, the compiler will tell you; but if you delete a field from the config file and keep using it, you get an exception at runtime. That has been my experience: it's better to have strongly typed attributes than an abstract database layer. Now, if we can have both, it would be great. Un saludo, Alex. > I think DynaBeans are perfect for queries and for when the > Java object model > is dictated by the database schema. Its also very common to > need to write a > web app for an existing database, where hand coding beans to > represent the > database is a wasted effort. Though it would be nice to > support the other > way around as well, that Java business objects are written > first and Simper > gets used to persist them and that the database schema comes > secondary. > > The Simper code is mostly based on DynaBeans and its pretty > easy to wrap a > DynaBean around a real bean so I'm hoping that mostly Simper > won't really > know if real or dyna beans are being used. To get the 'mark as dirty' > features in your SimperBean we could use BCEL or JDK1.3's > dynamic proxy > to generate wrappers that detect when bean setters are > called. The nice > thing about this would be we could > use Simper to persist any Java Bean, as well as DynaBeans. There's an > object-relational can of worms that this could open but > hopefully we'll be > able to keep it simple. > > BTW I keep wanting to type Simpler rather than Simper. The > project name > didn't start out as a typeo did it ;-) > > James
