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.

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? 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.

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.

I think a lift implementation of something like Ryan Dewsbury's
JSONRequest class, in Google Web Toolkit Applications,
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

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to