[Lift] Re: Lift and Cappuccino integration... a first step
Stupendous stuff Dave!
On Sep 3, 6:10 pm, David Pollak wrote:
> Folks,
>
> Hearkening back to my NextStep days, I took a dive into Cappuccino today.
> Yep... Obj-J is just like Obj-C and Cappuccino faithfully captures AppKit
> goodness.
>
> I've integrated Lift with Cappuccino. The integration points are as
> follows:
>
> 1. A Lift application serves the Cappuccino application. This means that
> one could mix a "web style" Lift based app with a could of "app style"
> Cappuccino-based application pages.
> 2. Cappuccino can initiate calls to Lift via Ajax. The call from Cap
> looks like: performAjaxCall([input stringValue]); where there's been a
> binding a Lift JSON message handler to the performAjaxCall function. The
> binding looks like:
> Script(
> Function("performAjaxCall", List("param"), JsonVar.is._1("hello",
> JsVar("param"))) &
> JsonVar.is._2)
> 3. Lift can initiate calls into a Cappuccino app via Lift's Comet
> support. Here's the Lift code that's necessary to create a clock that
> ticks
> every 3 seconds in the Cap app:
> override def highPriority = {
> case 'Ping =>
> partialUpdate(currentTime)
> ActorPing.schedule(this, 'Ping , 3 seconds)
> }
>
> def currentTime: JsCmd = JsRaw("clockCallback("+(""+now).encJs+");")
> Plus the following line that must appear in the page that contains the
> Cap app:
>
>
> A running version of the Lift/Cappuccino integrated app can be found
> athttp://frothy.liftweb.net/
>
> The source can be found athttp://github.com/dpp/Frothy/tree/master (please
> don't laugh at/vomit on my ObjJ code... it's been 15 years since I did
> ObjC).
>
> Thanks,
>
> David
>
> --
> 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: Dependency Injection in Lift
On Wed, Sep 2, 2009 at 9:06 PM, Kris Nuttycombe
wrote:
>
> On Wed, Sep 2, 2009 at 4:30 PM, David
> Pollak wrote:
> >
> >
> > On Wed, Sep 2, 2009 at 1:27 PM, Kris Nuttycombe <
> kris.nuttyco...@gmail.com>
> > wrote:
> >>
> >> I think that the following really misses the point of dependency
> >> injection:
> >>
> >> On Wed, Sep 2, 2009 at 11:39 AM, David
> >> Pollak wrote:
> >> >
> >> > Let's say we're running in test mode, in Boot.scala:
> >> > if (Props.testMode) {
> >> > MyAppRules.paymentGateway = () => MockPaymentGateway
> >> > }
> >>
> >> In order to test in isolation, production code should never have to
> >> have any idea that mock classes might exist. In most cases, they don't
> >> - the mock is a dynamic proxy that has expectations configured on it
> >> *in the test case*.
> >
> > At some point, the concrete implementation has to be specified, DI or no.
> > At some point there needs to be a definition (in a config file, in an
> > annotation, in Boot, in the current session, on the current call stack)
> of
> > the concrete class. Having a factory function that can be changed means
> > that you can define how an instance is created, that's all.
>
> My point is that Boot is part of the production codebase, and as such
> it should be entirely ignorant of the test harness.
>
> >> Dependency injection can be used to do configuration at any level of
> >> granularity, not just at the "global config" level that is Boot.scala.
> >
> > And my example above allowed for configuration at any level (well... the
> > example didn't include 'current request' but that's a change from
> SessionVar
> > to RequestVar)
>
> But can you test a snippet in the absence of references to RequestVar,
> SessionVar, S, and the rest of Lift if the snippet makes calls to such
> objects? I don't want to have to set up the state of a Req having been
> processed through a RewriteRequest and so on to create an environment
> for my snippet to run in.
>
If you've got a dependency on something, you're going to have to set it up.
Whether that setup is implicit because you've got some annotations on some
classes or explicit by creating some setup method that wraps the call to a
test or a set of tests, you've got setup.
There's no practical difference between the setup required to do:
@injectclass Snippet(someState: State) {
def transform(in: NodeSeq): NodeSeq = ...
}
Set up test injections
testSnippet
And
class Snippet { lazy val someState = myState.is
}
S.init(mockSession) {
myState.doWith(mockValue) {
testSnippet
}
}
>
> > Additionally, the S pattern looks like a global, but is in fact a front
> end
> > to thread-specific state. Scala's DynamicVar (S sits on top of a
> DynamicVar
> > style pattern) gives you a lot of latitude to have a concrete symbol for
> > something with a dynamic meaning for that symbol.
>
> I understand this, but to me thread-local state is little better than
> global state, because when you come down to it RequestVar and
> SessionVar instances behave like globals within the context of the
> request or the session, respectively. If I have multiple snippets on a
> page that both happen to mutate the state of a RequestVar without
> checking it, code that's ignorant of the order of snippet calls cannot
> reliably make any assumptions about said state. This has caused me
> bugs that took serious time to track down and in some cases still
> aren't fully resolved.
>
Yeah... this is a problem with state. I'm not sure how DI or IoC addresses
it, however. Statefulness leads to messiness.
>
> >> If the only dependencies that an
> >> object has are provided through constructor parameters, any and all
> >> external state that the object depends upon can be trivially mocked
> >> simply by passing in different parameters.
> >
> > I don't understand the difference between having a parameter magically
> > passed because on an annotation and making a method call to get a
> parameter
> > that satisfies an interface other than the call is explicit and the
> > annotation based mechanism is something that happens by magic where I
> regard
> > magic to be bad.
>
> I guess I feel like dependency injection is a declarative approach,
> which I prefer to the imperative method call. Ultimately, the
> significant question is what is allowed to configure how that method
> call responds; if there are several layers of framework (Boot, S,
> RequestVar, etc.) between the configurer and the configuree I don't
> have confidence that the state I'm trying to establish wont get mucked
> up along the way. DI is hardly magic; it's just a matter of having a
> piece of code that will calculate a dependency graph for you then find
> the correct objects to plug in from a flat scope to establish the
> state of the object you request.
>
And I prefer to have that calculation be explicit.
>
> >> With respect to Tim's comment, with Guice you usually don't use a
> >> configuration file; your configuration is in code. In a test c
[Lift] Re: Label in ChoiceHolder.toForm
On Thu, Sep 3, 2009 at 4:48 PM, Ross Mellgren wrote: > FYI, you leaked some extra characters into the license block: > > - * See the License for the specific language governing permissions > 0 > + * See the License for the specifichoicec language governing permissions > > > tnx > -Ross > > On Sep 3, 2009, at 7:40 PM, David Pollak wrote: > > > http://github.com/dpp/liftweb/commit/68c85dcd5f11c860af5e6a5c034fbe70f7a5d387 > You can specify (inject ;-) ) a different mechanism for turning the > ChoiceItem into NodeSeq in the ChoiceHolder companion object. > > On Thu, Sep 3, 2009 at 4:11 PM, Naftoli Gugenheim wrote: > >> >> Shouldn't ChoiceHolder.toForm use a label instead of a span? This way you >> can click on the text, not just the control, to select it. >> Thanks! >> >> >> > > > -- > 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 > > > > > > > -- 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: Label in ChoiceHolder.toForm
FYI, you leaked some extra characters into the license block: - * See the License for the specific language governing permissions 0 + * See the License for the specifichoicec language governing permissions -Ross On Sep 3, 2009, at 7:40 PM, David Pollak wrote: > http://github.com/dpp/liftweb/commit/68c85dcd5f11c860af5e6a5c034fbe70f7a5d387 > > You can specify (inject ;-) ) a different mechanism for turning the > ChoiceItem into NodeSeq in the ChoiceHolder companion object. > > On Thu, Sep 3, 2009 at 4:11 PM, Naftoli Gugenheim > wrote: > > Shouldn't ChoiceHolder.toForm use a label instead of a span? This > way you can click on the text, not just the control, to select it. > Thanks! > > > > > > -- > 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: Label in ChoiceHolder.toForm
http://github.com/dpp/liftweb/commit/68c85dcd5f11c860af5e6a5c034fbe70f7a5d387 You can specify (inject ;-) ) a different mechanism for turning the ChoiceItem into NodeSeq in the ChoiceHolder companion object. On Thu, Sep 3, 2009 at 4:11 PM, Naftoli Gugenheim wrote: > > Shouldn't ChoiceHolder.toForm use a label instead of a span? This way you > can click on the text, not just the control, to select it. > Thanks! > > > > -- 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: Common type of several MetMappers
On Thu, Sep 3, 2009 at 4:21 PM, Naftoli Gugenheim wrote:
> One of those exception when transforming types -- it prints the verbosified
> version of the function, then keeps going up the AST tree and printing.
> Then there's a InvocationTargetException caused by
> ...symtab.Types$TypeError: type mismatch;
> found: (Super-expanded recursive type)
> Etc.
> This is after I added : LongKeyedMetaMapper[_] to the method. (Adding it to
> each MetaMapper returned fixes it). Before it was something similar.
> The point is, is there a single type annotation that can be added to the
> method?
>
If LongKeyedMetaMapper[_] causes a compiler crash, please file a ticket on
the Scala bug tracker. If you can post the stack trace to the Scala list,
Paul P or someone else with a clue might be able to recommend something.
>
> -
> David Pollak wrote:
>
> On Thu, Sep 3, 2009 at 3:15 PM, Naftoli Gugenheim >wrote:
>
> >
> > def lookupTable(v: Value) = v match {
> > case Lookup => LookupTable
> > case RangleLookup => RangeLookupTable
> > }
> > Causes a compiler crash (sometimes?).
>
>
> Hmmm what's the compiler crash?
>
>
> > LookupTable and RangeLookupTable are LongKeyedMetaMappers.
> > What type information can I add without casting?
> > Thanks.
> >
> > >
> >
>
>
> --
> 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
>
> >
>
--
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: Common type of several MetMappers
One of those exception when transforming types -- it prints the verbosified
version of the function, then keeps going up the AST tree and printing.
Then there's a InvocationTargetException caused by ...symtab.Types$TypeError:
type mismatch;
found: (Super-expanded recursive type)
Etc.
This is after I added : LongKeyedMetaMapper[_] to the method. (Adding it to
each MetaMapper returned fixes it). Before it was something similar.
The point is, is there a single type annotation that can be added to the method?
-
David Pollak wrote:
On Thu, Sep 3, 2009 at 3:15 PM, Naftoli Gugenheim wrote:
>
> def lookupTable(v: Value) = v match {
> case Lookup => LookupTable
> case RangleLookup => RangeLookupTable
> }
> Causes a compiler crash (sometimes?).
Hmmm what's the compiler crash?
> LookupTable and RangeLookupTable are LongKeyedMetaMappers.
> What type information can I add without casting?
> Thanks.
>
> >
>
--
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] Label in ChoiceHolder.toForm
Shouldn't ChoiceHolder.toForm use a label instead of a span? This way you can click on the text, not just the control, to select it. Thanks! --~--~-~--~~~---~--~~ 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: Common type of several MetMappers
On Thu, Sep 3, 2009 at 3:15 PM, Naftoli Gugenheim wrote:
>
> def lookupTable(v: Value) = v match {
> case Lookup => LookupTable
> case RangleLookup => RangeLookupTable
> }
> Causes a compiler crash (sometimes?).
Hmmm what's the compiler crash?
> LookupTable and RangeLookupTable are LongKeyedMetaMappers.
> What type information can I add without casting?
> Thanks.
>
> >
>
--
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: May I know websites powered by Lift?
http://groups.google.com/group/liftweb/browse_thread/thread/ed8f9e8e44f3c23f On Sep 4, 12:07 am, surfman wrote: > I tried searching websites powered by Lift but failed. Any one knows > any? I suggest that David should edit a page list all websites powered > by Lift on Liftweb Project. It will be great useful. Thanks. --~--~-~--~~~---~--~~ 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] Mastering SiteMap
Hi all, I haven't been able to find many detailed explanations about how use SiteMap, so I went through and tried write up a decent walkthrough: http://www.bubblefoundry.com/blog/2009/09/understanding-lifts-sitemap/ My knowledge is still pretty basic, so I'd appreciate any comments and corrections. One question I still have is what is the use of the views folder under the src/main/myapp/ in the standard directory configuration? As I understand it, you don't put XHTML view files there – they need to be in src/main/myapp/webroot/. Am I misunderstanding the terminology and something else is a View with goes in that directory? Thanks, Peter Robinett --~--~-~--~~~---~--~~ 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: GAE (google apps engine) Lift Eclipse Setup
Thanks Tyler, thought it might be something like that. I can see that a more "conventional" approach of running mvn: eclipse on the standard lift example project creates an eclipse project without the problems mentioned above - so that gives me something to go on to find what's up with my GAE project. On Sep 3, 10:19 pm, TylerWeir wrote: > > test .. can't see previous post > > New members are moderated. --~--~-~--~~~---~--~~ 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: Lift and Cappuccino integration... a first step
Wow, great stuff!
I was considering looking into using Cappuccino but was afraid of the
integration troubles with Lift. Now I think I'll take a second look,
I've always been a fan of Obj-C.
--Dan--
On Sep 3, 2009, at 4:10 PM, David Pollak wrote:
> Folks,
>
> Hearkening back to my NextStep days, I took a dive into Cappuccino
> today. Yep... Obj-J is just like Obj-C and Cappuccino faithfully
> captures AppKit goodness.
>
> I've integrated Lift with Cappuccino. The integration points are as
> follows:
> A Lift application serves the Cappuccino application. This means
> that one could mix a "web style" Lift based app with a could of "app
> style" Cappuccino-based application pages.
> Cappuccino can initiate calls to Lift via Ajax. The call from Cap
> looks like: performAjaxCall([input stringValue]); where there's been
> a binding a Lift JSON message handler to the performAjaxCall
> function. The binding looks like:
> Script(
> Function("performAjaxCall", List("param"),
> JsonVar.is._1("hello", JsVar("param"))) &
> JsonVar.is._2)
> Lift can initiate calls into a Cappuccino app via Lift's Comet
> support. Here's the Lift code that's necessary to create a clock
> that ticks every 3 seconds in the Cap app:
> override def highPriority = {
> case 'Ping =>
> partialUpdate(currentTime)
> ActorPing.schedule(this, 'Ping , 3 seconds)
> }
>
> def currentTime: JsCmd = JsRaw("clockCallback("+(""+now).encJs+");")
> Plus the following line that must appear in the page that contains
> the Cap app:
>
> A running version of the Lift/Cappuccino integrated app can be found
> at http://frothy.liftweb.net/
>
> The source can be found at http://github.com/dpp/Frothy/tree/master
> (please don't laugh at/vomit on my ObjJ code... it's been 15 years
> since I did ObjC).
>
> Thanks,
>
> David
>
> --
> 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] Lift and Cappuccino integration... a first step
Folks,
Hearkening back to my NextStep days, I took a dive into Cappuccino today.
Yep... Obj-J is just like Obj-C and Cappuccino faithfully captures AppKit
goodness.
I've integrated Lift with Cappuccino. The integration points are as
follows:
1. A Lift application serves the Cappuccino application. This means that
one could mix a "web style" Lift based app with a could of "app style"
Cappuccino-based application pages.
2. Cappuccino can initiate calls to Lift via Ajax. The call from Cap
looks like: performAjaxCall([input stringValue]); where there's been a
binding a Lift JSON message handler to the performAjaxCall function. The
binding looks like:
Script(
Function("performAjaxCall", List("param"), JsonVar.is._1("hello",
JsVar("param"))) &
JsonVar.is._2)
3. Lift can initiate calls into a Cappuccino app via Lift's Comet
support. Here's the Lift code that's necessary to create a clock that ticks
every 3 seconds in the Cap app:
override def highPriority = {
case 'Ping =>
partialUpdate(currentTime)
ActorPing.schedule(this, 'Ping , 3 seconds)
}
def currentTime: JsCmd = JsRaw("clockCallback("+(""+now).encJs+");")
Plus the following line that must appear in the page that contains the
Cap app:
A running version of the Lift/Cappuccino integrated app can be found at
http://frothy.liftweb.net/
The source can be found at http://github.com/dpp/Frothy/tree/master (please
don't laugh at/vomit on my ObjJ code... it's been 15 years since I did
ObjC).
Thanks,
David
--
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] Common type of several MetMappers
def lookupTable(v: Value) = v match {
case Lookup => LookupTable
case RangleLookup => RangeLookupTable
}
Causes a compiler crash (sometimes?). LookupTable and RangeLookupTable are
LongKeyedMetaMappers.
What type information can I add without casting?
Thanks.
--~--~-~--~~~---~--~~
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: lift:msgs - how to override the default markup?
Note that noticesToJsCmd is used for Ajax propagated notices and not when rendering the actual page when the Msgs snippet is executed. Br's, Marius On Sep 3, 10:59 pm, george wrote: > thanks marius, I'll explore both options and hopefully I'll learn some > more about scala and lift along the way.. --~--~-~--~~~---~--~~ 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: lift:msgs - how to override the default markup?
thanks marius, I'll explore both options and hopefully I'll learn some more about scala and lift along the way.. --~--~-~--~~~---~--~~ 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: lift:msgs - how to override the default markup?
Ah, graciously is what I meant, I can't comment on the gracefulness of
his commit ;-)
-Ross
On Sep 3, 2009, at 3:29 PM, Ross Mellgren wrote:
> I built my own snippet and then used the hook DPP gracefully
> provided in LiftRules called noticesToJsCmd to make the AJAX
> generated notices look the same.
>
> -Ross
>
> Here's the version I use, for reference:
>
> /**
> * Snippet for showing page level and field level messages, like the
> lift builtin Msgs snippet does, only with better style integration
> */
> class Messages
> {
>def page(ns: NodeSeq): NodeSeq = { LiftRules.noticesContainerId }>{ Messages.page() }
>def field(ns: NodeSeq): NodeSeq = S.attr("id") match {
>case Full(id) => urlEncode(id) }>{ Messages.field(id) }
>case _ => Empty
>}
> }
>
> object Messages
> {
>type Notice = (NoticeType.Value, NodeSeq, Box[String])
>
>private def generate(messages: Iterable[Notice], divClass:
> String, iconClass: String, prefix: NodeSeq): NodeSeq =
>if (messages.isEmpty) {
>Empty
>} else {
> all" }>
>
>{ messages.flatMap(prefix ++ _._2 ++ ) }
>
>}
>
>private def generate(notices: Iterable[Notice]): NodeSeq =
>({ generate(notices.filter(_._1 == NoticeType.Error), "ui-
> state-error", "ui-icon-alert", Empty) } ++
> { generate(notices.filter(_._1 == NoticeType.Warning), "ui-
> state-highlight", "ui-icon-notice", Warning: ) } ++
> { generate(notices.filter(_._1 == NoticeType.Notice), "ui-
> state-highlight", "ui-icon-info", Empty) })
>
>
>def page() : NodeSeq = generate
> (S.getNotices.projection.filter(_._3.isEmpty))
>def field(id: String): NodeSeq = generate
> (S.getNotices.projection.filter(_._3 == id))
>
>def noticesToJsCmd(): JsCmd = {
>var pageNotices: List[Notice] = Nil
>var noticesByField: immutable.Map[String, List[Notice]] =
> immutable.TreeMap.empty[String, List[Notice]].withDefaultValue(Nil)
>
>S.getNotices.foreach {
>case notice@(_, _, fieldBox) => fieldBox match {
>case Full(field) => noticesByField(field) ::= notice
>case _ => pageNotices ::= notice
>}
>}
>
>val pageCmd = pageNotices match {
>case Nil => Noop
>case _ => SetHtml(LiftRules.noticesContainerId, generate
> (pageNotices))
>}
>
>noticesByField.foldLeft(pageCmd) {
>(cmd, tup) =>
>cmd & SetHtml(LiftRules.noticesContainerId + urlEncode
> (tup._1), generate(tup._2))
>}
>}
> }
>
> On Sep 3, 2009, at 3:20 PM, george wrote:
>
>>
>> Hello folks,
>>
>> If I want to change the XHTML output of the builtin snippet Msgs,
>> what
>> is the best way to do that? / Can I do that?
>>
>> Say for example if I didn't want an unordered list..
>>
>> thanks
>>
>> >>
>
--~--~-~--~~~---~--~~
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: lift:msgs - how to override the default markup?
In Boot you can do:
LiftRules.snippetDispatch.prepend {
case "Msgs" => MyMsgs
}
where MyMsg is :
object MyMsg extends DispatchSnippet {
}
But the simplest way is to simply not use Msgs snippet and build your
own one. There is no magic in Msgs snippet. You can probably inspire
your code from Msgs snippet.
Br's,
Marius
On Sep 3, 10:20 pm, george wrote:
> Hello folks,
>
> If I want to change the XHTML output of the builtin snippet Msgs, what
> is the best way to do that? / Can I do that?
>
> Say for example if I didn't want an unordered list..
>
> thanks
--~--~-~--~~~---~--~~
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: lift:msgs - how to override the default markup?
thanks ross! --~--~-~--~~~---~--~~ 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: lift:msgs - how to override the default markup?
I built my own snippet and then used the hook DPP gracefully provided
in LiftRules called noticesToJsCmd to make the AJAX generated notices
look the same.
-Ross
Here's the version I use, for reference:
/**
* Snippet for showing page level and field level messages, like the
lift builtin Msgs snippet does, only with better style integration
*/
class Messages
{
def page(ns: NodeSeq): NodeSeq = { Messages.page() }
def field(ns: NodeSeq): NodeSeq = S.attr("id") match {
case Full(id) => { Messages.field(id) }
case _ => Empty
}
}
object Messages
{
type Notice = (NoticeType.Value, NodeSeq, Box[String])
private def generate(messages: Iterable[Notice], divClass:
String, iconClass: String, prefix: NodeSeq): NodeSeq =
if (messages.isEmpty) {
Empty
} else {
{ messages.flatMap(prefix ++ _._2 ++ ) }
}
private def generate(notices: Iterable[Notice]): NodeSeq =
({ generate(notices.filter(_._1 == NoticeType.Error), "ui-
state-error", "ui-icon-alert", Empty) } ++
{ generate(notices.filter(_._1 == NoticeType.Warning), "ui-
state-highlight", "ui-icon-notice", Warning: ) } ++
{ generate(notices.filter(_._1 == NoticeType.Notice), "ui-
state-highlight", "ui-icon-info", Empty) })
def page() : NodeSeq = generate
(S.getNotices.projection.filter(_._3.isEmpty))
def field(id: String): NodeSeq = generate
(S.getNotices.projection.filter(_._3 == id))
def noticesToJsCmd(): JsCmd = {
var pageNotices: List[Notice] = Nil
var noticesByField: immutable.Map[String, List[Notice]] =
immutable.TreeMap.empty[String, List[Notice]].withDefaultValue(Nil)
S.getNotices.foreach {
case notice@(_, _, fieldBox) => fieldBox match {
case Full(field) => noticesByField(field) ::= notice
case _ => pageNotices ::= notice
}
}
val pageCmd = pageNotices match {
case Nil => Noop
case _ => SetHtml(LiftRules.noticesContainerId, generate
(pageNotices))
}
noticesByField.foldLeft(pageCmd) {
(cmd, tup) =>
cmd & SetHtml(LiftRules.noticesContainerId + urlEncode
(tup._1), generate(tup._2))
}
}
}
On Sep 3, 2009, at 3:20 PM, george wrote:
>
> Hello folks,
>
> If I want to change the XHTML output of the builtin snippet Msgs, what
> is the best way to do that? / Can I do that?
>
> Say for example if I didn't want an unordered list..
>
> thanks
>
> >
--~--~-~--~~~---~--~~
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] lift:msgs - how to override the default markup?
Hello folks, If I want to change the XHTML output of the builtin snippet Msgs, what is the best way to do that? / Can I do that? Say for example if I didn't want an unordered list.. thanks --~--~-~--~~~---~--~~ 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: Mapping MappedDouble to Postgres database
Sorry, had the date wrong. It's next Wednesday. Derek On Tue, Sep 1, 2009 at 5:06 PM, Derek Chen-Becker wrote: > There's 1.0.1-SNAPSHOT, and tomorrow I'll be rolling out 1.0.1 (final). > Both of these have the fix. > > > On Tue, Sep 1, 2009 at 3:45 PM, Naftoli Gugenheim wrote: > >> >> Not to discourage you from updating :) but I think there is a bugfix >> update to 1.0. >> >> - >> DavidV wrote: >> >> >> I found an old post that addresses this problem. I am still using >> Lift-1.0, so I'll update and that should fix the problem. >> -David >> >> On Sep 1, 5:11 pm, DavidV wrote: >> > I am trying to map a MappedDouble object to a postgres database and I >> > get the following error: >> > >> > Exception in thread "main" org.postgresql.util.PSQLException: ERROR: >> > type "double" does not exist >> > >> > I am looking through the Schemifier to try and figure out where the >> > database type is assigned and how to override it. Postgres has a >> > "real" type which would be appropriate for the DB columns I am >> > creating. >> > >> > Can anyone help me in converting the MappedDouble to create a DB >> > column of type "real" in postgres? >> > >> > Thanks, >> > David >> >> >> >> >> > --~--~-~--~~~---~--~~ 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: Dependency Injection in Lift
Guys, Can I direct this thread to a previous discussion on DI / IoC that took place on EPFL scala-user list: http://www.nabble.com/Dependency-injection-in-Scala--ts15229956.html Some interesting thoughts on there that appear to be most relevant to this thread :-) Cheers, Tim --~--~-~--~~~---~--~~ 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: Mapper subclasses
Isn't this really a matter of type casting, and asInstanceOf is just
Scala's
way of doing this. It's always best if you don't have to downcast your
objects, but sometimes its unavoidable.
Glenn...
On Sep 3, 10:29 am, glenn wrote:
> I'm not sure of what the exact problem is. I created an Address trait
> that
> I couple with a number of mapper classes.
>
> trait Address[OwnerType <: KeyedMapper[Long, OwnerType]]{
>
> def owner = this.asInstanceOf[OwnerType]
>
>
>
> Where exactly does this construct break down?
>
> Glenn...
>
> On Sep 3, 7:55 am, Giuseppe Fogliazza wrote:
>
> > jon suggested to me the way to avoid both explicit type parameter and
> > asinstance of:
> > trait Timestamp[MapperType <: TimeStamp[MapperType]] extends Mapper
> > [MapperType] {
> > self:MapperType =>
> > object xdatetime extends MappedDateTime(this)
>
> > // all sorts of utility functions for dealing with timestamps
>
> > }
>
> > Thanks jon I have improved model in my application with this approach.
>
> > Giuseppe
>
> > On 3 Set, 16:16, Giuseppe Fogliazza wrote:
>
> > > As an alternative to asInstanceOf you could use explicit type
> > > parameter in MappedField creation:
> > > self:MapperType =>
> > > object xdatetime extends MappedDateTime[MapperType](this)
>
> > > On 3 Set, 09:19, Giuseppe Fogliazza wrote:
>
> > > > Unfortunately you cannot escape from asInstanceOf . Forcing
> > > > self:MapperType the type of "this" will be TimeStamp with MapperType
> > > > violating the constraint for the type of the first parameter of
> > > > MappedDateTime :T <: Mapper[T].
>
> > > > Regards
> > > > Giuseppe
>
> > > > On 3 Set, 07:08, Naftoli Gugenheim wrote:
>
> > > > > So I guess you can't escape the asInstanceOf. Can you successfully
> > > > > give the trait a self-type of this: MapperType =>, or declare it to
> > > > > extend Mapper[MapperType], without running into problems elsewhere?
>
> > > > > -
>
> > > > > harryh wrote:
>
> > > > > I've been handling this with traits, for example I have something like
> > > > > so:
>
> > > > > trait Timestamp[MapperType <: Mapper[MapperType]] {
> > > > > object xdatetime extends
> > > > > MappedDateTime[MapperType](this.asInstanceOf
> > > > > [MapperType])
>
> > > > > // all sorts of utility functions for dealing with timestamps
>
> > > > > }
>
> > > > > Then I can do
>
> > > > > class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> > > > > // additional fields that are Foo specific
>
> > > > > }
>
> > > > > I have quite a few traits similar to Timestamp at this point
> > > > > corresponding to various fields that appear in lots of different
> > > > > tables in my application.
>
> > > > > -harryh
--~--~-~--~~~---~--~~
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: Mapper subclasses
I'm not sure of what the exact problem is. I created an Address trait
that
I couple with a number of mapper classes.
trait Address[OwnerType <: KeyedMapper[Long, OwnerType]]{
def owner = this.asInstanceOf[OwnerType]
Where exactly does this construct break down?
Glenn...
On Sep 3, 7:55 am, Giuseppe Fogliazza wrote:
> jon suggested to me the way to avoid both explicit type parameter and
> asinstance of:
> trait Timestamp[MapperType <: TimeStamp[MapperType]] extends Mapper
> [MapperType] {
> self:MapperType =>
> object xdatetime extends MappedDateTime(this)
>
> // all sorts of utility functions for dealing with timestamps
>
> }
>
> Thanks jon I have improved model in my application with this approach.
>
> Giuseppe
>
> On 3 Set, 16:16, Giuseppe Fogliazza wrote:
>
> > As an alternative to asInstanceOf you could use explicit type
> > parameter in MappedField creation:
> > self:MapperType =>
> > object xdatetime extends MappedDateTime[MapperType](this)
>
> > On 3 Set, 09:19, Giuseppe Fogliazza wrote:
>
> > > Unfortunately you cannot escape from asInstanceOf . Forcing
> > > self:MapperType the type of "this" will be TimeStamp with MapperType
> > > violating the constraint for the type of the first parameter of
> > > MappedDateTime :T <: Mapper[T].
>
> > > Regards
> > > Giuseppe
>
> > > On 3 Set, 07:08, Naftoli Gugenheim wrote:
>
> > > > So I guess you can't escape the asInstanceOf. Can you successfully give
> > > > the trait a self-type of this: MapperType =>, or declare it to extend
> > > > Mapper[MapperType], without running into problems elsewhere?
>
> > > > -
>
> > > > harryh wrote:
>
> > > > I've been handling this with traits, for example I have something like
> > > > so:
>
> > > > trait Timestamp[MapperType <: Mapper[MapperType]] {
> > > > object xdatetime extends MappedDateTime[MapperType](this.asInstanceOf
> > > > [MapperType])
>
> > > > // all sorts of utility functions for dealing with timestamps
>
> > > > }
>
> > > > Then I can do
>
> > > > class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> > > > // additional fields that are Foo specific
>
> > > > }
>
> > > > I have quite a few traits similar to Timestamp at this point
> > > > corresponding to various fields that appear in lots of different
> > > > tables in my application.
>
> > > > -harryh
--~--~-~--~~~---~--~~
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: Dependency Injection in Lift
This is a great analysis, Chris, thank you. I'll be saving this one
away for my next discussion of DI and IOC - the Law of Demeter point
is a particularly salient one that had been implicit in my thinking
but really needs to be discussed.
As usual, when people have different axioms communication is difficult
because such axioms tend to be assumed common when they really
probably are not.
Kris
On Thu, Sep 3, 2009 at 10:02 AM, Chris Shorrock wrote:
> Let me prefix this by saying this has been a brilliant conversation with
> some obviously smart people and has been enjoyable to follow over the past
> little bit.
> I'll argue (briefly as possible, although I'm notoriously wordy) that one of
> the biggest deltas between the two sides of the conversation is the concept
> of IoC and how it's being applied within the context of Lift. If we define
> dependency injection as the ability to retrieve a reference to a "depended
> upon" object it's been shown that we can achieve this through the various
> patterns which have proven themselves viable due to how the language has
> constructed itself.
> it sounds like the bigger stumbling point is the concept of IoC, that is,
> how we retrieve a reference to these objects. While dependency injection and
> IoC may be synonyms in some contexts I want to define them differently here,
> and I would say then define IoC different from DI in that it changes how
> things are referenced within the execution graph of an application. DI
> can obviously thus be used to achieve IoC.
> In a previous message David questions::
>>
>> How is:
>>
>> class Foo(snippetConstructors: XX) extends Snippet {}
>>
>> Any more abstract than:
>>
>> class Foo with MyProjectState {}
>>
>> where:
>>
>> trait MyProjectState { def snippetConstructor: XX}
>
> And in this case I would say the difference is IoC. When testing Foo in the
> first instance, it's explicitly clear what you need to "mock" out to Test
> Foo, where in the later example what you require is a little less clear. Of
> course this is a pretty trivial example so if we example further the
> differences between:
> def foo(state:S) = { ... }
> vs
> def state = S
> def foo() = { /* uses state */ }
> Again, pretty similar. But the difference is is that foo in the first case
> has declared precisely what it requires to perform it's operation. It's
> contract is very clear. Foo in the later case looks like it can be called
> without any parameter, but it implicitly needs a reference to S via the
> state() method, thus you need an explicit understanding of how things are
> used within a method to be able to test, or use it. Again simple example,
> but as the complexity of a method grows this problem exacerbates itself
> until the point where testing has becomes very difficult.
> Is this a huge deal, maybe not, but when this type of thing is repeated over
> the course of time, with many developers on a project I think it could get
> hard to manage. Finally, the other thing that I don't believe anybody has
> mentioned is how this all relates to LoD. In the example above, if we need
> to do something like:
> def state = S
> def foo() = { state.servletRequest.getCookies() }
> In order to test not only do we need to understand foo(), how it's using S
> via the state method but we also need to understand that S is calling
> servletRequest, which is calling cookies, further complicating testing.
> def foo(cookies:Array[Cookie]) = { ... }
> Would be a much preferable method signature. Anyways, I'll wrap up my
> thoughts there, most of my opinions here come from having lead development
> on a large SOA system where we made TONS of architectural mistakes, which
> really made testing a pain in the ass. In the past 6 or so we've started to
> employ some of the techniques discussed here and it's really made things
> much easier, and cleaner. With that said, this was all Java based, and while
> I've been using Scala at personal projects for some time now, only recently
> did we start to roll it out within the company, so it's possible my opinions
> may be deprecated due to lack of hands on unit-testing experience using some
> of the patterns mentioned above :)
> (love the framework by the way)
--~--~-~--~~~---~--~~
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: Dependency Injection in Lift
Let me prefix this by saying this has been a brilliant conversation with
some obviously smart people and has been enjoyable to follow over the past
little bit.
I'll argue (briefly as possible, although I'm notoriously wordy) that one of
the biggest deltas between the two sides of the conversation is the concept
of IoC and how it's being applied within the context of Lift. If we define
dependency injection as the ability to retrieve a reference to a "depended
upon" object it's been shown that we can achieve this through the various
patterns which have proven themselves viable due to how the language has
constructed itself.
it sounds like the bigger stumbling point is the concept of IoC, that is,
how we retrieve a reference to these objects. While dependency injection and
IoC may be synonyms in some contexts I want to define them differently here,
and I would say then define IoC different from DI in that it changes how
things are referenced within the execution graph of an application. DI
can obviously thus be used to achieve IoC.
In a previous message David questions::
How is:
class Foo(snippetConstructors: XX) extends Snippet {}
> Any more abstract than:
class Foo with MyProjectState {}
> where:
trait MyProjectState { def snippetConstructor: XX}
And in this case I would say the difference is IoC. When testing Foo in the
first instance, it's explicitly clear what you need to "mock" out to Test
Foo, where in the later example what you require is a little less clear. Of
course this is a pretty trivial example so if we example further the
differences between:
def foo(state:S) = { ... }
vs
def state = S
def foo() = { /* uses state */ }
Again, pretty similar. But the difference is is that foo in the first case
has declared precisely what it requires to perform it's operation. It's
contract is very clear. Foo in the later case looks like it can be called
without any parameter, but it implicitly needs a reference to S via the
state() method, thus you need an explicit understanding of how things are
used within a method to be able to test, or use it. Again simple example,
but as the complexity of a method grows this problem exacerbates itself
until the point where testing has becomes very difficult.
Is this a huge deal, maybe not, but when this type of thing is repeated over
the course of time, with many developers on a project I think it could get
hard to manage. Finally, the other thing that I don't believe anybody has
mentioned is how this all relates to LoD. In the example above, if we need
to do something like:
def state = S
def foo() = { state.servletRequest.getCookies() }
In order to test not only do we need to understand foo(), how it's using S
via the state method but we also need to understand that S is calling
servletRequest, which is calling cookies, further complicating testing.
def foo(cookies:Array[Cookie]) = { ... }
Would be a much preferable method signature. Anyways, I'll wrap up my
thoughts there, most of my opinions here come from having lead development
on a large SOA system where we made TONS of architectural mistakes, which
really made testing a pain in the ass. In the past 6 or so we've started to
employ some of the techniques discussed here and it's really made things
much easier, and cleaner. With that said, this was all Java based, and while
I've been using Scala at personal projects for some time now, only recently
did we start to roll it out within the company, so it's possible my opinions
may be deprecated due to lack of hands on unit-testing experience using some
of the patterns mentioned above :)
(love the framework by the way)
--~--~-~--~~~---~--~~
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: Dependency Injection in Lift
On Wed, Sep 2, 2009 at 11:05 PM, Chris Lewis wrote:
>
> DPP's explanation of how to mock infrastructure code (bound to S, etc)
> made since, but it still feels a bit sketchy. Again, this may be my
> misunderstanding, but he's saying to do something like replace the value
> of the function S.redirectTo, so I can test as needed. So here we go:
>
> S.redirectTo = () => { println("redirect received"); }
>
> Now that value is overwritten. What if I was unit testing a bunch of
> snippets, some of those snippets call the same global function, but I
> need to do per-snippet recordings/inspections of those calls? Must I
> reconfigure the values under S each time? What if I forget one?
>
> I've seen Bill Venner's specs - haven't used it but it looks cool. I've
> not heard of mokkito (and didn't see a relevant link on google), so I
> don't know how these tools might help here. Do share :-)
It's "mockito" - http://mockito.org/ which looks like EasyMock (what
I've used most) except that the interfaces are a bit more fluent and
mockito allows mocking of concrete classes, not just interfaces.
Kris
--~--~-~--~~~---~--~~
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: Mapper subclasses
jon suggested to me the way to avoid both explicit type parameter and
asinstance of:
trait Timestamp[MapperType <: TimeStamp[MapperType]] extends Mapper
[MapperType] {
self:MapperType =>
object xdatetime extends MappedDateTime(this)
// all sorts of utility functions for dealing with timestamps
}
Thanks jon I have improved model in my application with this approach.
Giuseppe
On 3 Set, 16:16, Giuseppe Fogliazza wrote:
> As an alternative to asInstanceOf you could use explicit type
> parameter in MappedField creation:
> self:MapperType =>
> object xdatetime extends MappedDateTime[MapperType](this)
>
> On 3 Set, 09:19, Giuseppe Fogliazza wrote:
>
> > Unfortunately you cannot escape from asInstanceOf . Forcing
> > self:MapperType the type of "this" will be TimeStamp with MapperType
> > violating the constraint for the type of the first parameter of
> > MappedDateTime :T <: Mapper[T].
>
> > Regards
> > Giuseppe
>
> > On 3 Set, 07:08, Naftoli Gugenheim wrote:
>
> > > So I guess you can't escape the asInstanceOf. Can you successfully give
> > > the trait a self-type of this: MapperType =>, or declare it to extend
> > > Mapper[MapperType], without running into problems elsewhere?
>
> > > -
>
> > > harryh wrote:
>
> > > I've been handling this with traits, for example I have something like
> > > so:
>
> > > trait Timestamp[MapperType <: Mapper[MapperType]] {
> > > object xdatetime extends MappedDateTime[MapperType](this.asInstanceOf
> > > [MapperType])
>
> > > // all sorts of utility functions for dealing with timestamps
>
> > > }
>
> > > Then I can do
>
> > > class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> > > // additional fields that are Foo specific
>
> > > }
>
> > > I have quite a few traits similar to Timestamp at this point
> > > corresponding to various fields that appear in lots of different
> > > tables in my application.
>
> > > -harryh
--~--~-~--~~~---~--~~
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: Mapper subclasses
You could also do this:
trait HasCreated [T <: HasCreated[T]] extends KeyedMapper[Long, T] {
self: T =>
object created_at extends MappedDateTime(this)
}
//mix into your meta object:
trait HasCreatedMetaMapper[T <: HasCreated[T]] {
self: T with LongKeyedMetaMapper[T] =>
import java.util.Date
def findByCreated(startDate:Date, endDate:Date) = findAll(By_>
(created_at, startDate), By_<(created_at, endDate))
}
On Sep 3, 10:16 am, Giuseppe Fogliazza wrote:
> As an alternative to asInstanceOf you could use explicit type
> parameter in MappedField creation:
> self:MapperType =>
> object xdatetime extends MappedDateTime[MapperType](this)
>
> On 3 Set, 09:19, Giuseppe Fogliazza wrote:
>
>
>
> > Unfortunately you cannot escape from asInstanceOf . Forcing
> > self:MapperType the type of "this" will be TimeStamp with MapperType
> > violating the constraint for the type of the first parameter of
> > MappedDateTime :T <: Mapper[T].
>
> > Regards
> > Giuseppe
>
> > On 3 Set, 07:08, Naftoli Gugenheim wrote:
>
> > > So I guess you can't escape the asInstanceOf. Can you successfully give
> > > the trait a self-type of this: MapperType =>, or declare it to extend
> > > Mapper[MapperType], without running into problems elsewhere?
>
> > > -
>
> > > harryh wrote:
>
> > > I've been handling this with traits, for example I have something like
> > > so:
>
> > > trait Timestamp[MapperType <: Mapper[MapperType]] {
> > > object xdatetime extends MappedDateTime[MapperType](this.asInstanceOf
> > > [MapperType])
>
> > > // all sorts of utility functions for dealing with timestamps
>
> > > }
>
> > > Then I can do
>
> > > class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> > > // additional fields that are Foo specific
>
> > > }
>
> > > I have quite a few traits similar to Timestamp at this point
> > > corresponding to various fields that appear in lots of different
> > > tables in my application.
>
> > > -harryh
--~--~-~--~~~---~--~~
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: Mapper subclasses
As an alternative to asInstanceOf you could use explicit type
parameter in MappedField creation:
self:MapperType =>
object xdatetime extends MappedDateTime[MapperType](this)
On 3 Set, 09:19, Giuseppe Fogliazza wrote:
> Unfortunately you cannot escape from asInstanceOf . Forcing
> self:MapperType the type of "this" will be TimeStamp with MapperType
> violating the constraint for the type of the first parameter of
> MappedDateTime :T <: Mapper[T].
>
> Regards
> Giuseppe
>
> On 3 Set, 07:08, Naftoli Gugenheim wrote:
>
> > So I guess you can't escape the asInstanceOf. Can you successfully give the
> > trait a self-type of this: MapperType =>, or declare it to extend
> > Mapper[MapperType], without running into problems elsewhere?
>
> > -
>
> > harryh wrote:
>
> > I've been handling this with traits, for example I have something like
> > so:
>
> > trait Timestamp[MapperType <: Mapper[MapperType]] {
> > object xdatetime extends MappedDateTime[MapperType](this.asInstanceOf
> > [MapperType])
>
> > // all sorts of utility functions for dealing with timestamps
>
> > }
>
> > Then I can do
>
> > class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> > // additional fields that are Foo specific
>
> > }
>
> > I have quite a few traits similar to Timestamp at this point
> > corresponding to various fields that appear in lots of different
> > tables in my application.
>
> > -harryh
--~--~-~--~~~---~--~~
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: XML -> JSON converter?
Ok, added. This is a quick hack just to explore the problem so expect
bugs, holes in logic and such.
Example usage:
http://github.com/dpp/liftweb/blob/f974b41c56afa500e9d93371f0ce21bde3c854ce/lift-json/src/test/scala/net/liftweb/json/XmlExamples.scala
Cheers Joni
On Sep 3, 2:40 am, David Pollak wrote:
> Cool... I'd be interested in you pushing this to master and letting people
> use it and give feedback.
>
>
>
> On Wed, Sep 2, 2009 at 2:40 PM, Joni Freeman wrote:
>
> > Hi,
>
> > I just quickly spiked this and following works on my local branch:
>
> > scala> val xml =
> >
> >
> > 1
> > Harry
> >
> >
> > 2
> > David
> >
> >
>
> > scala> val json = toJson(xml)
> > scala> compact(render(json))
> > {"foos":{"foo":[{"id":"1","name":"Harry"},{"id":"2","name":"David"}]}}
>
> > scala> val json2 = json map {
> > case JField("id", JString(s)) => JField("id", JInt(s.toInt))
> > case x => x
> > }
> > scala> compact(render(json2))
> > {"foos":{"foo":[{"id":1,"name":"Harry"},{"id":2,"name":"David"}]}}
>
> > This could be quite useful addition. However, I have at least one
> > concern. What kind of processing instructions will eventually be
> > needed for this to be generic enough? For instance, lets change the
> > example XML to:
>
> >
> >
> > 1
> > Harry
> >
> >
>
> > This would still be valid when validating against original XML's DTD,
> > but the generated JSON structure would be something quite different
> > (no arrays):
> > {"foos":{"foo":{"id":1,"name":"Harry"}}}
>
> > Cheers Joni
>
> --
> 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] May I know websites powered by Lift?
I tried searching websites powered by Lift but failed. Any one knows any? I suggest that David should edit a page list all websites powered by Lift on Liftweb Project. It will be great useful. Thanks. --~--~-~--~~~---~--~~ 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: GAE (google apps engine) Lift Eclipse Setup
> test .. can't see previous post New members are moderated. --~--~-~--~~~---~--~~ 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: GAE (google apps engine) Lift Eclipse Setup
test .. can't see previous post On Sep 1, 6:31 pm, Timothy Perrett wrote: > It's on the github wiki: > > http://wiki.github.com/dpp/liftweb > > Cheers, Tim > > Sent from my iPhone > > On 1 Sep 2009, at 07:23, Andreas > wrote: > > > > > > > How do I compile the lift snapshot from the git repository? > > Is there a maven config or wiki entry? > > > On Aug 31, 7:18 pm, David Pollak > > wrote: > >> There are known issues with Lift 1.0 and GAE. > > >> My understanding is that Lift 1.1-SNAPSHOT will work/may work on GAE. > > >> On Sat, Aug 29, 2009 at 12:29 PM, Andreas > >> wrote: > > >>> This is my current setup: > >>> 1)Eclipse3.5 with plugins: Scala, GAE > >>> 2) create a new GAE project without GWT > >>> 3) add Scala Nature to project and copy scala-library.jar to /war/ > >>> WEB- > >>> INF/lib > >>> 4) add this to .classpath: > >>> > >>> > >>> > >>> 5) define project properties Java Build Path->Libaries->Add Variable > >>> M2_REPO to maven repository on Mac OS X: /Users/ahe/.m2/repository > >>> (repository needs to be filled with liftweb by creating on project > >>> with maven on command line) > >>> 6) copy lift-mapper-1.0.jar, lift-util-1.0.jar, lift-webkit-1.0.jar > >>> to /war/WEB-INF/lib > >>> 7) remove existing files in /src and add from default liftweb > >>> structure the folder bootstrap and demo > >>> 8) copy from webapp/ templates-hidden and index.html to /war > >>> 9) replace from war/WEB-INF/web.xml with webapp/WEB-INF/web.xml > > >>> 10) start Debug As -> Web Application > >>> 2009-08-29 21:14:11.471 java[1289:10b] [Java CocoaComponent > >>> compatibility mode]: Enabled > >>> 2009-08-29 21:14:11.474 java[1289:10b] [Java CocoaComponent > >>> compatibility mode]: Setting timeout for SWT to 0.10 > >>> The server is running athttp://localhost:8080/ > > >>> Page access in Browser (http://localhost:8080/) will throw this: > >>> 29.08.2009 19:14:23 com.google.apphosting.utils.jetty.JettyLogger > >>> warn > >>> WARNUNG: Error for /favicon.ico > >>> java.lang.ExceptionInInitializerError > >>> at scala.actors.Actor$class.scheduler(Actor.scala:374) > >>> at net.liftweb.http.SessionMaster$.scheduler > >>> (LiftSession.scala:118) > >>> at scala.actors.Actor$class.start(Actor.scala:783) > >>> at net.liftweb.http.SessionMaster$.start(LiftSession.scala: > >>> 118) > >>> at net.liftweb.http.SessionMaster$.(LiftSession.scala: > >>> 205) > >>> at net.liftweb.http.SessionMaster$. > >>> (LiftSession.scala) > >>> at net.liftweb.http.LiftRules$.rewriteTable(LiftRules.scala: > >>> 408) > >>> at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply > >>> (LiftServlet.scala:522) > >>> at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply > >>> (LiftServlet.scala:518) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4$$anonfun$apply$5$$anonfun$apply$6.apply(Vars.scala:197) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4$$anonfun$apply$5.apply(Vars.scala:196) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4.apply(Vars.scala:195) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply > >>> (Vars.scala:194) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:193) > >>> at > >>> net.liftweb.http.LiftFilterTrait$class.doFilter(LiftServlet.scala: > >>> 517) > >>> at net.liftweb.http.LiftFilter.doFilter(LiftServlet.scala: > >>> 536) > >>> at org.mortbay.jetty.servlet.ServletHandler > >>> $CachedChain.doFilter > >>> (ServletHandler.java:1084) > >>> at > >>> com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter > >>> (TransactionCleanupFilter.java:43) > >>> at org.mortbay.jetty.servlet.ServletHandler > >>> $CachedChain.doFilter > >>> (ServletHandler.java:1084) > >>> at > >>> com.google.appengine.tools.development.StaticFileFilter.doFilter > >>> (StaticFileFilter.java:124) > >>> at org.mortbay.jetty.servlet.ServletHandler > >>> $CachedChain.doFilter > >>> (ServletHandler.java:1084) > >>> at org.mortbay.jetty.servlet.ServletHandler.handle > >>> (ServletHandler.java:360) > >>> at org.mortbay.jetty.security.SecurityHandler.handle > >>> (SecurityHandler.java:216) > >>> at org.mortbay.jetty.servlet.SessionHandler.handle > >>> (SessionHandler.java:181) > >>> at org.mortbay.jetty.handler.ContextHandler.handle > >>> (ContextHandler.java:712) > >>> at org.mortbay.jetty.webapp.WebAppContext.handle > >>> (WebAppContext.java: > >>> 405) > >>>
[Lift] Re: GAE (google apps engine) Lift Eclipse Setup
Hi, I followed this: http://jpkutner.blogspot.com/2009/08/scala-and-lift-on-google-app-engine.html then copied all the liftweb 1.1 and associated JARs into a GAE web project WEB-INF/lib, and added them to the classpath, and the app source files into src, (appropriately packaged). I found it all seemed to launch and run fine but the scala code editor doesn't recognise the imports to _root_.net.liftweb or give any code assistance to things imported that way. Hover over reads "value net is not a member of package " The Java source editor has no problem with that import (e.g. import net.liftweb.util.*;), and the Scala source editor is fine with import _root_.scala its only the .net.liftweb it can't seem to "find". Any ideas? On Sep 1, 6:31 pm, Timothy Perrett wrote: > It's on the github wiki: > > http://wiki.github.com/dpp/liftweb > > Cheers, Tim > > Sent from my iPhone > > On 1 Sep 2009, at 07:23, Andreas > wrote: > > > > > > > How do I compile the lift snapshot from the git repository? > > Is there a maven config or wiki entry? > > > On Aug 31, 7:18 pm, David Pollak > > wrote: > >> There are known issues with Lift 1.0 and GAE. > > >> My understanding is that Lift 1.1-SNAPSHOT will work/may work on GAE. > > >> On Sat, Aug 29, 2009 at 12:29 PM, Andreas > >> wrote: > > >>> This is my current setup: > >>> 1)Eclipse3.5 with plugins: Scala, GAE > >>> 2) create a new GAE project without GWT > >>> 3) add Scala Nature to project and copy scala-library.jar to /war/ > >>> WEB- > >>> INF/lib > >>> 4) add this to .classpath: > >>> > >>> > >>> > >>> 5) define project properties Java Build Path->Libaries->Add Variable > >>> M2_REPO to maven repository on Mac OS X: /Users/ahe/.m2/repository > >>> (repository needs to be filled with liftweb by creating on project > >>> with maven on command line) > >>> 6) copy lift-mapper-1.0.jar, lift-util-1.0.jar, lift-webkit-1.0.jar > >>> to /war/WEB-INF/lib > >>> 7) remove existing files in /src and add from default liftweb > >>> structure the folder bootstrap and demo > >>> 8) copy from webapp/ templates-hidden and index.html to /war > >>> 9) replace from war/WEB-INF/web.xml with webapp/WEB-INF/web.xml > > >>> 10) start Debug As -> Web Application > >>> 2009-08-29 21:14:11.471 java[1289:10b] [Java CocoaComponent > >>> compatibility mode]: Enabled > >>> 2009-08-29 21:14:11.474 java[1289:10b] [Java CocoaComponent > >>> compatibility mode]: Setting timeout for SWT to 0.10 > >>> The server is running athttp://localhost:8080/ > > >>> Page access in Browser (http://localhost:8080/) will throw this: > >>> 29.08.2009 19:14:23 com.google.apphosting.utils.jetty.JettyLogger > >>> warn > >>> WARNUNG: Error for /favicon.ico > >>> java.lang.ExceptionInInitializerError > >>> at scala.actors.Actor$class.scheduler(Actor.scala:374) > >>> at net.liftweb.http.SessionMaster$.scheduler > >>> (LiftSession.scala:118) > >>> at scala.actors.Actor$class.start(Actor.scala:783) > >>> at net.liftweb.http.SessionMaster$.start(LiftSession.scala: > >>> 118) > >>> at net.liftweb.http.SessionMaster$.(LiftSession.scala: > >>> 205) > >>> at net.liftweb.http.SessionMaster$. > >>> (LiftSession.scala) > >>> at net.liftweb.http.LiftRules$.rewriteTable(LiftRules.scala: > >>> 408) > >>> at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply > >>> (LiftServlet.scala:522) > >>> at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply > >>> (LiftServlet.scala:518) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4$$anonfun$apply$5$$anonfun$apply$6.apply(Vars.scala:197) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4$$anonfun$apply$5.apply(Vars.scala:196) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at > >>> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply > >>> $4.apply(Vars.scala:195) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply > >>> (Vars.scala:194) > >>> at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala: > >>> 65) > >>> at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:193) > >>> at > >>> net.liftweb.http.LiftFilterTrait$class.doFilter(LiftServlet.scala: > >>> 517) > >>> at net.liftweb.http.LiftFilter.doFilter(LiftServlet.scala: > >>> 536) > >>> at org.mortbay.jetty.servlet.ServletHandler > >>> $CachedChain.doFilter > >>> (ServletHandler.java:1084) > >>> at > >>> com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter > >>> (TransactionCleanupFilter.java:43) > >>> at org.mortbay.jetty.servlet.ServletHandler > >>> $CachedChain.doFilter > >>> (ServletHandler.java:1084) > >>> at > >>>
[Lift] Re: Mapper and Primary Keys
Indrajit,
Thanks! The problem was in the pom.xml. I fixed that to 1.1-SNAPSHOT
and the problem went away.
Regards,
Som
On Sep 2, 8:59 pm, Indrajit Raychaudhuri wrote:
> Som,
>
> 1. Your source code had dbAutoGenerated_?. The actual function is
> dbAutogenerated_? (g is in lower case).
> Hope you have the right case for 'g' one :)
>
> 2. If your project model (pom.xml) has lift versions set to 1.1-
> SNAPSHOT, you must be on the master and thus on the latest code.
> FWIW, dbAutoGenerated_? is part of the trait BaseMappedField in lift-
> mapper
>
> Verify if both things are in order at give it another spin :)
>
> Cheers, Indrajit
>
> On Sep 2, 7:29 pm, Somindra Bhattacharya wrote:
>
> > Hi again,
>
> > I just wanted to mention that I cannot override dbAutogenerated_?. I
> > get the following error:
>
> > error: method dbAutogenerated_? overrides nothing
> > override def dbAutogenerated_? = false
>
> > Looks to me that I am not using the latest framework code. How do I
> > verify this?
>
> > Thanks,
> > Som
>
> > On Sep 2, 2:24 pm, Somindra Bhattacharya wrote:
>
> > > On Jul 30, 3:36 am, David Pollak
> > > wrote:
>
> > > > I had to add a property on MappedField for dbGenerated_? which has to
> > > > be set
> > > > to false.
>
> > > > Here's the change set and the revised, working (wait for an hour for
> > > > Hudson
> > > > to build the new code) version.
>
> > > > On Wed, Jul 29, 2009 at 1:26 PM, Peter Robinett
> > > > wrote:
>
> > > Hi,
>
> > > I am new to programming for the Web and Lift is the first web
> > > framework I am using. Therefore, please excuse me if my questions seem
> > > naive.
>
> > > I have the same problem that Peter was facing. David, I looked through
> > > your diff and tried making similar changes to my model class. However,
> > > the primary key is still empty in the database.
>
> > > Here is the class that I have defined:
>
> > > class MJData extends KeyedMapper[String,MJData]
> > > {
> > > def getSingleton = MJData
>
> > > override def primaryKeyField = uid
>
> > > object uid extends MappedStringIndex[MJData](this,128)
> > > {
> > > override def writePermission_? = true
> > > override def dbDisplay_? = true
> > > // override def dbAutoGenerated_? = false //commented because it
> > > does not compile
>
> > > override lazy val defaultValue = "11232312" // any string for
> > > now...
>
> > > private var myDirty_? = false
> > > override protected def dirty_?(b: Boolean) = myDirty_? = b
> > > override def dirty_? = myDirty_?
> > > }
>
> > > After looking at the pom.xml that Peter had posted, I upgraded to the
> > > 1.1-SNAPSHOT. Is there something else that I need to do?
>
> > > Another question:
>
> > > > (wait for an hour for Hudson
> > > > to build the new code) version.
>
> > > What does this mean? I am using Maven and I am assuming that it will
> > > "pull" any new changes to the framework.
>
> > > Thanks for reading.
>
> > > Regards,
> > > Som
--~--~-~--~~~---~--~~
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: Wizard code in master
Thought as much ;-) Just something else to throw into discussion, but perhaps it would be great if wizard processes could be serialised into a couple of formats (XML, JSON??)... this is something that I could see myself using to load different wizard steps dynamically from my database or such. Cheers, Tim > Right now, I think it's vomit in process, but later it will turn into work > in process and later code suitable for others to make fun of. --~--~-~--~~~---~--~~ 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: XML -> JSON converter?
Nothing that I know of but maybe Joni could add it to the new json parse
On Wednesday, September 2, 2009, harryh wrote:
>
> Is there anything built into lift that will do XML -> JSON
> conversion? For example:
>
>
>
> 1
> Harry
>
>
> 2
> David
>
>
>
> to:
>
> {
> "foos": {
> "foo": [{
> "id": 1,
> "name": "Harry"
> },
> {
> "id": 2,
> "name": "David"
> }
> ]
> }
>
> Just checking to see if there was something Lift friendly to do this
> before writing my own (or picking a java library to use).
>
> -harryh
> >
>
--
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: Mapper subclasses
Unfortunately you cannot escape from asInstanceOf . Forcing
self:MapperType the type of "this" will be TimeStamp with MapperType
violating the constraint for the type of the first parameter of
MappedDateTime :T <: Mapper[T].
Regards
Giuseppe
On 3 Set, 07:08, Naftoli Gugenheim wrote:
> So I guess you can't escape the asInstanceOf. Can you successfully give the
> trait a self-type of this: MapperType =>, or declare it to extend
> Mapper[MapperType], without running into problems elsewhere?
>
> -
>
> harryh wrote:
>
> I've been handling this with traits, for example I have something like
> so:
>
> trait Timestamp[MapperType <: Mapper[MapperType]] {
> object xdatetime extends MappedDateTime[MapperType](this.asInstanceOf
> [MapperType])
>
> // all sorts of utility functions for dealing with timestamps
>
> }
>
> Then I can do
>
> class Foo extends LongKeyedMapper[Foo] with IdPK with Timestamp[Foo] {
> // additional fields that are Foo specific
>
> }
>
> I have quite a few traits similar to Timestamp at this point
> corresponding to various fields that appear in lots of different
> tables in my application.
>
> -harryh
--~--~-~--~~~---~--~~
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: Snippet inside of a Snippet
Ok, I've run "mvn clean jetty:run" and it works now.
Thanks.
On 3 sep, 03:16, David Pollak wrote:
> On Wed, Sep 2, 2009 at 3:55 PM, José María wrote:
>
> > SOLVED
>
> > lazy val id = S.param("id").flatMap(Helpers.asLong) openOr -1L
>
> > I changed it to:
>
> > lazy val pagina = S.param("numero").openOr("1").toInt
>
> This is a bad pattern. It will lead to an exception is the parameter
> "numero" cannot be parsed as an Int. Exceptions should only be encouraged
> in places where there is an unexpected situation (e.g., your database goes
> down), not in a situation where you have input that cannot logically be
> turned into a number.
>
> The reason, as Tim pointed out, that you got the exception was the class
> changed in a way that JavaRebel couldn't handle. Just stop JavaRebel, do a
> "mvn clean install" and restart JavaRebel.
>
>
>
>
>
> > Yes, I'm using JavaRebel
>
> > On 2 sep, 20:58, Timothy Perrett wrote:
> > > Are you using JavaRebel? Try doing a clean before jetty:run
>
> > > Cheers, Tim
>
> > > On 2 Sep 2009, at 20:57, José María wrote:
>
> > > > On 2 sep, 17:27, David Pollak wrote:
>
> > > >> Try:
>
> > > >> lazy val id = S.param("id").flatMap(Helpers.asLong) openOr -1L
>
> > > > I get:
>
> > > > Exception occured while processing /marca/162
>
> > > > Message: java.lang.IncompatibleClassChangeError
> > > > net.liftweb.util.Full.flatMap(Box.scala:332)
> > > > demo.helloworld.snippet.MarcaInfo$$M$1be0ea1b.id
> > (MarcaInfo.scala:23)
> > > > demo.helloworld.snippet.MarcaInfo$$A$1be0ea1b.id()
> > > > demo.helloworld.snippet.MarcaInfo.id(Marca.scala)
> > > > demo.helloworld.snippet.MarcaInfo$$M$1be0ea1b.marca(MarcaInfo.scala:
> > > > 29)
> > > > demo.helloworld.snippet.MarcaInfo$$A$1be0ea1b.marca()
> > > > demo.helloworld.snippet.MarcaInfo.marca(Marca.scala)
> > > > demo.helloworld.snippet.MarcaInfo$$M$1be0ea1b.datos(MarcaInfo.scala:
> > > > 94)
> > > > demo.helloworld.snippet.MarcaInfo$$A$1be0ea1b.datos()
> > > > demo.helloworld.snippet.MarcaInfo.datos(Marca.scala)
>
> --
> 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
-~--~~~~--~~--~--~---
