The return of controllers?

[Jeppe Nejsum Madsen]

Hi,

I read Harryh's slides from nescala
(https://docs.google.com/present/view?id=dcbpz3ck_38cj3kdbgm), and the
solution he presents is (almost verbatim :-) the same as what we've
come up with for this problem (e.g. a URL like /resource/id needs to
look up some item based on the id).

I've also felt that this is getting close to the MVC approach (which
is not inherently bad, but perhaps not the Lift philosophy) and was
wondering how others handle this?

/Jeppe

[David Pollak]

I have for years secretly suspected that parameterized Loc's are in fact controllers.

And yes, in a system with stable URLs, having parameterized Locs act as controllers is a good thing.

With Menu.param(...) and the new Menu.params(...), you can build parameterized, type-safe Locs very easily and with HarryH's favorite snippet feature: parameterized snippets.  If you've got a Loc[Foo], then:

class MySnippet(foo: Foo) {
  def render = "#name" #> foo.name
}
 
"just works"

/Jeppe

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Jeppe Nejsum Madsen]

David Pollak <feeder.of...@gmail.com> writes:

> On Wed, Feb 23, 2011 at 1:30 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>> Hi,
>>
>> I read Harryh's slides from nescala
>> (https://docs.google.com/present/view?id=dcbpz3ck_38cj3kdbgm), and the
>> solution he presents is (almost verbatim :-) the same as what we've
>> come up with for this problem (e.g. a URL like /resource/id needs to
>> look up some item based on the id).
>>
>> I've also felt that this is getting close to the MVC approach (which
>> is not inherently bad, but perhaps not the Lift philosophy) and was
>> wondering how others handle this?
>>
>
> I have for years secretly suspected that parameterized Loc's are in fact
> controllers.
>
> And yes, in a system with stable URLs, having parameterized Locs act as
> controllers is a good thing.

My gut feeling as well :-)

> With Menu.param(...) and the new Menu.params(...), you can build
> parameterized, type-safe Locs very easily and with HarryH's favorite snippet
> feature: parameterized snippets. If you've got a Loc[Foo], then:

I'm thinking about how to better compose these. Usually we have a bunch
of similar named menu items (CRUD etc) that needs to somehow work on the
same objects...

>
> class MySnippet(foo: Foo) {
> def render = "#name" #> foo.name
> }
>
> "just works"

Yes this is extremely awesome. I'm currently removing lots of
boilerplate with this syntax.

/Jeppe

[Peter Robinett]

Is there any good introduction to parameterized snippets? I imagine I'm not alone in loving to read a basic introduction to them. Perhaps something could be added to http://www.assembla.com/wiki/show/liftweb/More_on_Snippets?

Peter

[David Pollak]

On Thu, Feb 24, 2011 at 1:07 AM, Peter Robinett <pe...@bubblefoundry.com> wrote:

Is there any good introduction to parameterized snippets? I imagine I'm not alone in loving to read a basic introduction to them. Perhaps something could be added to http://www.assembla.com/wiki/show/liftweb/More_on_Snippets?

I'm working on a chapter in Simply Lift that covers, among other things, parameterized snippets.
 

Peter

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[David Pollak]

On Thu, Feb 24, 2011 at 12:33 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:

David Pollak <feeder.of...@gmail.com> writes:

> On Wed, Feb 23, 2011 at 1:30 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>> Hi,
>>
>> I read Harryh's slides from nescala
>> (https://docs.google.com/present/view?id=dcbpz3ck_38cj3kdbgm), and the
>> solution he presents is (almost verbatim :-) the same as what we've
>> come up with for this problem (e.g. a URL like /resource/id needs to
>> look up some item based on the id).
>>
>> I've also felt that this is getting close to the MVC approach (which
>> is not inherently bad, but perhaps not the Lift philosophy) and was
>> wondering how others handle this?
>>
>
> I have for years secretly suspected that parameterized Loc's are in fact
> controllers.
>
> And yes, in a system with stable URLs, having parameterized Locs act as
> controllers is a good thing.

My gut feeling as well :-)

> With Menu.param(...) and the new Menu.params(...), you can build
> parameterized, type-safe Locs very easily and with HarryH's favorite snippet
> feature: parameterized snippets.  If you've got a Loc[Foo], then:

I'm thinking about how to better compose these. Usually we have a bunch
of similar named menu items (CRUD etc) that needs to somehow work on the
same objects...

Would love to see the patterns you've come up with so we can build things into Lift that normalizes those patterns
 

>
> class MySnippet(foo: Foo) {
>   def render = "#name" #> foo.name
> }
>
> "just works"

Yes this is extremely awesome. I'm currently removing lots of
boilerplate with this syntax.

/Jeppe

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Naftoli Gugenheim]

I see a similarity between the move from controllers to view first, and the way, e.g., game programming changed. In the olden days (in e.g., BASIC) you had kept all your sprites' data in arrays, and you had one game loop that dealt with the logic of all the moving parts. The more modern (OOP) approach is that each object implements its own logic. But even so you often need "supervisor" objects.
As long as the controllers aren't replacing view first, only supplementing them, it doesn't take away from being "the Lift way."

/Jeppe

[Raoul Duke]

On Thu, Feb 24, 2011 at 12:22 PM, Naftoli Gugenheim
<nafto...@gmail.com> wrote:
> I see a similarity between the move from controllers to view first, and the
> way, e.g., game programming changed. In the olden days (in e.g., BASIC) you
> had kept all your sprites' data in arrays, and you had one game loop that
> dealt with the logic of all the moving parts. The more modern (OOP) approach
> is that each object implements its own logic. But even so you often need
> "supervisor" objects.

there are a lot of ways to skin the game engine rabbit, all in use --
it is heavily context dependent. just warning against claiming that
there's a strong clear single trend/thread/history to how people go
about doing engines. several non/anti-oo styles are alive and well
thank you very much :-) even though of course other things like unreal
present themselves as pretty ooy.

sincerely.