Yup, not over-complicated but simply intuitive is what I after. The reason I find Empire-db more appealing than static configuration based persistence framework is the same for Wicket vs Struts2. I'm not sure how good empire-db-struts2 is but I'm definitely not going to bother much on template based web framework. Unfortunately I haven't started anything yet, so can't provide much feedback to you guys. I'm sure to keep you all updated.
On Thu, Feb 5, 2009 at 7:40 PM, Rainer Döbele <[email protected]> wrote: > Hi bachew, > > yes sounds interesting, although with so many frameworks to have to carful > not to make things over-complicated. > > Redarding wicket: I think Wicket and Empire-db could be a very good > combination. We had a student who was willing to this for his dissertation > project but unfortunately he could't find a professor for this topic and had > to take something else. > > The basic approach for Wicket could be similar to the one we've taken for > our Struts2 intergration. > If you need any assistence here I might be able to provide you with some > useful hints. > > Rainer > > > -----Ursprüngliche Nachricht----- > > Von: Francis De Brabandere [mailto:[email protected]] > > Gesendet: Montag, 2. Februar 2009 13:22 > > An: [email protected] > > Betreff: Re: More history of Empire-db > > > > Hi bachew, > > > > Interesting to see you're integrating Wicket and Empire-db, I'd like > > to know how you are handling the integration. Keep us updated on your > > progress! > > > > On Mon, Feb 2, 2009 at 8:21 AM, bachew <[email protected]> wrote: > > > Hi, > > > Thanks for the details. Actually as an sane object oriented programmer > > came > > > from C++ like you, I understand that API is above everything, metadata > > > (annotation and XML) are very well just implemented using API. To use > > JPA > > > would mean I'm stuck without the ability to intuitively get metadata in > > > runtime. People were trying to pretend that SQL does not exist, but we > > all > > > know it will exist for a very long time. > > > I need SQL abstraction library but I don't have the time to write it, > > > Empire-db looks exactly what I need, I haven't tried it though, will > try > > > once I'm back from holiday and finished up tasks at hands. > > > Actually I have been gathering like-minded projects, like-minded in > > terms of > > > focus on getting API right, making most, if not everything dynamic. > > We've > > > got Guice for dependency injection, Wicket for web framework, Jetty for > > > embedded web server, Restlet for REST service and hopefully Empire-db > > for > > > database. > > > > > > I'm not building something sophisticated, just want a real object > > oriented > > > Java application framework to save our fellow Java developers precious > > time. > > > It's simply sickening for me to maintain someone else's applications > > written > > > in JPA, struts, JSP, JSF, spring moster xml, etc. > > > On Sun, Feb 1, 2009 at 6:39 PM, Rainer Döbele <[email protected]> > wrote: > > >> > > >> Hi bachew, > > >> > > >> we're glad to hear that you like Empire-db. We really believe it's the > > >> best thing since sliced bread and we hope more and more people will > see > > the > > >> advantages. > > >> > > >> About the history: > > >> The basic idea, i.e. to describe the data model using classes and > > objects > > >> goes back to the middle of the 90's. At that time I was developing > > document > > >> management solutions under Windows using C++ and MFC. Back then I > wrote > > the > > >> first attempt for a relational data persistence layer in C++. > > >> > > >> In 2000 me and my partner founded our company ESTEAM Software now > > focusing > > >> on developing Web-based applications in Java. For our first big > project > > I > > >> used all the ideas from my C++ implementation to build a data > > persistence > > >> layer in Java. Since then we have used and improved the library (I > > don't > > >> want to use the word 'framework' in this context) in many > fundamentally > > >> different applications such as CRM-tools, DataWarehouse utilities, > > >> Supply-Chain-Management etc. and for both Web and Rich-Client > > applications. > > >> Besides the Java implementation we also have a C# implementation; > > however we > > >> have not yet found the time to separate it from other stuff and make > > the > > >> necessary refactorings to match it with our Java Empire-db. We might > do > > that > > >> I we find there is demand for it. > > >> > > >> Most applications that we have implemented were relying heavily on > data > > >> gathered from various tables by complex queries with varying > > constraints and > > >> joins which are built at runtime. Also as applications and data model > > change > > >> we needed something that gives us maximum security that when we change > > the > > >> model the application will still work - or the compiler should give us > > an > > >> error. This is why we tried to avoid using strings for column or table > > names > > >> completely - except for the model definition of course. > > >> This has many times saved our lives and I really can't see how people > > >> could possibly survive with traditional OR-Mappers except for the > > simplest > > >> type of database activity. > > >> > > >> Finally about the name: > > >> This is a rather boring story. First, as we had the 'e' for our > jsp-tag > > >> library originally taken from our company name "ESTEAM" we were > looking > > for > > >> a name that also started with an 'e'. Second it had to be a simple > word > > as > > >> we couldn't think of a suitable idiom. And finally since my kids have > > made > > >> me live in a parallel Star Wars universe for the last couple of years > > >> "Empire" was the closest match. We're not looking to become as bad as > > the > > >> Galactic Empire though. So far we're only just rebels in the universe > > of > > >> relational data persistence. But we're determined to take on all these > > >> Hibernates and JPA implementations out there and maybe one day we will > > make > > >> the world a better place :-) > > >> > > >> The two example applications provided with the core and the web-demo > > >> application provided with the struts extensions should give you a good > > idea > > >> about most of the functionality and how to apply it. However most > > people > > >> when starting to use Empire-db make things more complicated than > > necessary. > > >> So if you face any difficulties or think there must be a shorter > easier > > way > > >> to achieve something don't hesitate to ask. > > >> > > >> On the other hand we are curious to hear what kind of solution you > have > > >> implemented with Empire-db. > > >> Best regards > > >> > > >> > > >> Rainer > > >> > > >> > > >> bachew wrote on Fr 30.01.2009 03:18 > > >> > Re: More history of Empire-db > > >> > > > >> > Hi, > > >> > The first entry in the FAQ answered part of my question - > > >> > http://incubator.apache.org/empire-db/empiredb/faq.htm. But I would > > like > > >> > to > > >> > know more about the history of Empire-db, the people and the > > >> > organization > > >> > behind this interesting library. How it improves over the years and > > what > > >> > kinda applications that Empire-db is written for. And erm... why > name > > it > > >> > Empire-db? > > >> > > > >> > Hard to believe that someone finally did what I have in mind and > this > > >> > > > >> > page<http://incubator.apache.org/empire- > > db/empiredb/hibernate.htm>explained > > >> > what I always wanted to explain to people. I'm planning to write > > >> > an application framework and it seems my only choice is Empire-db on > > >> > database side, I wish to know more about it. > > >> > > > >> > Thanks in advance. > > >> > > > > > > > > > > > > > > > -- > > http://www.somatik.be > > Microsoft gives you windows, Linux gives you the whole house. >
