Yeah, that's the ticket. You've got a new technology or framework you want to promulgate, insult the one's who don't get it out of the box. A bit mean-spirited, don't you think. Frankly, lift raises more questions then it answers. That's not a complaint..
I don't get it. I don't get that I have to slog through pages of source code to figure out where to hang my hooks. And my boss ain't going to pay me to do that either. To be kind, until you've got a well-documented API, all you have is a work-in-progress. You want followers, I'm exactly the kind of guy you need to talk down to. regards, Glenn... On May 17, 2:22 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > On Sun, May 17, 2009 at 2:33 AM, rintcius <rintc...@gmail.com> wrote: > > > Interesting discussion! I think I see a bit where Glenn is coming > > from. > > I'm all for interoperability... I like baseball and apple pie, too. If > there is a problem with Lift interoperating with another system or another > piece of J(2)EE infrastructure, be specific about it and we'll work on. > > To date, Glenn has complained a lot and made very little sense and has not > been specific. He's complained that you can't create a form to be submitted > to an external server that won't somehow magically execute functions defined > on your server. He's complained that Lift doesn't have its own > implementation of some JavaScript functions which are available in existing > JavaScript libraries. To date, Glenn has demonstrated little in terms of > understanding if code is executing on the server, in the browser or on some > other server. This makes it very difficult to have a coherent > conversation... and every time we've asked him for specifics, he's ignored > us or give examples that are very far off the mark. > > > To me it's about *ease* of interoperability. > > For enterprise architectures the most important question is: to what > > extent is Lift helping me to build a **composable** software system. > > A composable software system will offer gradual change from one > > architecture to another and it will make this migration easy. > > So suppose I am having a Spring based architecture with Hibernate and > > struts and want to migrate this to Lift. > > Okay... so there's a ton of documentation on the use of JPA within > Lift-based apps. Derek has written a lot of this and does a lot of support > on this list of people using JPA within Lift and Scala. Further, if you've > already got Java/JPA code, *IT JUST WORKS* inside Lift and Scala. There's > nothing to document beyond "just use it." > > > > > I think it would be a good exercise to check how such an architecture > > can be gradually migrated to a lift based architecture. > > So what to do if I just want to replace struts or hibernate. > > I personally recommend starting with building your REST APIs with Lift. > It's an easy way to get your hands dirty with Lift, you get to preserve > your existing models and it's very easy to do REST and XML/JSON within Lift > and Scala. > > > Or what > > if I want to start with migrating my POJO's to POSO's. > > Lift is not primarily focused on persistence. Lift is primarily focused on > the servicing of HTTP requests. We will help people on this list with > JPA-related stuff, but it's not the primary focus of Lift as a web > framework. > > > > > My guess is that this is all possible in Lift but I haven't seen > > anything in the code or docs that facilitates this. > > That's because it's not a "Lift thing", it's a persistence thing. Please > look at Exploring Lift, there are a ton of JPA-related examples. > > > > > Maybe I have overlooked something but what I have seen so far is based > > on an "all or nothing" approach > > (also nothing wrong with that, e.g. Grails doesn't facilitate this > > either and this is a very productive framework as well). > > I disagree with this. Glenn was complaining that "Lift didn't do > everything" for him and that's how he seems to define interoperability. > Lift in fact interoperates with all things in JVM-land. If there's > something you want to do on the JVM and Lift is getting in your way, please > let us know. We'll work on it. > > Lift is simply a ServletFilter and can intercept as many or as few HTTP > requests as defined by your web.xml file. If you simply want to use Lift to > service a single URL, you put that in your web.xml file and away you go. If > you want Lift service all the URLs in your app, that's the define web.xml > file. If you want to use Lift's mapper for RDBMS related stuff, cool, but > if you want to use JPA, existing home grown classes, whatever, you're > welcome to. If you want to talk to PayPal, Lift has APIs for that... but > you can use your own. > > At the end of the day, Lift can be as big or as small a part of your > application as you want. If you have a specific requirement, please let us > know and we'll help you through it. > > Thanks, > > David > > > > > Regards, Rintcius > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
