Making modular lift functionality

[Tim Perrett]

Chaps,

Currently, it appears we have no way of modularizing code to make it
portable across lift apps - would I be right in that assumption?

I've just been thinking of late that I have multiple lift apps in
which abstracting the functionality / parts of the application into
something that can be reused would be very useful. Essentially im
talking about plugins :)

I know we have JARs which we can stuff code into, and the widget
framework is coming along nicely too - but what about groups of
functionality? Lets use the classic example of a shopping cart - how
many applications do we do that kind of thing in... lots! As far as I
can see that couldn't ever really be served by the widget framework as
its deeper than that....?

How could we make it possible to group code together or make creating
plugins easy? I don't really think rails plugins are a good example,
as thats pretty messy, but the merb plugins are pretty sweet way of
doing things; perhaps its possible to do something similar with JAR
packaging? Maven modules perhaps?

What are peoples thoughts? Are these the ramblings of a mad-man? ;-)

Cheers

Tim

[TylerWeir]

What's the planned extent for your plugins?

If we use the cart example, you'd like to package up a bunch of Model
objects, views and snippets?

If think it's a rad idea, what's stopping you/us from doing this?

(and you're quite mad :) )

[David Pollak]

Tim,

The idea is a great one... and you can do it today.

In Boot.scala:

    LiftRules.addToPackages("my.shopping.cart")

    my.shopping.cart.Boot()

And voila, you've added enough stuff to intercept the appropriate calls, have snippets, comet stuff, etc.

I think the existing infrastructure for intercepting requests, etc. should give you everything you need.

Thanks,

David

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Tim Perrett]

> In Boot.scala:
>
>     LiftRules.addToPackages("my.shopping.cart")
>
>     my.shopping.cart.Boot()
>
> And voila, you've added enough stuff to intercept the appropriate calls,
> have snippets, comet stuff, etc.
>
> I think the existing infrastructure for intercepting requests, etc. should
> give you everything you need.

Thats interesting stuff Dave. Whats the directory structure of that
package? Or is it just another lift app which you then call the Boot
method? Thats a pretty crazy notion - lift apps calling smaller lift
apps if thats what you mean! Groovy!

Id say one of the most important things about any type of plugin
system is that its possible to customise / override. For instance, the
HTML of the cart is very likley to differ for each project, whilst the
actual functionality would be very similar. Would schemifier pick up
mapper models in that extra package too? Presumably the addToPackages
method just added stuff onto the seach / load path?

Cheers

Tim

PS: @ty... I always suspected I was mad ;-)

[TylerWeir]

@Tim - in addition to your shopping cart, what else are you thinking
about? Maybe we can capture it on a wiki wishlist?

[Tim Perrett]

I have some specific functionality which I use for use with some
particular workflow systems - its so specific to what I do it would be
irrelevant for 99% of people. Thats why i used the cart as an example
as everyone can relate to it (although it would actually be pretty
useful)

Really cant wait for Dave to share some more of his illuminating
knowledge on this :-)

[David Pollak]

There's nothing magic about the current lift app in terms of how lift processes snippets, etc.

LiftRules.addToPackages(...) defines which packages lift will search for snippets, comet actors, etc.  You can add a whole bunch of different packages and voila, you'll have snippets and comet actors (and Scala-based views) from those different pacakges.  If you want plugins that are simply based on snippets or comet actors, you've got all you need right here.

If you want to do more (intercept incoming requests, re-write requests, define additional menu items), there are a ton of intercept points in lift's request cycle.  Your plugin can re-write requests just like your main app.  Your plugin can define menu items, just like your main app can, etc.

MegaProtoUser is a good example of intercepting a bunch of calls into lift in order to add a ton of functionality to an app with little or no work on the part of a developer.  MegaProtoUser is not doing any magic... it's just using lift calls to add functionality to the app (it's a little sub-optimal in terms of the view code living in the Scala file and that ultimately has to be changed.)

Does this help?

[Tim Perrett]

Hey Dave,

Yes thank you, thats very helpful.

I'll have a play around with a few things and see where I get too. Out
of interest - how would you remove the HTML from MegaProtoUser?
Replace it with calls to bind?

Cheers

Tim

[David Pollak]

Tim Perrett wrote:

Hey Dave,

Yes thank you, thats very helpful.

I'll have a play around with a few things and see where I get too. Out  
of interest - how would you remove the HTML from MegaProtoUser?  
Replace it with calls to bind?
  

Not bind.  I'm not really sure how to address the issue. :-)

[Tim Perrett]

Interesting - so effectively, we can provide plugins that have code,
but serving HTML right now unless its in the .scala file is really
rather difficult?

Cheers, Tim

[David Pollak]

On Wed, Jul 9, 2008 at 7:45 AM, Tim Perrett <he...@timperrett.com> wrote:

Interesting - so effectively, we can provide plugins that have code,
but serving HTML right now unless its in the .scala file is really
rather difficult?

No, you can include the HTML as well.  It must be a resource that's loaded.  As long as the resource is in the JAR file, it'll be loaded correctly.

The issue for MegaProtoUser is slightly different... there's a very, very tight coupling between the display and the code.  I think the right answer is a resource bundle with strings that are loaded into the forms rather than pages bound to live elements.
 

Cheers, Tim

On 9 Jul 2008, at 14:22, David Pollak wrote:
> Not bind.  I'm not really sure how to address the issue. :-)

[Tim Perrett]

> No, you can include the HTML as well. It must be a resource that's
> loaded. As long as the resource is in the JAR file, it'll be loaded
> correctly.

Oh ok cool, sorry to keep banging on about this, I have one last
question and I promise thats it :D

A common thing with plugins is a "heres the default, use that if you
want, but just override XYZ to customize it". Obviously this is no
problem with classes/traits et al as its just usual programming, but
in terms of a view that (for arguments sake) was just like a normal
lift app using bind for the snippets onto HTML elements - how would
one use a snippet/view combo that was contained in that JAR? Some kind
of rewrite? Or would you need to unpack that HTML file into the
"webapp" dir?

Overriding it would be easier than using the stock implementation I
guess as its just a case of calling the snippet in the code the
developer would write.

Cheers

Tim

[David Pollak]

You can build a partial function that will intercept a request for a particular resource and return the resource of your choice.

I think it's time to build an example of this.

Perhaps you can design the requirements for a plugin and create a new project for this plugin and we can work through the points.  Sound good?

Thanks,

David

Cheers

Tim





  

[Tim Perrett]

> Perhaps you can design the requirements for a plugin and create a
> new project for this plugin and we can work through the points.
> Sound good?

Yeah that sounds cool - can I suggest we do a very crude cart example?
I'll set up this on my github tomorrow :)

Cheers David

Tim

[TylerWeir]

>can I suggest we do a very crude cart example?

Excellent idea I'd say.

[Tim Perrett]

Cool - well i've set up the github; i'll just bosh together a quick
scala project tomorrow [I want to do it now, but my lift addiction is
really affecting productivity ;-) ] which has a simple model and a
snippet for adding, removing and totaling stuff in the cart.

Cheers

Tim