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")
}
}
Ooohhhh... 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 <feeder.of.the.be...@gmail.com>
> 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
-~----------~----~----~----~------~----~------~--~---
