Glenn, On Wed, May 13, 2009 at 10:39 PM, glenn <gl...@exmbly.com> wrote:
> > I appreciate all the comments on lift and interoperability. What I'm > hearing > is that if an integration can be done in a plain old Java EE > application, it can be done > in lift. I never doubted that. It's just that I was hoping for a > little transparency when it > comes to resource management. What resources are you looking to manage. Your original post lacked specifics as does this one. What is it that you want to do that you cannot (1) do with Lift or (2) do with some other JVM library because Lift is getting in your way? > > > If I want to grab a resource outside the lift application context, do > I write plain html, Java EE code, lift code, > or a hybrid? What kind of resource do you want to "grab"? A database? An HTTP exposed service? In general, Lift is about servicing (responding to) HTTP requests, not about making them. There's nothing in Lift that I know of that impairs your ability to use other libraries to access external services. But, Lift is primarily about servicing, not making, HTTP requests. > I can use an action attribute on an html form to submit a > request to any URL, > but I can't do that in a lift form template. This is just wrong. First, there's no such thing as a "Lift form template". Lift's templating mechanism is a generic system for re-writing XML documents. There's no limit on how that re-writing can happen. What kind of re-writing do you want to do? How do you want the XML to appear? What kind of substitution do you want to make from a generic template into what is rendered to the browser? > > > Lift has api's to construct and process JSON and ATOM formats and even > has REST methods to process them, > but only if you plan on talking to yourself. What does this mean? What does "talking to yourself" mean? > > > I think a lift implementation of something like Ryan Dewsbury's > JSONRequest class, This is a JavaScript class that operates on the client side (in the browser). There's nothing that bars you from using this class in your Lift-based application. If you are suggesting a Scala-based JSON request generator so that you can make JSON requests on external services, there are plenty of Java-based classes that do this and there's been no demand to writing a wrapper for one of these in Scala and include it with Lift. Once again, Lift is primarily concerned with servicing HTTP requests, not making them. > in Google Web Toolkit Applications, GWT is a client-side technology, not a server-side technology. You can use GWT-based clients as front ends to Lift-based applications. As Marius said, be specific about what you want and why (you've seen the kind of support you've been getting related to the menu items... find me another framework team that adds features with a day or two turn-around when the feature is concrete). Continuing to be non-specific or just plain wrong is not helping your case. David > > would help. > > On May 11, 9:59 pm, Meredith Gregory <lgreg.mered...@gmail.com> wrote: > > Glen, > > > > i've done some really hare-brained integrations -- like chaining the Lift > > filter with the Jersey filter -- and a bunch of other stuff. Between > Lift's > > architecture and Scala's brilliant interop with Java, it's definitely my > > weapon of choice for integration projects. > > > > That said, i would really be interested to know what sort of integration > > you're having difficulty with -- even if it's only a gedanken experiment > > that seems to be problematic. Chances are, if you're running into a > problem, > > we're likely to run into it, or already have. Either way, it would be > > beneficial for all to find a soln. > > > > Best wishes, > > > > --greg > > > > On Mon, May 11, 2009 at 3:45 PM, Timothy Perrett <timo...@getintheloop.eu > >wrote: > > > > > > > > > > > > > Could agree more with Alex - I too have done some pretty sophisticated > > > integrations with 3rd party systems and at every stage I found the > > > life-cycle hooks into lift very rich and completely empowering. > > > > > Cheers, Tim > > > > > On May 11, 11:31 pm, Alex Boisvert <boisv...@intalio.com> wrote: > > > > Hi Glenn, > > > > > > I don't understand where you're coming from either... I've > integrated > > > Lift > > > > with a different persistence layer (home-grown), another > authentication > > > > system (Tempo RBAC), integrated it with existing Java libraries and > > > Spring > > > > MVC components without trouble. So far, I haven't run into a > situation > > > > where Lift got in the way of integration. The fact that Lift uses > all > > > the > > > > standard servlet APIs made it easy to simply add it to an existing > app > > > and > > > > even reuse session state / cookies from existing apps. > > > > > > I can see how Lift can be different from what you're used to, but I > don't > > > > see how Lift gets in the way of integrating with legacy apps. > > > > > > My 2 cents... > > > > > > alex > > > > > > On Mon, May 11, 2009 at 1:06 PM, glenn <gl...@exmbly.com> wrote: > > > > > > > Just some observations from a struggling lift user... > > > > > > > Yes, I see it's utility in delivering dynamic html to the browser. > But > > > > > in today's world of rapidly evolving technologies for mashups and > flex- > > > > > like richness and gadgetization, interoperability is the key to > > > > > adoption in the enterprise. It's not enough to say you can > selectively > > > > > rewrite your legacy apps in lift. Lift, out of the box, is still > > > > > another technology for building monolithing web apps (war files). > Not > > > > > the best stategy. > > > > > > > I find the keepers of the code, in response to numerous postings on > > > > > this site, suffer from NIH anxiety and easily dismiss > interoperability > > > > > with other frameworks, either because they believe they have a > > > > > superior implementation, so why use someone else's, or, if you > really > > > > > feel you need it, roll your own. > > > > > > > My response to that is, it just doesn't work that way. The best > > > > > technologies are not just agnostic on the issue of > interoperability, > > > > > they embrace pluggability, and let the developer community choose > the > > > > > winners and losers. > > > > > > > Lift suffers from not even having an out-of the-box declarative > > > > > configuration capability. And, frankly no, I don't have the time or > > > > > resources to write my own. Please, give me something other than > just > > > > > an <a> tag to work with. > > > > -- > > L.G. Meredith > > Managing Partner > > Biosimilarity LLC > > 1219 NW 83rd St > > Seattle, WA 98117 > > > > +1 206.650.3740 > > > > http://biosimilarity.blogspot.com > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 -~----------~----~----~----~------~----~------~--~---
