[Lift] Re: Some DispatchSnippet Qs
David,
Thanks for your reply.
I agree with your points about dispatch snippets: they're a good
idea, and I see that it's possible to avoid having to rewrite the
method name several times.
But Lift does provide a reflection-based dispatch mechanism which
could work with stateful snippets but for the fact that
StatefulSnippet extends DispatchSnippet. It seems like an arbitrary
restriction that would be easy to lift (sorry, couldn't resist). My
summary argument is: If it's very important that developers use
DispatchSnippet, then all snippets should be DispatchSnippets. But if
it's okay to invoke snippets through reflection, then it should be
okay for StatefulSnippets too.
I'll use the framework either way and do appreciate all the work
you've put into it!
W
On May 19, 8:52 am, David Pollak
wrote:
> Willis,
>
> I appreciate your point of view. Getting stuff done more quickly is good.
> Having a maintainable, flexible code base is good. Sometimes these things
> are at odds.
>
> I've found that over my various projects, using DispatchSnippets is better.
> They tend to lead to fewer bugs. That's why I think it's a better practice
> to use them.
>
> Let's look at a couple of examples:
>
> class MySnippet {
> def doIt(in: NodeSeq): NodeSeq = bind("s", in, "a" -> "b")
>
> }
>
> class MyDispSnip extends DispatchSnippet {
> def dispatch = Map("doIt" -> doIt _)
>
> def doIt(in: NodeSeq): NodeSeq = bind("s", in, "a" -> "b")
>
> }
>
> Or, if I'm feeling DRY:
>
> object MyDS extends DispatchSnippet {
> def dispatch = {
> case "doIt" => bind("s", _, "a" -> "b")
> }
>
> }
>
> Ooo... in the last example, we didn't even have to define our parameter
> name or type or the return type... so technically, it's the most DRY of all.
> :-)
>
> In all seriousness, I appreciate your comments and perspective. It's good
> to hear from newbies. And I really do appreciate the balance between
> convention and configuration. I am gently pushing toward configuration
> because it's been my experience that in this case, it works better.
>
> Thanks,
>
> David
>
> On Tue, May 19, 2009 at 3:32 AM, Willis Blackburn <
>
>
>
> willis.blackb...@gmail.com> wrote:
>
> > David,
>
> > Aren't I declaring the methods my snippet supports by including them
> > as public methods of the snippet itself?
>
> > I think that requiring every StatefulSnippet to also be a
> > DispatchSnippet is at odds with the code-by-convention and don't-
> > repeat-yourself principles. If all my dispatch PF does is map each
> > method name to the corresponding method (as in my example), then all
> > I've done is re-implement the default behavior in order to satisfy the
> > compiler. I would prefer that DispatchSnippet and StatefulSnippet
> > were unrelated, allowing the application developer to make the
> > dispatch vs. reflection and stateless vs. stateful choices
> > independently. Is there a technical reason why this would be
> > impossible?
>
> > I appreciate that you might think it presumptuous of me to show up in
> > this group, having only a few days' experience with Lift and Scala,
> > and opine about the design of the framework. Nevertheless I hope
> > you'll consider my point of view. I like Lift precisely because it
> > isn't rigid and structured. It's powerful but doesn't prescribe a
> > particular web application architecture like "every URL invokes a
> > controller" or "everything is a component." Even the view-first
> > principle is simply the default strategy and can be changed. That's
> > why the StatefulSnippets-DispatchSnippet coupling stands out for me.
>
> > W
>
> > On May 18, 10:36 pm, David Pollak
> > wrote:
> > > It's better practice to use DispatchSnippets. Snippets by convention are
> > > the easy toe in the water, but once you're dealing with state, etc., you
> > > should be graduating to declaring the methods that your snippets support,
> > > thus enforcing the DispatchSnippet being the base class of
> > StatefulSnippet.
>
> > > On Mon, May 18, 2009 at 6:04 PM, Willis Blackburn <
>
> > > willis.blackb...@gmail.com> wrote:
>
> > > > I'm back with another question.
>
> > > > I see that StatefulSnippet extends DispatchSnippet. I understand what
> > > > DispatchSnippet is about. But what is the reason that a
> > > > StatefulSnippet must also be a DispatchSnippet? Aren't these concepts
> > > > (stateful vs. stateless, dispatch vs. reflection) unrelated?
>
> > > > Most of the StatefulSnippet examples that I've seen look like this:
>
> > > > class MySnippet extends StatefulSnippet {
> > > > def dispatch = {
> > > > case "add" => add _
> > > > case "edit" => edit _
> > > > case "foo" => foo _
> > > > }
> > > > def add(xhtml : NodeSeq) : ...
> > > > ...
> > > > }
>
> > > > The dispatch definition doesn't seem to provide much value here.
>
> > > > W
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430
[Lift] Re: Some DispatchSnippet Qs
Willis,
I appreciate your point of view. Getting stuff done more quickly is good.
Having a maintainable, flexible code base is good. Sometimes these things
are at odds.
I've found that over my various projects, using DispatchSnippets is better.
They tend to lead to fewer bugs. That's why I think it's a better practice
to use them.
Let's look at a couple of examples:
class MySnippet {
def doIt(in: NodeSeq): NodeSeq = bind("s", in, "a" -> "b")
}
class MyDispSnip extends DispatchSnippet {
def dispatch = Map("doIt" -> doIt _)
def doIt(in: NodeSeq): NodeSeq = bind("s", in, "a" -> "b")
}
Or, if I'm feeling DRY:
object MyDS extends DispatchSnippet {
def dispatch = {
case "doIt" => bind("s", _, "a" -> "b")
}
}
Ooo... in the last example, we didn't even have to define our parameter
name or type or the return type... so technically, it's the most DRY of all.
:-)
In all seriousness, I appreciate your comments and perspective. It's good
to hear from newbies. And I really do appreciate the balance between
convention and configuration. I am gently pushing toward configuration
because it's been my experience that in this case, it works better.
Thanks,
David
On Tue, May 19, 2009 at 3:32 AM, Willis Blackburn <
willis.blackb...@gmail.com> wrote:
>
> David,
>
> Aren't I declaring the methods my snippet supports by including them
> as public methods of the snippet itself?
>
> I think that requiring every StatefulSnippet to also be a
> DispatchSnippet is at odds with the code-by-convention and don't-
> repeat-yourself principles. If all my dispatch PF does is map each
> method name to the corresponding method (as in my example), then all
> I've done is re-implement the default behavior in order to satisfy the
> compiler. I would prefer that DispatchSnippet and StatefulSnippet
> were unrelated, allowing the application developer to make the
> dispatch vs. reflection and stateless vs. stateful choices
> independently. Is there a technical reason why this would be
> impossible?
>
> I appreciate that you might think it presumptuous of me to show up in
> this group, having only a few days' experience with Lift and Scala,
> and opine about the design of the framework. Nevertheless I hope
> you'll consider my point of view. I like Lift precisely because it
> isn't rigid and structured. It's powerful but doesn't prescribe a
> particular web application architecture like "every URL invokes a
> controller" or "everything is a component." Even the view-first
> principle is simply the default strategy and can be changed. That's
> why the StatefulSnippets-DispatchSnippet coupling stands out for me.
>
> W
>
>
> On May 18, 10:36 pm, David Pollak
> wrote:
> > It's better practice to use DispatchSnippets. Snippets by convention are
> > the easy toe in the water, but once you're dealing with state, etc., you
> > should be graduating to declaring the methods that your snippets support,
> > thus enforcing the DispatchSnippet being the base class of
> StatefulSnippet.
> >
> > On Mon, May 18, 2009 at 6:04 PM, Willis Blackburn <
> >
> >
> >
> > willis.blackb...@gmail.com> wrote:
> >
> > > I'm back with another question.
> >
> > > I see that StatefulSnippet extends DispatchSnippet. I understand what
> > > DispatchSnippet is about. But what is the reason that a
> > > StatefulSnippet must also be a DispatchSnippet? Aren't these concepts
> > > (stateful vs. stateless, dispatch vs. reflection) unrelated?
> >
> > > Most of the StatefulSnippet examples that I've seen look like this:
> >
> > > class MySnippet extends StatefulSnippet {
> > >def dispatch = {
> > >case "add" => add _
> > >case "edit" => edit _
> > >case "foo" => foo _
> > >}
> > >def add(xhtml : NodeSeq) : ...
> > >...
> > > }
> >
> > > The dispatch definition doesn't seem to provide much value here.
> >
> > > W
> >
> > --
> > 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
>
> >
>
--
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
-~--~~~~--~~--~--~---
[Lift] Re: Some DispatchSnippet Qs
David,
Aren't I declaring the methods my snippet supports by including them
as public methods of the snippet itself?
I think that requiring every StatefulSnippet to also be a
DispatchSnippet is at odds with the code-by-convention and don't-
repeat-yourself principles. If all my dispatch PF does is map each
method name to the corresponding method (as in my example), then all
I've done is re-implement the default behavior in order to satisfy the
compiler. I would prefer that DispatchSnippet and StatefulSnippet
were unrelated, allowing the application developer to make the
dispatch vs. reflection and stateless vs. stateful choices
independently. Is there a technical reason why this would be
impossible?
I appreciate that you might think it presumptuous of me to show up in
this group, having only a few days' experience with Lift and Scala,
and opine about the design of the framework. Nevertheless I hope
you'll consider my point of view. I like Lift precisely because it
isn't rigid and structured. It's powerful but doesn't prescribe a
particular web application architecture like "every URL invokes a
controller" or "everything is a component." Even the view-first
principle is simply the default strategy and can be changed. That's
why the StatefulSnippets-DispatchSnippet coupling stands out for me.
W
On May 18, 10:36 pm, David Pollak
wrote:
> It's better practice to use DispatchSnippets. Snippets by convention are
> the easy toe in the water, but once you're dealing with state, etc., you
> should be graduating to declaring the methods that your snippets support,
> thus enforcing the DispatchSnippet being the base class of StatefulSnippet.
>
> On Mon, May 18, 2009 at 6:04 PM, Willis Blackburn <
>
>
>
> willis.blackb...@gmail.com> wrote:
>
> > I'm back with another question.
>
> > I see that StatefulSnippet extends DispatchSnippet. I understand what
> > DispatchSnippet is about. But what is the reason that a
> > StatefulSnippet must also be a DispatchSnippet? Aren't these concepts
> > (stateful vs. stateless, dispatch vs. reflection) unrelated?
>
> > Most of the StatefulSnippet examples that I've seen look like this:
>
> > class MySnippet extends StatefulSnippet {
> > def dispatch = {
> > case "add" => add _
> > case "edit" => edit _
> > case "foo" => foo _
> > }
> > def add(xhtml : NodeSeq) : ...
> > ...
> > }
>
> > The dispatch definition doesn't seem to provide much value here.
>
> > W
>
> --
> 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
-~--~~~~--~~--~--~---
[Lift] Re: Some DispatchSnippet Qs
It's better practice to use DispatchSnippets. Snippets by convention are
the easy toe in the water, but once you're dealing with state, etc., you
should be graduating to declaring the methods that your snippets support,
thus enforcing the DispatchSnippet being the base class of StatefulSnippet.
On Mon, May 18, 2009 at 6:04 PM, Willis Blackburn <
willis.blackb...@gmail.com> wrote:
>
> I'm back with another question.
>
> I see that StatefulSnippet extends DispatchSnippet. I understand what
> DispatchSnippet is about. But what is the reason that a
> StatefulSnippet must also be a DispatchSnippet? Aren't these concepts
> (stateful vs. stateless, dispatch vs. reflection) unrelated?
>
> Most of the StatefulSnippet examples that I've seen look like this:
>
> class MySnippet extends StatefulSnippet {
>def dispatch = {
>case "add" => add _
>case "edit" => edit _
>case "foo" => foo _
>}
>def add(xhtml : NodeSeq) : ...
>...
> }
>
> The dispatch definition doesn't seem to provide much value here.
>
> W
>
>
>
> >
>
--
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
-~--~~~~--~~--~--~---
