[Lift] Re: ws-generated code in lift
Tim, Viktor, Thanks for the insights and sharing of experience. i'm in a situation where i'm working with legacy stuff. i was just wondering how deeply into lift i could push the WSDL-based Java handlers. Best wishes, --greg On Fri, Aug 14, 2009 at 2:54 PM, Timothy Perrett wrote: > > I agree with Viktor - in a similar vein, this is exactly what I > implemented with Akka; the servlet runs in conjunction with lifts > filter and lift just hands off stuff it doesnt know what to do with. > So if you want to use AxisServlet or whatever its real easy. > > From my point of view, you'd need a good reason to bring the SOAP > stuff into lift; right now i havent found one... I write a lot of lift > apps that consume SOAP services, but as yet have no good reason to > write a SOAP serving app with lift - If i were to do one, id do > exactly as with the JAX-RS stuff in Akka and passNotFoundToChain. > > Cheers, Tim > > On Aug 14, 10:24 pm, Viktor Klang wrote: > > Gregory, > > > > Depending on what WS-* stuff you're using, you _should_ be able to wire > the > > AxisServlet in web.xml under /ws/* or something like that, and then have > > lift passNotFoundToChain=true > > > > But I guess it boils down to what liftiness you're planning to do. Can > you > > elaborate a bit on what you're aiming for? > > > > On Fri, Aug 14, 2009 at 9:00 PM, Meredith Gregory > > wrote: > > > > > > > > > > > > > Tim, Viktor, > > > > > Do you wire your SOAP services into lift or do you keep that > independent? i > > > was just talking to DPP and according to him it appears you can > successfully > > > wire WS-generated code anywhere along in the http-request processing > > > pipeline. He pointed out a gotcha that i think can be circumvented with > > > HttpServletResponse trampoline. Both lift and the WS-generated code are > > > likely to want to be in the driver's seat regarding who's returning the > > > bytes. But, i think you can just fool the WS-generated code into > thinking > > > it's got an HttpServletResponse that is really a widget that will just > write > > > into the one lift returns. In this way you can write a 1-size-fits-all > > > return adapter. Is this what you guys are doing, or am i making this > too > > > complicated? > > > > > Best wishes, > > > > > --greg > > > > > -- > > > L.G. Meredith > > > Managing Partner > > > Biosimilarity LLC > > > 1219 NW 83rd St > > > Seattle, WA 98117 > > > > > +1 206.650.3740 > > > > >http://biosimilarity.blogspot.com > > > > -- > > Viktor Klang > > > > Rogue Scala-head > > > > Blog: klangism.blogspot.com > > Twttr: viktorklang > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~-~--~~~---~--~~ 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] Looking for Lift Developers
Hi all, I'm part of a very young Silicon Valley startup that is looking for Lift developers. We use ultra-low-power WiFi-based temperature sensors to monitor rack temperatures in datacenters. RIght now it's just me doing the main development, and as I'm sure you've noticed on this list, I'm quite new to Lift and Scala. So, we'd love more help, particularly someone who knows more Scala than me! If you're interesting in crunching lots of data and helping with things like building out our API with oAuth, XMPP (or perhaps AMQP?) and SNMP support, please drop me a line. Peter Robinett pe...@equal-networks.com --~--~-~--~~~---~--~~ 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: Redirecting during stateful snippet instantiation
Yeah, I don't want to do that because then I have to either modify all
the snippet methods to handle the state or treat each snippet method
differently depending on which state I know it needs, and then also
pass down any state the snippet methods receive to any helper methods
they might call. Overall, I'd just rather have the state as locals and
non-Boxed to cut down on typing and extra crud.
-Ross
On Aug 14, 2009, at 7:09 PM, Naftoli Gugenheim wrote:
> They're just names of pages in my app which have a similar
> functionality.
> Anyway, one method you can use is:
> Make your snippet functions actually have a parameter list before
> the xhtml parameter list:
> def edit(x: X)(xhtml: NodeSeq) = ...
> or alternatively
> def edit(x: X) = (xhtml: NodeSeq) => ...
> where x is the optional data.
> Then change dispatch from a val to a def, which should pattern match
> on whether you have a Full(x) or not; if yes it will return a
> disatch PF that returns something like edit(x) _, in other words, a
> snippet function that knows an X; and if it's empty it will return
> another PF that just redirects.
>
>
>
> -
> Ross Mellgren wrote:
>
> The problem with the Box is unwrapping it in every snippet method,
> when I really want to guarantee that if the StatefulSnippet is
> instantiated, it has these parameters. Moreover, I have additional
> pieces of state which need to be initialized based on the other
> parameters.
>
> For this particular snippet, I put a hack into place based on your
> note about the dispatch function... there's a risk of NPE, but it
> should work okay:
>
> class TemplateEditor
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case _ if (template == null) => S.redirectTo("chooser", ()
> => {
> S.error("Session information lost, please choose what
> template to edit again")
> })
> ...
> }
>
> val template = TemplateEditor.template.is.openOr(null) // eww
> lazy val imageFuncBinding = S.fmapFunc[String](() =>
> { TemplateEditor.template(Full(template)) })(identity)
> }
>
> the key part is that I needed to make derived state lazy (so that if
> it happens to be null I don't NPE early) and just ensure that no calls
> will enter that are before dispatch gets called. Seems a bit ugly, but
> at least I don't have to pass all my state down to the snippet methods
> by hand.
>
> You refer to Request, Client, etc, which don't mean anything to me.
> What are you talking about?
>
> -Ross
>
> On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
>
>> I think it's a mistake, and it's per request. Could someone confirm?
>> In any case, I don't see why you need a separate template class or a
>> RequesVar. Just use an Option or Box var in your snippet, and let it
>> redirect whenever it's None/Empty. You can put the check in the
>> dispatch partial function, in the snippet functions, or in a def
>> dispatch that if it's empty returns a case _ => redirectTo ... PF.
>> I'm not sure if I'm missing something, but I've been doing something
>> similar (if not more complex):
>> When editing a Request you can go to the Client edit or search page,
>> both of which return to the Request screen with its state intact.
>> The edit page is populated with the current Client. The search page
>> can also branch to the client edit page, either editing an existing
>> client or editing a new unsaved client based on the search criteria.
>> Editing returns to the search page while saving a new Client returns
>> to the Request page. This is all using StatefulSnippets defined once
>> and mapSnippet etc., except for ClientSearch which isn't a snippet
>> and so uses RequestVars.
>>
>>
>>
>> -
>> Ross Mellgren wrote:
>>
>> The missing piece there is that I would like it to redirect to
>> another
>> page if the RequestVar is not populated. With mapSnippet, it sounds
>> like I'd have to have a "dummy" snippet with the same shape as the
>> original snippet where all the snippets redirect, e.g.
>>
>> class InitializedTemplateEditor(template: Template)
>> extends StatefulSnippet
>> {
>>val dispatch: DispatchIt = {
>>case "one" => doOne _
>>case "two" => doTwo _
>>...
>>}
>> ...
>> }
>>
>> class TemplateEditor /* named TemplateEditor so that HTML templates
>> will use this unless mapSnippet has overridden */
>>extends StatefulSnippet
>> {
>>val dispatch: DispatchIt = {
>>case "one" => doRedirect _
>>case "two" => doRedirect _
>>...
>>}
>>
>>def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
>> => { S.error("Session information lost, please choose what template
>> to
>> edit again") })
>> }
>>
>> and then some helper to map all the individual dispatches
>>
>> object TemplateEditor
>> {
>>def redirectToEditor(template: Template) = {
>>val editor = InitializedTemplateEditor(template)
[Lift] Testing Record Abstractions?
Hey all, So im in the middle of writing a specialized Record / MetaRecord system - its gone pretty well so far and have been impressed by how flexible Record can be. However, i have a strange issue that I think is being caused by the back-end SOAP service that my abstraction invokes, however to eliminate the option of it being my code I want to test it out... So my question is two fold: 1. Considering i want my tests to not communicate with the actual back- end server, i'll need to mock the results (which is fine) but how can I do that in practice? The examples on the specs site appear limited and don't detail how to test traits... 2. Are there any examples of Record testing? 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: Redirecting during stateful snippet instantiation
Or you could define a def that returns it unboxed if possible or else redirects
the first time its accessed.
-
Ross Mellgren wrote:
Yeah, I don't want to do that because then I have to either modify all
the snippet methods to handle the state or treat each snippet method
differently depending on which state I know it needs, and then also
pass down any state the snippet methods receive to any helper methods
they might call. Overall, I'd just rather have the state as locals and
non-Boxed to cut down on typing and extra crud.
-Ross
On Aug 14, 2009, at 7:09 PM, Naftoli Gugenheim wrote:
> They're just names of pages in my app which have a similar
> functionality.
> Anyway, one method you can use is:
> Make your snippet functions actually have a parameter list before
> the xhtml parameter list:
> def edit(x: X)(xhtml: NodeSeq) = ...
> or alternatively
> def edit(x: X) = (xhtml: NodeSeq) => ...
> where x is the optional data.
> Then change dispatch from a val to a def, which should pattern match
> on whether you have a Full(x) or not; if yes it will return a
> disatch PF that returns something like edit(x) _, in other words, a
> snippet function that knows an X; and if it's empty it will return
> another PF that just redirects.
>
>
>
> -
> Ross Mellgren wrote:
>
> The problem with the Box is unwrapping it in every snippet method,
> when I really want to guarantee that if the StatefulSnippet is
> instantiated, it has these parameters. Moreover, I have additional
> pieces of state which need to be initialized based on the other
> parameters.
>
> For this particular snippet, I put a hack into place based on your
> note about the dispatch function... there's a risk of NPE, but it
> should work okay:
>
> class TemplateEditor
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case _ if (template == null) => S.redirectTo("chooser", ()
> => {
> S.error("Session information lost, please choose what
> template to edit again")
> })
> ...
> }
>
> val template = TemplateEditor.template.is.openOr(null) // eww
> lazy val imageFuncBinding = S.fmapFunc[String](() =>
> { TemplateEditor.template(Full(template)) })(identity)
> }
>
> the key part is that I needed to make derived state lazy (so that if
> it happens to be null I don't NPE early) and just ensure that no calls
> will enter that are before dispatch gets called. Seems a bit ugly, but
> at least I don't have to pass all my state down to the snippet methods
> by hand.
>
> You refer to Request, Client, etc, which don't mean anything to me.
> What are you talking about?
>
> -Ross
>
> On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
>
>> I think it's a mistake, and it's per request. Could someone confirm?
>> In any case, I don't see why you need a separate template class or a
>> RequesVar. Just use an Option or Box var in your snippet, and let it
>> redirect whenever it's None/Empty. You can put the check in the
>> dispatch partial function, in the snippet functions, or in a def
>> dispatch that if it's empty returns a case _ => redirectTo ... PF.
>> I'm not sure if I'm missing something, but I've been doing something
>> similar (if not more complex):
>> When editing a Request you can go to the Client edit or search page,
>> both of which return to the Request screen with its state intact.
>> The edit page is populated with the current Client. The search page
>> can also branch to the client edit page, either editing an existing
>> client or editing a new unsaved client based on the search criteria.
>> Editing returns to the search page while saving a new Client returns
>> to the Request page. This is all using StatefulSnippets defined once
>> and mapSnippet etc., except for ClientSearch which isn't a snippet
>> and so uses RequestVars.
>>
>>
>>
>> -
>> Ross Mellgren wrote:
>>
>> The missing piece there is that I would like it to redirect to
>> another
>> page if the RequestVar is not populated. With mapSnippet, it sounds
>> like I'd have to have a "dummy" snippet with the same shape as the
>> original snippet where all the snippets redirect, e.g.
>>
>> class InitializedTemplateEditor(template: Template)
>> extends StatefulSnippet
>> {
>>val dispatch: DispatchIt = {
>>case "one" => doOne _
>>case "two" => doTwo _
>>...
>>}
>> ...
>> }
>>
>> class TemplateEditor /* named TemplateEditor so that HTML templates
>> will use this unless mapSnippet has overridden */
>>extends StatefulSnippet
>> {
>>val dispatch: DispatchIt = {
>>case "one" => doRedirect _
>>case "two" => doRedirect _
>>...
>>}
>>
>>def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
>> => { S.error("Session information lost, please choose what template
>> to
>> edit again") })
>> }
>>
>> and then some helper to map al
[Lift] Re: Redirecting during stateful snippet instantiation
They're just names of pages in my app which have a similar functionality.
Anyway, one method you can use is:
Make your snippet functions actually have a parameter list before the xhtml
parameter list:
def edit(x: X)(xhtml: NodeSeq) = ...
or alternatively
def edit(x: X) = (xhtml: NodeSeq) => ...
where x is the optional data.
Then change dispatch from a val to a def, which should pattern match on whether
you have a Full(x) or not; if yes it will return a disatch PF that returns
something like edit(x) _, in other words, a snippet function that knows an X;
and if it's empty it will return another PF that just redirects.
-
Ross Mellgren wrote:
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) => S.redirectTo("chooser", () => {
S.error("Session information lost, please choose what
template to edit again")
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =>
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
> I think it's a mistake, and it's per request. Could someone confirm?
> In any case, I don't see why you need a separate template class or a
> RequesVar. Just use an Option or Box var in your snippet, and let it
> redirect whenever it's None/Empty. You can put the check in the
> dispatch partial function, in the snippet functions, or in a def
> dispatch that if it's empty returns a case _ => redirectTo ... PF.
> I'm not sure if I'm missing something, but I've been doing something
> similar (if not more complex):
> When editing a Request you can go to the Client edit or search page,
> both of which return to the Request screen with its state intact.
> The edit page is populated with the current Client. The search page
> can also branch to the client edit page, either editing an existing
> client or editing a new unsaved client based on the search criteria.
> Editing returns to the search page while saving a new Client returns
> to the Request page. This is all using StatefulSnippets defined once
> and mapSnippet etc., except for ClientSearch which isn't a snippet
> and so uses RequestVars.
>
>
>
> -
> Ross Mellgren wrote:
>
> The missing piece there is that I would like it to redirect to another
> page if the RequestVar is not populated. With mapSnippet, it sounds
> like I'd have to have a "dummy" snippet with the same shape as the
> original snippet where all the snippets redirect, e.g.
>
> class InitializedTemplateEditor(template: Template)
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case "one" => doOne _
> case "two" => doTwo _
> ...
> }
> ...
> }
>
> class TemplateEditor /* named TemplateEditor so that HTML templates
> will use this unless mapSnippet has overridden */
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case "one" => doRedirect _
> case "two" => doRedirect _
> ...
> }
>
> def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
> => { S.error("Session information lost, please choose what template to
> edit again") })
> }
>
> and then some helper to map all the individual dispatches
>
> object TemplateEditor
> {
> def redirectToEditor(template: Template) = {
> val editor = InitializedTemplateEditor(template)
> S.mapSnippet("TemplateEditor.one", editor.doOne _)
> S.mapSnippet("TemplateEditor.one", editor.doOne _)
> ...
> S.redirectTo("/editor")
> }
> }
>
> which seems pretty wordy. In this case I think I'd prefer lazy vals /
> boxes as state. Also, the docs for S.mapSnippet claim per-session, but
> the docs for S.snippetMap (which mapSnippet uses) claim per-request,
> so it might be even more onerous.
>
> -Ross
>
>
> On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
>
>> Not sure if I read your message closely enough, but if you want to
>> r
[Lift] Re: Redirecting during stateful snippet instantiation
The problem with the Box is unwrapping it in every snippet method,
when I really want to guarantee that if the StatefulSnippet is
instantiated, it has these parameters. Moreover, I have additional
pieces of state which need to be initialized based on the other
parameters.
For this particular snippet, I put a hack into place based on your
note about the dispatch function... there's a risk of NPE, but it
should work okay:
class TemplateEditor
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case _ if (template == null) => S.redirectTo("chooser", () => {
S.error("Session information lost, please choose what
template to edit again")
})
...
}
val template = TemplateEditor.template.is.openOr(null) // eww
lazy val imageFuncBinding = S.fmapFunc[String](() =>
{ TemplateEditor.template(Full(template)) })(identity)
}
the key part is that I needed to make derived state lazy (so that if
it happens to be null I don't NPE early) and just ensure that no calls
will enter that are before dispatch gets called. Seems a bit ugly, but
at least I don't have to pass all my state down to the snippet methods
by hand.
You refer to Request, Client, etc, which don't mean anything to me.
What are you talking about?
-Ross
On Aug 14, 2009, at 6:27 PM, Naftoli Gugenheim wrote:
> I think it's a mistake, and it's per request. Could someone confirm?
> In any case, I don't see why you need a separate template class or a
> RequesVar. Just use an Option or Box var in your snippet, and let it
> redirect whenever it's None/Empty. You can put the check in the
> dispatch partial function, in the snippet functions, or in a def
> dispatch that if it's empty returns a case _ => redirectTo ... PF.
> I'm not sure if I'm missing something, but I've been doing something
> similar (if not more complex):
> When editing a Request you can go to the Client edit or search page,
> both of which return to the Request screen with its state intact.
> The edit page is populated with the current Client. The search page
> can also branch to the client edit page, either editing an existing
> client or editing a new unsaved client based on the search criteria.
> Editing returns to the search page while saving a new Client returns
> to the Request page. This is all using StatefulSnippets defined once
> and mapSnippet etc., except for ClientSearch which isn't a snippet
> and so uses RequestVars.
>
>
>
> -
> Ross Mellgren wrote:
>
> The missing piece there is that I would like it to redirect to another
> page if the RequestVar is not populated. With mapSnippet, it sounds
> like I'd have to have a "dummy" snippet with the same shape as the
> original snippet where all the snippets redirect, e.g.
>
> class InitializedTemplateEditor(template: Template)
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case "one" => doOne _
> case "two" => doTwo _
> ...
> }
> ...
> }
>
> class TemplateEditor /* named TemplateEditor so that HTML templates
> will use this unless mapSnippet has overridden */
> extends StatefulSnippet
> {
> val dispatch: DispatchIt = {
> case "one" => doRedirect _
> case "two" => doRedirect _
> ...
> }
>
> def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
> => { S.error("Session information lost, please choose what template to
> edit again") })
> }
>
> and then some helper to map all the individual dispatches
>
> object TemplateEditor
> {
> def redirectToEditor(template: Template) = {
> val editor = InitializedTemplateEditor(template)
> S.mapSnippet("TemplateEditor.one", editor.doOne _)
> S.mapSnippet("TemplateEditor.one", editor.doOne _)
> ...
> S.redirectTo("/editor")
> }
> }
>
> which seems pretty wordy. In this case I think I'd prefer lazy vals /
> boxes as state. Also, the docs for S.mapSnippet claim per-session, but
> the docs for S.snippetMap (which mapSnippet uses) claim per-request,
> so it might be even more onerous.
>
> -Ross
>
>
> On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
>
>> Not sure if I read your message closely enough, but if you want to
>> redirect to a pre-initialized StatefulSnippet, one option is to
>> instantiate it and use its snippet function in call to S.mapSnippet,
>> in the redirect function. This will override lift's default behavior
>> and use the snippet function to process the page being redirected to.
>>
>>
>> -
>> Ross Mellgren wrote:
>>
>>
>> I have a stateful snippet:
>>
>> class TemplateEditor
>>extends StatefulSnippet
>> {
>> ...
>>val template =
>>(TemplateEditor.template.is
>> openOr
>> S.redirectTo("chooser", () => {
>> S.error("Session information lost, please choose what
>> template to edit again")
>> }))
>>
[Lift] Re: Redirecting during stateful snippet instantiation
I think it's a mistake, and it's per request. Could someone confirm?
In any case, I don't see why you need a separate template class or a RequesVar.
Just use an Option or Box var in your snippet, and let it redirect whenever
it's None/Empty. You can put the check in the dispatch partial function, in the
snippet functions, or in a def dispatch that if it's empty returns a case _ =>
redirectTo ... PF.
I'm not sure if I'm missing something, but I've been doing something similar
(if not more complex):
When editing a Request you can go to the Client edit or search page, both of
which return to the Request screen with its state intact. The edit page is
populated with the current Client. The search page can also branch to the
client edit page, either editing an existing client or editing a new unsaved
client based on the search criteria. Editing returns to the search page while
saving a new Client returns to the Request page. This is all using
StatefulSnippets defined once and mapSnippet etc., except for ClientSearch
which isn't a snippet and so uses RequestVars.
-
Ross Mellgren wrote:
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a "dummy" snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case "one" => doOne _
case "two" => doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case "one" => doRedirect _
case "two" => doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
=> { S.error("Session information lost, please choose what template to
edit again") })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet("TemplateEditor.one", editor.doOne _)
S.mapSnippet("TemplateEditor.one", editor.doOne _)
...
S.redirectTo("/editor")
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
> Not sure if I read your message closely enough, but if you want to
> redirect to a pre-initialized StatefulSnippet, one option is to
> instantiate it and use its snippet function in call to S.mapSnippet,
> in the redirect function. This will override lift's default behavior
> and use the snippet function to process the page being redirected to.
>
>
> -
> Ross Mellgren wrote:
>
>
> I have a stateful snippet:
>
> class TemplateEditor
> extends StatefulSnippet
> {
> ...
> val template =
> (TemplateEditor.template.is
> openOr
> S.redirectTo("chooser", () => {
> S.error("Session information lost, please choose what
> template to edit again")
> }))
> ...
> }
>
> with a companion object holding a RequestVar:
>
> object TemplateEditor
> {
> /** Request var that is populated with what template is under
> edit */
> object template extends RequestVar[Box[Template]](Empty)
> ...
> }
>
> The flow is that another page with snippet chooses a template to edit,
> and then uses:
>
>S.redirectTo("/editor", () =>
> { TemplateEditor.template(Full(template)) })
>
> to stuff the template to edit into the RequestVar. I'd like for the
> state of TemplateEditor to
> use the value of the RequestVar, but not to require every link to re-
> stuff that RequestVar once
> the StatefulSnippet has been instantiated, and not require each
> snippet method to be wrapped
> with the logic to check the RequestVar and do the redirect if it's not
> populated.
>
> The problem I'm running into is that snippet instantiation is
> apparently too early to use
> S.redirectTo -- the Shortcut exception is being trapped as an
> instantiation exception and not
> being used as a redirect.
>
> It doesn't look entirely trivial to touch up LiftSession to pass this
> through, so I guess
> I'm partly soliciting feedback on whether there's a better pattern to
> use here (lazy val?) and
> partly asking if the behavior as it stands is desired.
>
> 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@goog
[Lift] Re: ws-generated code in lift
I agree with Viktor - in a similar vein, this is exactly what I implemented with Akka; the servlet runs in conjunction with lifts filter and lift just hands off stuff it doesnt know what to do with. So if you want to use AxisServlet or whatever its real easy. >From my point of view, you'd need a good reason to bring the SOAP stuff into lift; right now i havent found one... I write a lot of lift apps that consume SOAP services, but as yet have no good reason to write a SOAP serving app with lift - If i were to do one, id do exactly as with the JAX-RS stuff in Akka and passNotFoundToChain. Cheers, Tim On Aug 14, 10:24 pm, Viktor Klang wrote: > Gregory, > > Depending on what WS-* stuff you're using, you _should_ be able to wire the > AxisServlet in web.xml under /ws/* or something like that, and then have > lift passNotFoundToChain=true > > But I guess it boils down to what liftiness you're planning to do. Can you > elaborate a bit on what you're aiming for? > > On Fri, Aug 14, 2009 at 9:00 PM, Meredith Gregory > wrote: > > > > > > > Tim, Viktor, > > > Do you wire your SOAP services into lift or do you keep that independent? i > > was just talking to DPP and according to him it appears you can successfully > > wire WS-generated code anywhere along in the http-request processing > > pipeline. He pointed out a gotcha that i think can be circumvented with > > HttpServletResponse trampoline. Both lift and the WS-generated code are > > likely to want to be in the driver's seat regarding who's returning the > > bytes. But, i think you can just fool the WS-generated code into thinking > > it's got an HttpServletResponse that is really a widget that will just write > > into the one lift returns. In this way you can write a 1-size-fits-all > > return adapter. Is this what you guys are doing, or am i making this too > > complicated? > > > Best wishes, > > > --greg > > > -- > > L.G. Meredith > > Managing Partner > > Biosimilarity LLC > > 1219 NW 83rd St > > Seattle, WA 98117 > > > +1 206.650.3740 > > >http://biosimilarity.blogspot.com > > -- > Viktor Klang > > Rogue Scala-head > > Blog: klangism.blogspot.com > Twttr: viktorklang --~--~-~--~~~---~--~~ 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: Redirecting during stateful snippet instantiation
The missing piece there is that I would like it to redirect to another
page if the RequestVar is not populated. With mapSnippet, it sounds
like I'd have to have a "dummy" snippet with the same shape as the
original snippet where all the snippets redirect, e.g.
class InitializedTemplateEditor(template: Template)
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case "one" => doOne _
case "two" => doTwo _
...
}
...
}
class TemplateEditor /* named TemplateEditor so that HTML templates
will use this unless mapSnippet has overridden */
extends StatefulSnippet
{
val dispatch: DispatchIt = {
case "one" => doRedirect _
case "two" => doRedirect _
...
}
def doRedirect(ns: NodeSeq): NodeSeq = S.redirectTo("chooser", ()
=> { S.error("Session information lost, please choose what template to
edit again") })
}
and then some helper to map all the individual dispatches
object TemplateEditor
{
def redirectToEditor(template: Template) = {
val editor = InitializedTemplateEditor(template)
S.mapSnippet("TemplateEditor.one", editor.doOne _)
S.mapSnippet("TemplateEditor.one", editor.doOne _)
...
S.redirectTo("/editor")
}
}
which seems pretty wordy. In this case I think I'd prefer lazy vals /
boxes as state. Also, the docs for S.mapSnippet claim per-session, but
the docs for S.snippetMap (which mapSnippet uses) claim per-request,
so it might be even more onerous.
-Ross
On Aug 14, 2009, at 5:30 PM, Naftoli Gugenheim wrote:
> Not sure if I read your message closely enough, but if you want to
> redirect to a pre-initialized StatefulSnippet, one option is to
> instantiate it and use its snippet function in call to S.mapSnippet,
> in the redirect function. This will override lift's default behavior
> and use the snippet function to process the page being redirected to.
>
>
> -
> Ross Mellgren wrote:
>
>
> I have a stateful snippet:
>
> class TemplateEditor
> extends StatefulSnippet
> {
> ...
> val template =
> (TemplateEditor.template.is
> openOr
> S.redirectTo("chooser", () => {
> S.error("Session information lost, please choose what
> template to edit again")
> }))
> ...
> }
>
> with a companion object holding a RequestVar:
>
> object TemplateEditor
> {
> /** Request var that is populated with what template is under
> edit */
> object template extends RequestVar[Box[Template]](Empty)
> ...
> }
>
> The flow is that another page with snippet chooses a template to edit,
> and then uses:
>
>S.redirectTo("/editor", () =>
> { TemplateEditor.template(Full(template)) })
>
> to stuff the template to edit into the RequestVar. I'd like for the
> state of TemplateEditor to
> use the value of the RequestVar, but not to require every link to re-
> stuff that RequestVar once
> the StatefulSnippet has been instantiated, and not require each
> snippet method to be wrapped
> with the logic to check the RequestVar and do the redirect if it's not
> populated.
>
> The problem I'm running into is that snippet instantiation is
> apparently too early to use
> S.redirectTo -- the Shortcut exception is being trapped as an
> instantiation exception and not
> being used as a redirect.
>
> It doesn't look entirely trivial to touch up LiftSession to pass this
> through, so I guess
> I'm partly soliciting feedback on whether there's a better pattern to
> use here (lazy val?) and
> partly asking if the behavior as it stands is desired.
>
> 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: Redirecting during stateful snippet instantiation
Not sure if I read your message closely enough, but if you want to redirect to
a pre-initialized StatefulSnippet, one option is to instantiate it and use its
snippet function in call to S.mapSnippet, in the redirect function. This will
override lift's default behavior and use the snippet function to process the
page being redirected to.
-
Ross Mellgren wrote:
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo("chooser", () => {
S.error("Session information lost, please choose what
template to edit again")
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo("/editor", () =>
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
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: ws-generated code in lift
Gregory, Depending on what WS-* stuff you're using, you _should_ be able to wire the AxisServlet in web.xml under /ws/* or something like that, and then have lift passNotFoundToChain=true But I guess it boils down to what liftiness you're planning to do. Can you elaborate a bit on what you're aiming for? On Fri, Aug 14, 2009 at 9:00 PM, Meredith Gregory wrote: > Tim, Viktor, > > Do you wire your SOAP services into lift or do you keep that independent? i > was just talking to DPP and according to him it appears you can successfully > wire WS-generated code anywhere along in the http-request processing > pipeline. He pointed out a gotcha that i think can be circumvented with > HttpServletResponse trampoline. Both lift and the WS-generated code are > likely to want to be in the driver's seat regarding who's returning the > bytes. But, i think you can just fool the WS-generated code into thinking > it's got an HttpServletResponse that is really a widget that will just write > into the one lift returns. In this way you can write a 1-size-fits-all > return adapter. Is this what you guys are doing, or am i making this too > complicated? > > Best wishes, > > --greg > > -- > L.G. Meredith > Managing Partner > Biosimilarity LLC > 1219 NW 83rd St > Seattle, WA 98117 > > +1 206.650.3740 > > http://biosimilarity.blogspot.com > -- Viktor Klang Rogue Scala-head Blog: klangism.blogspot.com Twttr: viktorklang --~--~-~--~~~---~--~~ 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] Redirecting during stateful snippet instantiation
I have a stateful snippet:
class TemplateEditor
extends StatefulSnippet
{
...
val template =
(TemplateEditor.template.is
openOr
S.redirectTo("chooser", () => {
S.error("Session information lost, please choose what
template to edit again")
}))
...
}
with a companion object holding a RequestVar:
object TemplateEditor
{
/** Request var that is populated with what template is under
edit */
object template extends RequestVar[Box[Template]](Empty)
...
}
The flow is that another page with snippet chooses a template to edit,
and then uses:
S.redirectTo("/editor", () =>
{ TemplateEditor.template(Full(template)) })
to stuff the template to edit into the RequestVar. I'd like for the
state of TemplateEditor to
use the value of the RequestVar, but not to require every link to re-
stuff that RequestVar once
the StatefulSnippet has been instantiated, and not require each
snippet method to be wrapped
with the logic to check the RequestVar and do the redirect if it's not
populated.
The problem I'm running into is that snippet instantiation is
apparently too early to use
S.redirectTo -- the Shortcut exception is being trapped as an
instantiation exception and not
being used as a redirect.
It doesn't look entirely trivial to touch up LiftSession to pass this
through, so I guess
I'm partly soliciting feedback on whether there's a better pattern to
use here (lazy val?) and
partly asking if the behavior as it stands is desired.
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: Attributes question
IMHO:
The problem with
"name" some_new_operator_beside_-> expr
would lead to a handful of overloading as -> in SuperArrowAssoc. Looks
a little messy to me.
Looks like we already have a way to do this:
import Helpers._
"name" -> {node: NodeSeq => mixinAttributes(expr _that_yields_an_Elem)
(node)}
Would that be too ... boilerplate for you?
Br's,
Marius
On Aug 14, 11:18 pm, Naftoli Gugenheim wrote:
> As I mentioned, I wrote some code that allows you to use %> instead of -> to
> preserve the attributes. (I chose it because the % symbol is used to merge
> attributes to an Elem.) The right side can be an Elem or a Box/Option of an
> Elem.
> What do people think of this syntax?
> P.S. Another way is to append ".%%" to an Elem making it into a NodeSeq
> function.
>
> -
>
> marius d. wrote:
>
> The book exposes current functionality for Lift 1.0. If functionality
> X was not intended to be there is a different story, but regardless it
> is there and the way I see it it is OK to be in the book.
>
> Personally I don't see it as defect as preserving attributes (to the
> top level resulting NodeSeq) may be quite handy in certain situations
> even that contradicts David's design intent. But this is just a
> personal opinion. After David removes this, a helper to copy
> attributes is needed IMO. So Naftoli if you want to do this please go
> ahead ... or if you don't want it I'll do it.
>
> Br's,
> Marius
>
> On Aug 14, 7:43 pm, Naftoli Gugenheim wrote:
>
> > The book seems to think it's intentional!
> > But why can't unprefixed nodes by preserved automatically? Maybe there
> > could be a setting?
> > Thanks.
>
> > -
>
> > David Pollak wrote:
>
> > On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim
> > wrote:
>
> > > Exactly!
>
> > > -
> > > Derek Chen-Becker wrote:
>
> > > Basically, you're asking why a bind tag like
>
> > >
>
> > > doesn't preserve the id and class attrs when it binds, but
>
> > >
>
> > > does?
>
> > If bind("ledger", ,
> > "entry" -> )
> > results in anything other than it's a defect.
>
> > Wow... looks like it does... it's a defect and I'll fix it.
>
> > > Derek
>
> > > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim > > >wrote:
>
> > > > Of course you can access it from the snippet. But if you want it to be
> > > > output automatically, then you prefix it with whatever the node's prefix
> > > is.
> > > > In other words, by default it's not outputted.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim > > > >wrote:
>
> > > > > What I would like to do:
> > > > > Name > > > > class="special" style="vertical-align: top" maxlength="5" tabindex="1"
> > > />
> > > > > Okay, just a little contrived...
> > > > > My understanding is you can do this by prefixing the attribute with
> > > > > "lift:"; otherwise it will not be output but is available to the
> > > snippet
> > > > > code, i.e., without the prefix you are making an attribute available
> > > > > to
> > > > the
> > > > > snippet but that's it.
>
> > > > I'm sorry, but I'm still clueless about what you're talking about.
>
> > > > Do you want to bind to and add the attributes in the
> > > > element to the resulting element?
>
> > > > The lift prefix has nothing to do with binding. Binding is done in
> > > > net.liftweb.util and is purely a way of substituting dynamic XML into
> > > well
> > > > defined points in a NodeSeq.
>
> > > > So... if you want to include the attributes of an Elem that you are
> > > > replacing during a bind operation, you have access to the current node
> > > via
> > > > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > > > currentNode.map(_.attributes) openOr Null
>
> > > > > I'm getting this from Exploring Lift page 115.
>
> > > > > -
> > > > > David Pollak wrote:
>
> > > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> > > naftoli...@gmail.com
> > > > > >wrote:
>
> > > > > > Why was the decision made, if I understand correctly, that normal
> > > > > > attributes are not preserved in a bound node, and are are only
> > > > available
> > > > > for
> > > > > > the snippet's usage, and if you want the attribute to be "sticky"
> > > > > > you
> > > > > have
> > > > > > to prefix it with "lift:"? Wouldn't it be better the other way?
>
> > > > > I don't understand your question. Are you talking about
> > > > > Helpers.bind()
> > > > or
> > > > > are you talking about snippet dispatching?
>
> > > > > Can you please provide an example of what happens now and what you
> > > would
> > > > > expect to happen?
>
> > > > > > One of lift's design goals is to help keep the static html in the
> > > view
> > > > > and
> > > > > > the logic in the code, and to provide a templating system that
> > > doesn't
> > > > > > interfere with visual web designers. It see
[Lift] Re: Attributes question
As I mentioned, I wrote some code that allows you to use %> instead of -> to
preserve the attributes. (I chose it because the % symbol is used to merge
attributes to an Elem.) The right side can be an Elem or a Box/Option of an
Elem.
What do people think of this syntax?
P.S. Another way is to append ".%%" to an Elem making it into a NodeSeq
function.
-
marius d. wrote:
The book exposes current functionality for Lift 1.0. If functionality
X was not intended to be there is a different story, but regardless it
is there and the way I see it it is OK to be in the book.
Personally I don't see it as defect as preserving attributes (to the
top level resulting NodeSeq) may be quite handy in certain situations
even that contradicts David's design intent. But this is just a
personal opinion. After David removes this, a helper to copy
attributes is needed IMO. So Naftoli if you want to do this please go
ahead ... or if you don't want it I'll do it.
Br's,
Marius
On Aug 14, 7:43 pm, Naftoli Gugenheim wrote:
> The book seems to think it's intentional!
> But why can't unprefixed nodes by preserved automatically? Maybe there could
> be a setting?
> Thanks.
>
> -
>
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim
> wrote:
>
>
>
>
>
> > Exactly!
>
> > -
> > Derek Chen-Becker wrote:
>
> > Basically, you're asking why a bind tag like
>
> >
>
> > doesn't preserve the id and class attrs when it binds, but
>
> >
>
> > does?
>
> If bind("ledger", ,
> "entry" -> )
> results in anything other than it's a defect.
>
> Wow... looks like it does... it's a defect and I'll fix it.
>
>
>
>
>
> > Derek
>
> > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim > >wrote:
>
> > > Of course you can access it from the snippet. But if you want it to be
> > > output automatically, then you prefix it with whatever the node's prefix
> > is.
> > > In other words, by default it's not outputted.
>
> > > -
> > > David Pollak wrote:
>
> > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim > > >wrote:
>
> > > > What I would like to do:
> > > > Name > > > class="special" style="vertical-align: top" maxlength="5" tabindex="1"
> > />
> > > > Okay, just a little contrived...
> > > > My understanding is you can do this by prefixing the attribute with
> > > > "lift:"; otherwise it will not be output but is available to the
> > snippet
> > > > code, i.e., without the prefix you are making an attribute available to
> > > the
> > > > snippet but that's it.
>
> > > I'm sorry, but I'm still clueless about what you're talking about.
>
> > > Do you want to bind to and add the attributes in the
> > > element to the resulting element?
>
> > > The lift prefix has nothing to do with binding. Binding is done in
> > > net.liftweb.util and is purely a way of substituting dynamic XML into
> > well
> > > defined points in a NodeSeq.
>
> > > So... if you want to include the attributes of an Elem that you are
> > > replacing during a bind operation, you have access to the current node
> > via
> > > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > > currentNode.map(_.attributes) openOr Null
>
> > > > I'm getting this from Exploring Lift page 115.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
>
> > > > > Why was the decision made, if I understand correctly, that normal
> > > > > attributes are not preserved in a bound node, and are are only
> > > available
> > > > for
> > > > > the snippet's usage, and if you want the attribute to be "sticky" you
> > > > have
> > > > > to prefix it with "lift:"? Wouldn't it be better the other way?
>
> > > > I don't understand your question. Are you talking about Helpers.bind()
> > > or
> > > > are you talking about snippet dispatching?
>
> > > > Can you please provide an example of what happens now and what you
> > would
> > > > expect to happen?
>
> > > > > One of lift's design goals is to help keep the static html in the
> > view
> > > > and
> > > > > the logic in the code, and to provide a templating system that
> > doesn't
> > > > > interfere with visual web designers. It seems to me that it would
> > > further
> > > > > this goal if html attributes could be properly specified in the view
> > > > html.
>
> > > > --
> > > > 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 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 frameworkhttp://lift
[Lift] Re: Attributes question
The book exposes current functionality for Lift 1.0. If functionality
X was not intended to be there is a different story, but regardless it
is there and the way I see it it is OK to be in the book.
Personally I don't see it as defect as preserving attributes (to the
top level resulting NodeSeq) may be quite handy in certain situations
even that contradicts David's design intent. But this is just a
personal opinion. After David removes this, a helper to copy
attributes is needed IMO. So Naftoli if you want to do this please go
ahead ... or if you don't want it I'll do it.
Br's,
Marius
On Aug 14, 7:43 pm, Naftoli Gugenheim wrote:
> The book seems to think it's intentional!
> But why can't unprefixed nodes by preserved automatically? Maybe there could
> be a setting?
> Thanks.
>
> -
>
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim
> wrote:
>
>
>
>
>
> > Exactly!
>
> > -
> > Derek Chen-Becker wrote:
>
> > Basically, you're asking why a bind tag like
>
> >
>
> > doesn't preserve the id and class attrs when it binds, but
>
> >
>
> > does?
>
> If bind("ledger", ,
> "entry" -> )
> results in anything other than it's a defect.
>
> Wow... looks like it does... it's a defect and I'll fix it.
>
>
>
>
>
> > Derek
>
> > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim > >wrote:
>
> > > Of course you can access it from the snippet. But if you want it to be
> > > output automatically, then you prefix it with whatever the node's prefix
> > is.
> > > In other words, by default it's not outputted.
>
> > > -
> > > David Pollak wrote:
>
> > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim > > >wrote:
>
> > > > What I would like to do:
> > > > Name > > > class="special" style="vertical-align: top" maxlength="5" tabindex="1"
> > />
> > > > Okay, just a little contrived...
> > > > My understanding is you can do this by prefixing the attribute with
> > > > "lift:"; otherwise it will not be output but is available to the
> > snippet
> > > > code, i.e., without the prefix you are making an attribute available to
> > > the
> > > > snippet but that's it.
>
> > > I'm sorry, but I'm still clueless about what you're talking about.
>
> > > Do you want to bind to and add the attributes in the
> > > element to the resulting element?
>
> > > The lift prefix has nothing to do with binding. Binding is done in
> > > net.liftweb.util and is purely a way of substituting dynamic XML into
> > well
> > > defined points in a NodeSeq.
>
> > > So... if you want to include the attributes of an Elem that you are
> > > replacing during a bind operation, you have access to the current node
> > via
> > > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > > currentNode.map(_.attributes) openOr Null
>
> > > > I'm getting this from Exploring Lift page 115.
>
> > > > -
> > > > David Pollak wrote:
>
> > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
>
> > > > > Why was the decision made, if I understand correctly, that normal
> > > > > attributes are not preserved in a bound node, and are are only
> > > available
> > > > for
> > > > > the snippet's usage, and if you want the attribute to be "sticky" you
> > > > have
> > > > > to prefix it with "lift:"? Wouldn't it be better the other way?
>
> > > > I don't understand your question. Are you talking about Helpers.bind()
> > > or
> > > > are you talking about snippet dispatching?
>
> > > > Can you please provide an example of what happens now and what you
> > would
> > > > expect to happen?
>
> > > > > One of lift's design goals is to help keep the static html in the
> > view
> > > > and
> > > > > the logic in the code, and to provide a templating system that
> > doesn't
> > > > > interfere with visual web designers. It seems to me that it would
> > > further
> > > > > this goal if html attributes could be properly specified in the view
> > > > html.
>
> > > > --
> > > > 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 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 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...@googlegr
[Lift] Re: Attributes question
By the way, there does seem to be some other kind of built in attribute binding
mechanism (BindWithAttr, etc.). How does it work?
-
David Pollak wrote:
On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim wrote:
>
> Where above?
The contents of my messages send 35 minutes ago:
This has nothing to do with snippets. This is below the level of the
snippet. This is the operation of the bind() operation (if I understand
your question correctly.)
With a bind, you are replacing one Elem with a NodeSeq. There are plenty of
helpers that allow you to do this.
If you want to do something that's not provided by the helper, you can write
a function and wrap it in a FuncBindParam to do things the way you want.
Nothing in Lift is stopping that from happening.
How, why is did I make the choice to do a pure substitution rather than
doing something fancier by default:
1. You get what you bind rather than having some attributes magically
added.
2. There's no requirement that you bind an Elem to an Elem... thus if you
bind a NodeSeq, what's the correct behavior (adding attrs to every Elem,
every top-level Elem, the first Elem)?
3. If there is magic, no matter what the rules are, someone will be
confused (look through the archives relating to the newbie issue of not
explicitly setting the return type of snippets to NodeSeq)
So, I believe the default behavior is the correct behavior.
If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.
> Do mean when you said that binding is about inserting xml in well defined
> points?
> If so, I understand that, but it would be convenient if there was a simple
> way that SHtml inputs could take their attributes from the view.
As I said:
*If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.*
But more broadly (and this applies to everyone on the list), it's much
better to speak in code rather than English.
So, had you asked:
bind("ledger", , "entry"
-> )
returns
but:
bind("ledger", , "entry" -> )
returns
Shouldn't it be the other way around?
You would have expressed the same question, but I wouldn't have asked 3
times what you were talking about. You would have framed the question in a
way I (and other folks on the list) could have understood it.
Whether it's posting a ticket or asking a question, put together as much
code as possible will help everyone understand what's going on, get on the
same page, and get to a good answer.
Thanks,
David
>
> -
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim >wrote:
>
> >
> > The book seems to think it's intentional!
>
>
> I'm not sure how the code crept in, but it's wrong and should not have been
> part of Lift.
>
>
> >
> > But why can't unprefixed nodes by preserved automatically?
>
>
> I explained this above.
>
>
> > Maybe there could be a setting?
>
>
> I explained this above as well.
>
>
> >
> > Thanks.
> >
> > -
> > David Pollak wrote:
> >
> > On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim > >wrote:
> >
> > >
> > > Exactly!
> > >
> > > -
> > > Derek Chen-Becker wrote:
> > >
> > > Basically, you're asking why a bind tag like
> > >
> > >
> > >
> > > doesn't preserve the id and class attrs when it binds, but
> > >
> > >
> > >
> > > does?
> > >
> >
> > If bind("ledger", ,
> > "entry" -> )
> > results in anything other than it's a defect.
> >
> > Wow... looks like it does... it's a defect and I'll fix it.
> >
> >
> > >
> > >
> > > Derek
> > >
> > > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > Of course you can access it from the snippet. But if you want it to
> be
> > > > output automatically, then you prefix it with whatever the node's
> > prefix
> > > is.
> > > > In other words, by default it's not outputted.
> > > >
> > > > -
> > > > David Pollak wrote:
> > > >
> > > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > > What I would like to do:
> > > > > Name size="10"
> > > > > class="special" style="vertical-align: top" maxlength="5"
> > tabindex="1"
> > > />
> > > > > Okay, just a little contrived...
> > > > > My understanding is you can do this by prefixing the attribute with
> > > > > "lift:"; otherwise it will not be output but is available to the
> > > snippet
> > > > > code, i.e., without the prefix you are making an attribute
> available
> > to
> > > > the
> > > > > snippet but that's it.
> > > >
> > > >
> > > > I'm sorry, but I'm still clueless about what you're talkin
[Lift] Re: Symlinks and Javascript Files
It is not in my site map. I did try the ResourceServer with the
symlinked script in the 'js' subdir.
Peter
On Aug 14, 6:43 am, Derek Chen-Becker wrote:
> Is the path to that file defined in your SiteMap? In the case of using
> ResourceServer, the "js" that you've tried means that the script should be
> under a "js" subdir.
>
> Derek
>
> On Thu, Aug 13, 2009 at 7:57 PM, Peter Robinett
> wrote:
>
>
>
> > My Lift project is in a git repository and to the repository I've
> > added a submodule. Since right now I only want one javascript file
> > from this submodule, my thought was to make the directory src/main/
> > webroot/js and then make a symbolic link to the javascript file in
> > question. Unfortunately, when I try to request the file at
> >http://localhost:9090/js/jquery.sparkline.js, I get a 403 response
> > that says the page is not defined in my sitemap. There was no note of
> > the request in the stdout.
>
> > Thinking that the js subdirectory is the problem, I then tried making
> > the symlink in the webroot directory and got a 404 error. On stdout it
> > said:
> > 2009-08-13 18:38:23.051::WARN: Aliased resource: file:/Users/peter/
> > Sites/Equal%20Networks/server/src/main/webapp/
> > jquery.sparkline.js==file:/Users/peter/Sites/Equal%20Networks/server/
> > vendors/dashboard/www/jquery.sparkline.js
>
> > From this I gather than Lift is troubled by the presence of a symlink
> > and refused to acknowledge its presence. Is this true? If so, why?
>
> > From the thread last week on ExtJS I see a discussion on loading files
> > in webroot, including supporting a css directory by adding the
> > following to Boot.scala:
> > ResourceServer.allow {
> > case "css" :: _ => true
> > }
>
> > I already have a css file being served from a directory in the exact
> > same location without any additions to Boot.scala. Nonetheless, I
> > tried the following:
> > ResourceServer.allow {
> > case "js" :: _ => true
> > }
>
> > Unfortunately, this had no effect. So, how can I get my symlinked
> > javascript to be server? Or should I just give up on symlinks
> > altogether (I'm not a git master, so perhaps that was the wrong
> > approach anyway).
>
> > Peter Robinett
>
> > PS I'm on 1.1-SNAPSHOT.
> > PPS The YUI Compressor works well. Very cool.
--~--~-~--~~~---~--~~
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] ws-generated code in lift
Tim, Viktor, Do you wire your SOAP services into lift or do you keep that independent? i was just talking to DPP and according to him it appears you can successfully wire WS-generated code anywhere along in the http-request processing pipeline. He pointed out a gotcha that i think can be circumvented with HttpServletResponse trampoline. Both lift and the WS-generated code are likely to want to be in the driver's seat regarding who's returning the bytes. But, i think you can just fool the WS-generated code into thinking it's got an HttpServletResponse that is really a widget that will just write into the one lift returns. In this way you can write a 1-size-fits-all return adapter. Is this what you guys are doing, or am i making this too complicated? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~-~--~~~---~--~~ 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: Attributes question
I guess #2 was what I was looking for. :)
I wrote some code that enables me to bind
"query" %> SHtml.text(clientQuery, clientQuery=_)
which means you're actually binding to a function that preserves the input
node's attributes.
Does anyone like/dislike the syntax or feature?
Thanks.
-
David Pollak wrote:
On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim wrote:
>
> Where above?
The contents of my messages send 35 minutes ago:
This has nothing to do with snippets. This is below the level of the
snippet. This is the operation of the bind() operation (if I understand
your question correctly.)
With a bind, you are replacing one Elem with a NodeSeq. There are plenty of
helpers that allow you to do this.
If you want to do something that's not provided by the helper, you can write
a function and wrap it in a FuncBindParam to do things the way you want.
Nothing in Lift is stopping that from happening.
How, why is did I make the choice to do a pure substitution rather than
doing something fancier by default:
1. You get what you bind rather than having some attributes magically
added.
2. There's no requirement that you bind an Elem to an Elem... thus if you
bind a NodeSeq, what's the correct behavior (adding attrs to every Elem,
every top-level Elem, the first Elem)?
3. If there is magic, no matter what the rules are, someone will be
confused (look through the archives relating to the newbie issue of not
explicitly setting the return type of snippets to NodeSeq)
So, I believe the default behavior is the correct behavior.
If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.
> Do mean when you said that binding is about inserting xml in well defined
> points?
> If so, I understand that, but it would be convenient if there was a simple
> way that SHtml inputs could take their attributes from the view.
As I said:
*If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.*
But more broadly (and this applies to everyone on the list), it's much
better to speak in code rather than English.
So, had you asked:
bind("ledger", , "entry"
-> )
returns
but:
bind("ledger", , "entry" -> )
returns
Shouldn't it be the other way around?
You would have expressed the same question, but I wouldn't have asked 3
times what you were talking about. You would have framed the question in a
way I (and other folks on the list) could have understood it.
Whether it's posting a ticket or asking a question, put together as much
code as possible will help everyone understand what's going on, get on the
same page, and get to a good answer.
Thanks,
David
>
> -
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim >wrote:
>
> >
> > The book seems to think it's intentional!
>
>
> I'm not sure how the code crept in, but it's wrong and should not have been
> part of Lift.
>
>
> >
> > But why can't unprefixed nodes by preserved automatically?
>
>
> I explained this above.
>
>
> > Maybe there could be a setting?
>
>
> I explained this above as well.
>
>
> >
> > Thanks.
> >
> > -
> > David Pollak wrote:
> >
> > On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim > >wrote:
> >
> > >
> > > Exactly!
> > >
> > > -
> > > Derek Chen-Becker wrote:
> > >
> > > Basically, you're asking why a bind tag like
> > >
> > >
> > >
> > > doesn't preserve the id and class attrs when it binds, but
> > >
> > >
> > >
> > > does?
> > >
> >
> > If bind("ledger", ,
> > "entry" -> )
> > results in anything other than it's a defect.
> >
> > Wow... looks like it does... it's a defect and I'll fix it.
> >
> >
> > >
> > >
> > > Derek
> > >
> > > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > Of course you can access it from the snippet. But if you want it to
> be
> > > > output automatically, then you prefix it with whatever the node's
> > prefix
> > > is.
> > > > In other words, by default it's not outputted.
> > > >
> > > > -
> > > > David Pollak wrote:
> > > >
> > > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > > What I would like to do:
> > > > > Name size="10"
> > > > > class="special" style="vertical-align: top" maxlength="5"
> > tabindex="1"
> > > />
> > > > > Okay, just a little contrived...
> > > > > My understanding is you can do this by prefixing the attribute with
> > > > > "lift:"; otherwise it will not be output but is available to the
> > > snippet
> > > > > code, i.e., without the prefix you are making an a
[Lift] Cookie not being removed for custom user logout
I'm seeing some odd behaviour with a cookie I'm setting not being
removed. I'm unsure which phase of my code is broken or how deep my
misunderstandings are here... so I'm looking for some clues.
I'm setting a "keep me logged in" cookie for users of my application.
That works fine using...
val c = HTTPCookie(COOKIE_NAME, encode(user)).setMaxAge(three_months_as_seconds)
S.addCookie(c)
The encode(user) is, when all is said and done, returning the user PK
as the cookie value.
I'm not using ProtoUser, I'm using the scheme outlined in
http://groups.google.com/group/liftweb/msg/85a8e790d5efec26
That is, I have...
object LoginContext {
object userId extends SessionVar[Box[Long]](KeepMeLoggedIn.findUserId)
// etc...
}
...and the findUserId function tries to decode the cookie and find a
matching user:
def findUserId:Box[Long] = for {
cookie <- S.findCookie(COOKIE_NAME);
cookie_value <- cookie.value;
(id, salt) <- decode(cookie_value);
u <- User.find(By(User.id, id),By(User.salt,salt))
} yield {
println(u)
id
}
And that's all working for me.
The problem comes when the user clicks the logout link, and I want to
remove this cookie.
The logout link is:
SHtml.link("/logout", LoginContext.logout, Logout )
... and LoginContext.logout is
KeepMeLoggedIn.removeCookie()
// the above is just: S.deleteCookie(COOKIE_NAME)
userId.remove()
currentUser.remove()
S.request.foreach(_.request.session.terminate)
And for completeness, my /logout page is a redirect to the home page:
Menu(Loc("logout", List("logout") -> false, "Logout", Hidden, If(
()=>false, ()=>RedirectResponse("/index")) ))
What I'm seeing is:
- user clicks logout
- logout function called, and Jetty tells me /logout took N
milliseconds to render
- then I'm seeing activity in the findUserId function, a result is
found, and the user is logged back in again.
- then Jetty tells me /index took N milliseconds to render.
When I dig into HTTP headers, I'm not seeing the cookie value being
set in the response header (which I believe is required to remove it).
I'm guessing my confusion is perhaps over how the SHtml.link magic works?
Any suggestions of where I might poke around next?
I'm using 1.1-SNAPSHOT (updated a few hours ago).
Thank you
Richard
--~--~-~--~~~---~--~~
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: Attributes question
On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim wrote:
>
> Where above?
The contents of my messages send 35 minutes ago:
This has nothing to do with snippets. This is below the level of the
snippet. This is the operation of the bind() operation (if I understand
your question correctly.)
With a bind, you are replacing one Elem with a NodeSeq. There are plenty of
helpers that allow you to do this.
If you want to do something that's not provided by the helper, you can write
a function and wrap it in a FuncBindParam to do things the way you want.
Nothing in Lift is stopping that from happening.
How, why is did I make the choice to do a pure substitution rather than
doing something fancier by default:
1. You get what you bind rather than having some attributes magically
added.
2. There's no requirement that you bind an Elem to an Elem... thus if you
bind a NodeSeq, what's the correct behavior (adding attrs to every Elem,
every top-level Elem, the first Elem)?
3. If there is magic, no matter what the rules are, someone will be
confused (look through the archives relating to the newbie issue of not
explicitly setting the return type of snippets to NodeSeq)
So, I believe the default behavior is the correct behavior.
If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.
> Do mean when you said that binding is about inserting xml in well defined
> points?
> If so, I understand that, but it would be convenient if there was a simple
> way that SHtml inputs could take their attributes from the view.
As I said:
*If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.*
But more broadly (and this applies to everyone on the list), it's much
better to speak in code rather than English.
So, had you asked:
bind("ledger", , "entry"
-> )
returns
but:
bind("ledger", , "entry" -> )
returns
Shouldn't it be the other way around?
You would have expressed the same question, but I wouldn't have asked 3
times what you were talking about. You would have framed the question in a
way I (and other folks on the list) could have understood it.
Whether it's posting a ticket or asking a question, put together as much
code as possible will help everyone understand what's going on, get on the
same page, and get to a good answer.
Thanks,
David
>
> -
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim >wrote:
>
> >
> > The book seems to think it's intentional!
>
>
> I'm not sure how the code crept in, but it's wrong and should not have been
> part of Lift.
>
>
> >
> > But why can't unprefixed nodes by preserved automatically?
>
>
> I explained this above.
>
>
> > Maybe there could be a setting?
>
>
> I explained this above as well.
>
>
> >
> > Thanks.
> >
> > -
> > David Pollak wrote:
> >
> > On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim > >wrote:
> >
> > >
> > > Exactly!
> > >
> > > -
> > > Derek Chen-Becker wrote:
> > >
> > > Basically, you're asking why a bind tag like
> > >
> > >
> > >
> > > doesn't preserve the id and class attrs when it binds, but
> > >
> > >
> > >
> > > does?
> > >
> >
> > If bind("ledger", ,
> > "entry" -> )
> > results in anything other than it's a defect.
> >
> > Wow... looks like it does... it's a defect and I'll fix it.
> >
> >
> > >
> > >
> > > Derek
> > >
> > > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > Of course you can access it from the snippet. But if you want it to
> be
> > > > output automatically, then you prefix it with whatever the node's
> > prefix
> > > is.
> > > > In other words, by default it's not outputted.
> > > >
> > > > -
> > > > David Pollak wrote:
> > > >
> > > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > > What I would like to do:
> > > > > Name size="10"
> > > > > class="special" style="vertical-align: top" maxlength="5"
> > tabindex="1"
> > > />
> > > > > Okay, just a little contrived...
> > > > > My understanding is you can do this by prefixing the attribute with
> > > > > "lift:"; otherwise it will not be output but is available to the
> > > snippet
> > > > > code, i.e., without the prefix you are making an attribute
> available
> > to
> > > > the
> > > > > snippet but that's it.
> > > >
> > > >
> > > > I'm sorry, but I'm still clueless about what you're talking about.
> > > >
> > > > Do you want to bind to and add the attributes in the
> > > > element to the resulting element?
> > > >
> > > > The lift prefix has nothing to do with binding. Bindi
[Lift] Re: Skip lift processing for single html file
LiftRules.liftRequest.append {
case Req("foo" :: Nil, _, _) => false
}
On Fri, Aug 14, 2009 at 9:54 AM, jon wrote:
>
> Hi,
>
> How do I tell lift to serve "/foo.html" directly (without parsing xml
> or adding javascript) where "foo.html" is a file that lives in my
> webapp folder? I still want lift to process the rest of my html
> files.
>
> - Jon
> >
>
--
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: Attributes question
Where above? Do mean when you said that binding is about inserting xml in well
defined points?
If so, I understand that, but it would be convenient if there was a simple way
that SHtml inputs could take their attributes from the view.
-
David Pollak wrote:
On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim wrote:
>
> The book seems to think it's intentional!
I'm not sure how the code crept in, but it's wrong and should not have been
part of Lift.
>
> But why can't unprefixed nodes by preserved automatically?
I explained this above.
> Maybe there could be a setting?
I explained this above as well.
>
> Thanks.
>
> -
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim >wrote:
>
> >
> > Exactly!
> >
> > -
> > Derek Chen-Becker wrote:
> >
> > Basically, you're asking why a bind tag like
> >
> >
> >
> > doesn't preserve the id and class attrs when it binds, but
> >
> >
> >
> > does?
> >
>
> If bind("ledger", ,
> "entry" -> )
> results in anything other than it's a defect.
>
> Wow... looks like it does... it's a defect and I'll fix it.
>
>
> >
> >
> > Derek
> >
> > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > >wrote:
> >
> > >
> > > Of course you can access it from the snippet. But if you want it to be
> > > output automatically, then you prefix it with whatever the node's
> prefix
> > is.
> > > In other words, by default it's not outputted.
> > >
> > > -
> > > David Pollak wrote:
> > >
> > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > What I would like to do:
> > > > Name > > > class="special" style="vertical-align: top" maxlength="5"
> tabindex="1"
> > />
> > > > Okay, just a little contrived...
> > > > My understanding is you can do this by prefixing the attribute with
> > > > "lift:"; otherwise it will not be output but is available to the
> > snippet
> > > > code, i.e., without the prefix you are making an attribute available
> to
> > > the
> > > > snippet but that's it.
> > >
> > >
> > > I'm sorry, but I'm still clueless about what you're talking about.
> > >
> > > Do you want to bind to and add the attributes in the
> > > element to the resulting element?
> > >
> > > The lift prefix has nothing to do with binding. Binding is done in
> > > net.liftweb.util and is purely a way of substituting dynamic XML into
> > well
> > > defined points in a NodeSeq.
> > >
> > > So... if you want to include the attributes of an Elem that you are
> > > replacing during a bind operation, you have access to the current node
> > via
> > > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > > currentNode.map(_.attributes) openOr Null
> > >
> > >
> > > >
> > > > I'm getting this from Exploring Lift page 115.
> > > >
> > > >
> > > >
> > > > -
> > > > David Pollak wrote:
> > > >
> > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > > Why was the decision made, if I understand correctly, that normal
> > > > > attributes are not preserved in a bound node, and are are only
> > > available
> > > > for
> > > > > the snippet's usage, and if you want the attribute to be "sticky"
> you
> > > > have
> > > > > to prefix it with "lift:"? Wouldn't it be better the other way?
> > > >
> > > >
> > > > I don't understand your question. Are you talking about
> Helpers.bind()
> > > or
> > > > are you talking about snippet dispatching?
> > > >
> > > > Can you please provide an example of what happens now and what you
> > would
> > > > expect to happen?
> > > >
> > > >
> > > > >
> > > > > One of lift's design goals is to help keep the static html in the
> > view
> > > > and
> > > > > the logic in the code, and to provide a templating system that
> > doesn't
> > > > > interfere with visual web designers. It seems to me that it would
> > > further
> > > > > this goal if html attributes could be properly specified in the
> view
> > > > html.
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> > >
> > > >
> > >
> >
> >
> >
> > >
> >
>
>
> --
> 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.c
[Lift] Skip lift processing for single html file
Hi, How do I tell lift to serve "/foo.html" directly (without parsing xml or adding javascript) where "foo.html" is a file that lives in my webapp folder? I still want lift to process the rest of my html files. - Jon --~--~-~--~~~---~--~~ 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: Attributes question
On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim wrote:
>
> The book seems to think it's intentional!
I'm not sure how the code crept in, but it's wrong and should not have been
part of Lift.
>
> But why can't unprefixed nodes by preserved automatically?
I explained this above.
> Maybe there could be a setting?
I explained this above as well.
>
> Thanks.
>
> -
> David Pollak wrote:
>
> On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim >wrote:
>
> >
> > Exactly!
> >
> > -
> > Derek Chen-Becker wrote:
> >
> > Basically, you're asking why a bind tag like
> >
> >
> >
> > doesn't preserve the id and class attrs when it binds, but
> >
> >
> >
> > does?
> >
>
> If bind("ledger", ,
> "entry" -> )
> results in anything other than it's a defect.
>
> Wow... looks like it does... it's a defect and I'll fix it.
>
>
> >
> >
> > Derek
> >
> > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > >wrote:
> >
> > >
> > > Of course you can access it from the snippet. But if you want it to be
> > > output automatically, then you prefix it with whatever the node's
> prefix
> > is.
> > > In other words, by default it's not outputted.
> > >
> > > -
> > > David Pollak wrote:
> > >
> > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > What I would like to do:
> > > > Name > > > class="special" style="vertical-align: top" maxlength="5"
> tabindex="1"
> > />
> > > > Okay, just a little contrived...
> > > > My understanding is you can do this by prefixing the attribute with
> > > > "lift:"; otherwise it will not be output but is available to the
> > snippet
> > > > code, i.e., without the prefix you are making an attribute available
> to
> > > the
> > > > snippet but that's it.
> > >
> > >
> > > I'm sorry, but I'm still clueless about what you're talking about.
> > >
> > > Do you want to bind to and add the attributes in the
> > > element to the resulting element?
> > >
> > > The lift prefix has nothing to do with binding. Binding is done in
> > > net.liftweb.util and is purely a way of substituting dynamic XML into
> > well
> > > defined points in a NodeSeq.
> > >
> > > So... if you want to include the attributes of an Elem that you are
> > > replacing during a bind operation, you have access to the current node
> > via
> > > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > > currentNode.map(_.attributes) openOr Null
> > >
> > >
> > > >
> > > > I'm getting this from Exploring Lift page 115.
> > > >
> > > >
> > > >
> > > > -
> > > > David Pollak wrote:
> > > >
> > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> > naftoli...@gmail.com
> > > > >wrote:
> > > >
> > > > >
> > > > > Why was the decision made, if I understand correctly, that normal
> > > > > attributes are not preserved in a bound node, and are are only
> > > available
> > > > for
> > > > > the snippet's usage, and if you want the attribute to be "sticky"
> you
> > > > have
> > > > > to prefix it with "lift:"? Wouldn't it be better the other way?
> > > >
> > > >
> > > > I don't understand your question. Are you talking about
> Helpers.bind()
> > > or
> > > > are you talking about snippet dispatching?
> > > >
> > > > Can you please provide an example of what happens now and what you
> > would
> > > > expect to happen?
> > > >
> > > >
> > > > >
> > > > > One of lift's design goals is to help keep the static html in the
> > view
> > > > and
> > > > > the logic in the code, and to provide a templating system that
> > doesn't
> > > > > interfere with visual web designers. It seems to me that it would
> > > further
> > > > > this goal if html attributes could be properly specified in the
> view
> > > > html.
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> > >
> > > >
> > >
> >
> >
> >
> > >
> >
>
>
> --
> 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 becaus
[Lift] Re: Attributes question
The book seems to think it's intentional!
But why can't unprefixed nodes by preserved automatically? Maybe there could be
a setting?
Thanks.
-
David Pollak wrote:
On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim wrote:
>
> Exactly!
>
> -
> Derek Chen-Becker wrote:
>
> Basically, you're asking why a bind tag like
>
>
>
> doesn't preserve the id and class attrs when it binds, but
>
>
>
> does?
>
If bind("ledger", ,
"entry" -> )
results in anything other than it's a defect.
Wow... looks like it does... it's a defect and I'll fix it.
>
>
> Derek
>
> On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim >wrote:
>
> >
> > Of course you can access it from the snippet. But if you want it to be
> > output automatically, then you prefix it with whatever the node's prefix
> is.
> > In other words, by default it's not outputted.
> >
> > -
> > David Pollak wrote:
> >
> > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim > >wrote:
> >
> > >
> > > What I would like to do:
> > > Name > > class="special" style="vertical-align: top" maxlength="5" tabindex="1"
> />
> > > Okay, just a little contrived...
> > > My understanding is you can do this by prefixing the attribute with
> > > "lift:"; otherwise it will not be output but is available to the
> snippet
> > > code, i.e., without the prefix you are making an attribute available to
> > the
> > > snippet but that's it.
> >
> >
> > I'm sorry, but I'm still clueless about what you're talking about.
> >
> > Do you want to bind to and add the attributes in the
> > element to the resulting element?
> >
> > The lift prefix has nothing to do with binding. Binding is done in
> > net.liftweb.util and is purely a way of substituting dynamic XML into
> well
> > defined points in a NodeSeq.
> >
> > So... if you want to include the attributes of an Elem that you are
> > replacing during a bind operation, you have access to the current node
> via
> > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > currentNode.map(_.attributes) openOr Null
> >
> >
> > >
> > > I'm getting this from Exploring Lift page 115.
> > >
> > >
> > >
> > > -
> > > David Pollak wrote:
> > >
> > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > Why was the decision made, if I understand correctly, that normal
> > > > attributes are not preserved in a bound node, and are are only
> > available
> > > for
> > > > the snippet's usage, and if you want the attribute to be "sticky" you
> > > have
> > > > to prefix it with "lift:"? Wouldn't it be better the other way?
> > >
> > >
> > > I don't understand your question. Are you talking about Helpers.bind()
> > or
> > > are you talking about snippet dispatching?
> > >
> > > Can you please provide an example of what happens now and what you
> would
> > > expect to happen?
> > >
> > >
> > > >
> > > > One of lift's design goals is to help keep the static html in the
> view
> > > and
> > > > the logic in the code, and to provide a templating system that
> doesn't
> > > > interfere with visual web designers. It seems to me that it would
> > further
> > > > this goal if html attributes could be properly specified in the view
> > > html.
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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
> >
> >
> >
> > >
> >
>
>
>
> >
>
--
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: Attributes question
On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim wrote:
>
> Exactly!
>
> -
> Derek Chen-Becker wrote:
>
> Basically, you're asking why a bind tag like
>
>
>
> doesn't preserve the id and class attrs when it binds, but
>
>
>
> does?
>
If bind("ledger", ,
"entry" -> )
results in anything other than it's a defect.
Wow... looks like it does... it's a defect and I'll fix it.
>
>
> Derek
>
> On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim >wrote:
>
> >
> > Of course you can access it from the snippet. But if you want it to be
> > output automatically, then you prefix it with whatever the node's prefix
> is.
> > In other words, by default it's not outputted.
> >
> > -
> > David Pollak wrote:
> >
> > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim > >wrote:
> >
> > >
> > > What I would like to do:
> > > Name > > class="special" style="vertical-align: top" maxlength="5" tabindex="1"
> />
> > > Okay, just a little contrived...
> > > My understanding is you can do this by prefixing the attribute with
> > > "lift:"; otherwise it will not be output but is available to the
> snippet
> > > code, i.e., without the prefix you are making an attribute available to
> > the
> > > snippet but that's it.
> >
> >
> > I'm sorry, but I'm still clueless about what you're talking about.
> >
> > Do you want to bind to and add the attributes in the
> > element to the resulting element?
> >
> > The lift prefix has nothing to do with binding. Binding is done in
> > net.liftweb.util and is purely a way of substituting dynamic XML into
> well
> > defined points in a NodeSeq.
> >
> > So... if you want to include the attributes of an Elem that you are
> > replacing during a bind operation, you have access to the current node
> via
> > Helpers.currentNode: Box[Elem] and you can get the attributes:
> > currentNode.map(_.attributes) openOr Null
> >
> >
> > >
> > > I'm getting this from Exploring Lift page 115.
> > >
> > >
> > >
> > > -
> > > David Pollak wrote:
> > >
> > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > > >wrote:
> > >
> > > >
> > > > Why was the decision made, if I understand correctly, that normal
> > > > attributes are not preserved in a bound node, and are are only
> > available
> > > for
> > > > the snippet's usage, and if you want the attribute to be "sticky" you
> > > have
> > > > to prefix it with "lift:"? Wouldn't it be better the other way?
> > >
> > >
> > > I don't understand your question. Are you talking about Helpers.bind()
> > or
> > > are you talking about snippet dispatching?
> > >
> > > Can you please provide an example of what happens now and what you
> would
> > > expect to happen?
> > >
> > >
> > > >
> > > > One of lift's design goals is to help keep the static html in the
> view
> > > and
> > > > the logic in the code, and to provide a templating system that
> doesn't
> > > > interfere with visual web designers. It seems to me that it would
> > further
> > > > this goal if html attributes could be properly specified in the view
> > > html.
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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
> >
> >
> >
> > >
> >
>
>
>
> >
>
--
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: Attributes question
Exactly! - Derek Chen-Becker wrote: Basically, you're asking why a bind tag like doesn't preserve the id and class attrs when it binds, but does? Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim wrote: > > Of course you can access it from the snippet. But if you want it to be > output automatically, then you prefix it with whatever the node's prefix is. > In other words, by default it's not outputted. > > - > David Pollak wrote: > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim >wrote: > > > > > What I would like to do: > > Name > class="special" style="vertical-align: top" maxlength="5" tabindex="1" /> > > Okay, just a little contrived... > > My understanding is you can do this by prefixing the attribute with > > "lift:"; otherwise it will not be output but is available to the snippet > > code, i.e., without the prefix you are making an attribute available to > the > > snippet but that's it. > > > I'm sorry, but I'm still clueless about what you're talking about. > > Do you want to bind to and add the attributes in the > element to the resulting element? > > The lift prefix has nothing to do with binding. Binding is done in > net.liftweb.util and is purely a way of substituting dynamic XML into well > defined points in a NodeSeq. > > So... if you want to include the attributes of an Elem that you are > replacing during a bind operation, you have access to the current node via > Helpers.currentNode: Box[Elem] and you can get the attributes: > currentNode.map(_.attributes) openOr Null > > > > > > I'm getting this from Exploring Lift page 115. > > > > > > > > - > > David Pollak wrote: > > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim > >wrote: > > > > > > > > Why was the decision made, if I understand correctly, that normal > > > attributes are not preserved in a bound node, and are are only > available > > for > > > the snippet's usage, and if you want the attribute to be "sticky" you > > have > > > to prefix it with "lift:"? Wouldn't it be better the other way? > > > > > > I don't understand your question. Are you talking about Helpers.bind() > or > > are you talking about snippet dispatching? > > > > Can you please provide an example of what happens now and what you would > > expect to happen? > > > > > > > > > > One of lift's design goals is to help keep the static html in the view > > and > > > the logic in the code, and to provide a templating system that doesn't > > > interfere with visual web designers. It seems to me that it would > further > > > this goal if html attributes could be properly specified in the view > > html. > > > > > > > > > > > > > > > > > > > -- > > 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: Attributes question
On Fri, Aug 14, 2009 at 9:08 AM, Naftoli Gugenheim wrote: > > Of course you can access it from the snippet. But if you want it to be > output automatically, then you prefix it with whatever the node's prefix is. > In other words, by default it's not outputted. This has nothing to do with snippets. This is below the level of the snippet. This is the operation of the bind() operation (if I understand your question correctly.) With a bind, you are replacing one Elem with a NodeSeq. There are plenty of helpers that allow you to do this. If you want to do something that's not provided by the helper, you can write a function and wrap it in a FuncBindParam to do things the way you want. Nothing in Lift is stopping that from happening. How, why is did I make the choice to do a pure substitution rather than doing something fancier by default: 1. You get what you bind rather than having some attributes magically added. 2. There's no requirement that you bind an Elem to an Elem... thus if you bind a NodeSeq, what's the correct behavior (adding attrs to every Elem, every top-level Elem, the first Elem)? 3. If there is magic, no matter what the rules are, someone will be confused (look through the archives relating to the newbie issue of not explicitly setting the return type of snippets to NodeSeq) So, I believe the default behavior is the correct behavior. If you want to add a helper that will copy attrs from the bound Elem to a newly provided Elem (not anything other than an Elem because of #2 above), you're a committer... you can add it. > > > - > David Pollak wrote: > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim >wrote: > > > > > What I would like to do: > > Name > class="special" style="vertical-align: top" maxlength="5" tabindex="1" /> > > Okay, just a little contrived... > > My understanding is you can do this by prefixing the attribute with > > "lift:"; otherwise it will not be output but is available to the snippet > > code, i.e., without the prefix you are making an attribute available to > the > > snippet but that's it. > > > I'm sorry, but I'm still clueless about what you're talking about. > > Do you want to bind to and add the attributes in the > element to the resulting element? > > The lift prefix has nothing to do with binding. Binding is done in > net.liftweb.util and is purely a way of substituting dynamic XML into well > defined points in a NodeSeq. > > So... if you want to include the attributes of an Elem that you are > replacing during a bind operation, you have access to the current node via > Helpers.currentNode: Box[Elem] and you can get the attributes: > currentNode.map(_.attributes) openOr Null > > > > > > I'm getting this from Exploring Lift page 115. > > > > > > > > - > > David Pollak wrote: > > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim > >wrote: > > > > > > > > Why was the decision made, if I understand correctly, that normal > > > attributes are not preserved in a bound node, and are are only > available > > for > > > the snippet's usage, and if you want the attribute to be "sticky" you > > have > > > to prefix it with "lift:"? Wouldn't it be better the other way? > > > > > > I don't understand your question. Are you talking about Helpers.bind() > or > > are you talking about snippet dispatching? > > > > Can you please provide an example of what happens now and what you would > > expect to happen? > > > > > > > > > > One of lift's design goals is to help keep the static html in the view > > and > > > the logic in the code, and to provide a templating system that doesn't > > > interfere with visual web designers. It seems to me that it would > further > > > this goal if html attributes could be properly specified in the view > > html. > > > > > > > > > > > > > > > > > > > -- > > 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 > > > > > > -- 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: Attributes question
Basically, you're asking why a bind tag like doesn't preserve the id and class attrs when it binds, but does? Derek On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim wrote: > > Of course you can access it from the snippet. But if you want it to be > output automatically, then you prefix it with whatever the node's prefix is. > In other words, by default it's not outputted. > > - > David Pollak wrote: > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim >wrote: > > > > > What I would like to do: > > Name > class="special" style="vertical-align: top" maxlength="5" tabindex="1" /> > > Okay, just a little contrived... > > My understanding is you can do this by prefixing the attribute with > > "lift:"; otherwise it will not be output but is available to the snippet > > code, i.e., without the prefix you are making an attribute available to > the > > snippet but that's it. > > > I'm sorry, but I'm still clueless about what you're talking about. > > Do you want to bind to and add the attributes in the > element to the resulting element? > > The lift prefix has nothing to do with binding. Binding is done in > net.liftweb.util and is purely a way of substituting dynamic XML into well > defined points in a NodeSeq. > > So... if you want to include the attributes of an Elem that you are > replacing during a bind operation, you have access to the current node via > Helpers.currentNode: Box[Elem] and you can get the attributes: > currentNode.map(_.attributes) openOr Null > > > > > > I'm getting this from Exploring Lift page 115. > > > > > > > > - > > David Pollak wrote: > > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim > >wrote: > > > > > > > > Why was the decision made, if I understand correctly, that normal > > > attributes are not preserved in a bound node, and are are only > available > > for > > > the snippet's usage, and if you want the attribute to be "sticky" you > > have > > > to prefix it with "lift:"? Wouldn't it be better the other way? > > > > > > I don't understand your question. Are you talking about Helpers.bind() > or > > are you talking about snippet dispatching? > > > > Can you please provide an example of what happens now and what you would > > expect to happen? > > > > > > > > > > One of lift's design goals is to help keep the static html in the view > > and > > > the logic in the code, and to provide a templating system that doesn't > > > interfere with visual web designers. It seems to me that it would > further > > > this goal if html attributes could be properly specified in the view > > html. > > > > > > > > > > > > > > > > > > > -- > > 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: Attributes question
Of course you can access it from the snippet. But if you want it to be output automatically, then you prefix it with whatever the node's prefix is. In other words, by default it's not outputted. - David Pollak wrote: On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim wrote: > > What I would like to do: > Name class="special" style="vertical-align: top" maxlength="5" tabindex="1" /> > Okay, just a little contrived... > My understanding is you can do this by prefixing the attribute with > "lift:"; otherwise it will not be output but is available to the snippet > code, i.e., without the prefix you are making an attribute available to the > snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to and add the attributes in the element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null > > I'm getting this from Exploring Lift page 115. > > > > - > David Pollak wrote: > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim >wrote: > > > > > Why was the decision made, if I understand correctly, that normal > > attributes are not preserved in a bound node, and are are only available > for > > the snippet's usage, and if you want the attribute to be "sticky" you > have > > to prefix it with "lift:"? Wouldn't it be better the other way? > > > I don't understand your question. Are you talking about Helpers.bind() or > are you talking about snippet dispatching? > > Can you please provide an example of what happens now and what you would > expect to happen? > > > > > > One of lift's design goals is to help keep the static html in the view > and > > the logic in the code, and to provide a templating system that doesn't > > interfere with visual web designers. It seems to me that it would further > > this goal if html attributes could be properly specified in the view > html. > > > > > > > > > > > > -- > 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: how to use BySql query
On Thu, Aug 13, 2009 at 10:26 PM, pravin wrote:
>
> Hi,
> I am new to lift .
> I am using mapper framework.
> i have table emp with name ,salary, location columns
>
>
> now i want to put query to find employee whose salary is less than
> 1 and greater that 1000 and location is California.
>
> For this i am using BySql query...as foolows ->
>
> val emp_List = emp_details.findAll(BySql("salary between ? and ?,
> 1000,1",IHaveValidatedThisSQL("pravin",""2009-08-03)));
The first issue is the misplaced quotes. This is a Scala compiler issue...
the compiler should report a syntax error:
val emp_List = emp_details.findAll(BySql("salary between ? and ?,
1000,1",IHaveValidatedThisSQL("pravin",""2009-08-03)));
Should be:
val emp_List = emp_details.findAll(BySql("salary between ? and ?,
1000,1",IHaveValidatedThisSQL("pravin","2009-08-03")));
But once it compiles, it's still going to result in a run-time error. "salary
between ? and ?, 1000,1" is not valid SQL. You probably want something
like:
val emp_List = emp_details.findAll(BySql("salary between ? and
?",IHaveValidatedThisSQL("pravin","2009-08-03"), 1000, 1));
Note that 1000 and 1 are not part of the query string, but are
parameters bound to the two '?'.
>
> but when i compileing this i get following error ->
>
> java.io.IOException: MALFORMED[1]
>at scala.tools.nsc.io.SourceReader$.decode(SourceReader.scala:
> 134)
>at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:95)
>at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:46)
>at scala.tools.nsc.io.SourceReader.read(SourceReader.scala:65)
>at scala.tools.nsc.Global.getSourceFile(Global.scala:211)
>at scala.tools.nsc.Global.getSourceFile(Global.scala:217)
>at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply
> (Global.scala:667)
>at scala.tools.nsc.Global$Run$$anonfun$compile$1.apply
> (Global.scala:667)
>at scala.List.map(List.scala:805)
>at scala.tools.nsc.Global$Run.compile(Global.scala:667)
>at scala.tools.nsc.Main$.process(Main.scala:73)
>at scala.tools.nsc.Main$.main(Main.scala:87)
>at scala.tools.nsc.Main.main(Main.scala)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
>at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at org.scala_tools.maven.executions.MainHelper.runMain
> (MainHelper.java:105)
>at org.scala_tools.maven.executions.MainWithArgsInFile.main
> (MainWithArgsInFile.java:26)
> error: IO error while decoding C:\Documents and Settings\pravin_karne
> \Scala_workspace\mobworx\src\main\scala\com\mobworx\snip
> pet\DisplayResults.scala with UTF-8
> Please try specifying another one using the -encoding option
> one error found
>
>
>
> So what is cause of this error and is there other way to find it out
>
>
> Thanks in advance
> -Pravin
>
> >
>
--
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: Welcome Joni Freeman to the Lift committers
On Fri, Aug 14, 2009 at 12:31 AM, Jeppe Nejsum Madsen wrote: > > David Pollak writes: > > > * DSL to produce valid JSON > > > > Examples: > > > http://github.com/jonifreeman/liftweb/tree/e2e59b63a427258e7dde9b0877691322c29c8552/lift-json > > Sweet! Will this be integrated with Lift's Js constructs so we can use > this to e.g construct a JsObj? Yeah we may break Lift's JavaScript support out into a separate module which may break some code, but will ultimately result in more flexibility. > > > /Jeppe > > > > > -- 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: Attributes question
On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim wrote: > > What I would like to do: > Name class="special" style="vertical-align: top" maxlength="5" tabindex="1" /> > Okay, just a little contrived... > My understanding is you can do this by prefixing the attribute with > "lift:"; otherwise it will not be output but is available to the snippet > code, i.e., without the prefix you are making an attribute available to the > snippet but that's it. I'm sorry, but I'm still clueless about what you're talking about. Do you want to bind to and add the attributes in the element to the resulting element? The lift prefix has nothing to do with binding. Binding is done in net.liftweb.util and is purely a way of substituting dynamic XML into well defined points in a NodeSeq. So... if you want to include the attributes of an Elem that you are replacing during a bind operation, you have access to the current node via Helpers.currentNode: Box[Elem] and you can get the attributes: currentNode.map(_.attributes) openOr Null > > I'm getting this from Exploring Lift page 115. > > > > - > David Pollak wrote: > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim >wrote: > > > > > Why was the decision made, if I understand correctly, that normal > > attributes are not preserved in a bound node, and are are only available > for > > the snippet's usage, and if you want the attribute to be "sticky" you > have > > to prefix it with "lift:"? Wouldn't it be better the other way? > > > I don't understand your question. Are you talking about Helpers.bind() or > are you talking about snippet dispatching? > > Can you please provide an example of what happens now and what you would > expect to happen? > > > > > > One of lift's design goals is to help keep the static html in the view > and > > the logic in the code, and to provide a templating system that doesn't > > interfere with visual web designers. It seems to me that it would further > > this goal if html attributes could be properly specified in the view > html. > > > > > > > > > > > > -- > 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: Attributes question
Yes, 7.12 vs. 7.13.
Apparently the prefix is not supposed to be lift like I thought but the prefix
of the node it belongs to. But I still have the question. It would seem more
logical that just like nodes, attributes that are prefixed are not html, and
html attributes should not be prefixed. What was the reasoning behind this?
-
marius d. wrote:
What listing from the book are you referring to ? 7.13 ?
and the code:
class Ledger {
def balance (content : NodeSeq ) : NodeSeq = {
bind ("ledger", content,
"time" -> {(new java.util.Date).toString})
}
}
would output
Sat Mar 28 16:43:48 EET 2009.
so ledger:id was preserved in the output node. So class attribute is
not preserved. Is that you are referring to ?
Well ledger:time node is just an xml node meaningless without the
snippet's magic. You can access the unprefixed attributes passed to
this node with BindHelpers.attrs such as
bind ("ledger", content,
"time" -> {node:NodeSeq =>
{(new java.util.Date).toString})}
}
to your questions ... why we preserve the attributes having the same
prefix with the node and not the default ones is simply a design
choice (the way I see it) that by the common prefix there is a hint
that this attribute should stay in the output node. It is not a rock
solid argumentation but kinda makes sense. Unprefixed attributes here
may be attributes that have nothing to do with output node, but rather
with processing logic.
To change this behavior a consensus should be made. Personally I'm not
truly convinced it should be but who knows ...
Br's,
Marius
On Aug 14, 7:06 am, Naftoli Gugenheim wrote:
> What I would like to do:
> Name class="special" style="vertical-align: top" maxlength="5" tabindex="1" />
> Okay, just a little contrived...
> My understanding is you can do this by prefixing the attribute with "lift:";
> otherwise it will not be output but is available to the snippet code, i.e.,
> without the prefix you are making an attribute available to the snippet but
> that's it.
> I'm getting this from Exploring Lift page 115.
>
> -
>
> David Pollak wrote:
>
> On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim
> wrote:
>
>
>
> > Why was the decision made, if I understand correctly, that normal
> > attributes are not preserved in a bound node, and are are only available for
> > the snippet's usage, and if you want the attribute to be "sticky" you have
> > to prefix it with "lift:"? Wouldn't it be better the other way?
>
> I don't understand your question. Are you talking about Helpers.bind() or
> are you talking about snippet dispatching?
>
> Can you please provide an example of what happens now and what you would
> expect to happen?
>
>
>
> > One of lift's design goals is to help keep the static html in the view and
> > the logic in the code, and to provide a templating system that doesn't
> > interfere with visual web designers. It seems to me that it would further
> > this goal if html attributes could be properly specified in the view html.
>
> --
> 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: is that a lift's bug?
On Fri, Aug 14, 2009 at 1:10 AM, xiaomingzhen...@gmail.com <
xiaomingzhen...@gmail.com> wrote:
>
> i am a newer to lift, and now i am reading the book the definitive
> guide to lift. In chapter 5.1, book told me this:
> val helpMenu = Menu(Loc("helpHome",("help" :: "" :: Nil) ->
> true,"Help")) make all the files under help folder accessible, but i
> found the loc object in the Menu item should write like this:
> ("help" :: Nil) -> true. Is that book wrong?
>
> and sometimes i wrote Menu(Loc("Home", "/", "Home")) and got a compile
> wrong, and i have to write Menu(Loc("Home", "/" :: Nil, "Home")). i
> have imported Loc._, why "/" string can not convert to a list? is that
> a lift bug?
>
> besides, does all pages accessible in lift project must be import to
> Sitemap?
No. If you do not declare the sitemap, then all the pages in the app will
be available, however you'll have to manually enforce access control and
manually build menus. You can also define particular directories as
"anything in this directory gets served."
> if so, when the website is large, the work may be tiring?
It's been my experience that having a large site is a very good reason to
have SiteMap... you can have each module define its pages, access control,
etc. and roll that up into a nice menu.
>
>
> >
>
--
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: is that a lift's bug?
That looks like a typo in the book. I'll fix it.
Derek
On Fri, Aug 14, 2009 at 2:10 AM, xiaomingzhen...@gmail.com <
xiaomingzhen...@gmail.com> wrote:
>
> i am a newer to lift, and now i am reading the book the definitive
> guide to lift. In chapter 5.1, book told me this:
> val helpMenu = Menu(Loc("helpHome",("help" :: "" :: Nil) ->
> true,"Help")) make all the files under help folder accessible, but i
> found the loc object in the Menu item should write like this:
> ("help" :: Nil) -> true. Is that book wrong?
>
> and sometimes i wrote Menu(Loc("Home", "/", "Home")) and got a compile
> wrong, and i have to write Menu(Loc("Home", "/" :: Nil, "Home")). i
> have imported Loc._, why "/" string can not convert to a list? is that
> a lift bug?
>
> besides, does all pages accessible in lift project must be import to
> Sitemap? if so, when the website is large, the work may be tiring?
>
> >
>
--~--~-~--~~~---~--~~
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: Symlinks and Javascript Files
Is the path to that file defined in your SiteMap? In the case of using
ResourceServer, the "js" that you've tried means that the script should be
under a "js" subdir.
Derek
On Thu, Aug 13, 2009 at 7:57 PM, Peter Robinett wrote:
>
> My Lift project is in a git repository and to the repository I've
> added a submodule. Since right now I only want one javascript file
> from this submodule, my thought was to make the directory src/main/
> webroot/js and then make a symbolic link to the javascript file in
> question. Unfortunately, when I try to request the file at
> http://localhost:9090/js/jquery.sparkline.js, I get a 403 response
> that says the page is not defined in my sitemap. There was no note of
> the request in the stdout.
>
> Thinking that the js subdirectory is the problem, I then tried making
> the symlink in the webroot directory and got a 404 error. On stdout it
> said:
> 2009-08-13 18:38:23.051::WARN: Aliased resource: file:/Users/peter/
> Sites/Equal%20Networks/server/src/main/webapp/
> jquery.sparkline.js==file:/Users/peter/Sites/Equal%20Networks/server/
> vendors/dashboard/www/jquery.sparkline.js
>
> From this I gather than Lift is troubled by the presence of a symlink
> and refused to acknowledge its presence. Is this true? If so, why?
>
> From the thread last week on ExtJS I see a discussion on loading files
> in webroot, including supporting a css directory by adding the
> following to Boot.scala:
> ResourceServer.allow {
> case "css" :: _ => true
> }
>
> I already have a css file being served from a directory in the exact
> same location without any additions to Boot.scala. Nonetheless, I
> tried the following:
> ResourceServer.allow {
> case "js" :: _ => true
> }
>
> Unfortunately, this had no effect. So, how can I get my symlinked
> javascript to be server? Or should I just give up on symlinks
> altogether (I'm not a git master, so perhaps that was the wrong
> approach anyway).
>
> Peter Robinett
>
> PS I'm on 1.1-SNAPSHOT.
> PPS The YUI Compressor works well. Very cool.
> >
>
--~--~-~--~~~---~--~~
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: Attributes question
What listing from the book are you referring to ? 7.13 ?
and the code:
class Ledger {
def balance (content : NodeSeq ) : NodeSeq = {
bind ("ledger", content,
"time" -> {(new java.util.Date).toString})
}
}
would output
Sat Mar 28 16:43:48 EET 2009.
so ledger:id was preserved in the output node. So class attribute is
not preserved. Is that you are referring to ?
Well ledger:time node is just an xml node meaningless without the
snippet's magic. You can access the unprefixed attributes passed to
this node with BindHelpers.attrs such as
bind ("ledger", content,
"time" -> {node:NodeSeq =>
{(new java.util.Date).toString})}
}
to your questions ... why we preserve the attributes having the same
prefix with the node and not the default ones is simply a design
choice (the way I see it) that by the common prefix there is a hint
that this attribute should stay in the output node. It is not a rock
solid argumentation but kinda makes sense. Unprefixed attributes here
may be attributes that have nothing to do with output node, but rather
with processing logic.
To change this behavior a consensus should be made. Personally I'm not
truly convinced it should be but who knows ...
Br's,
Marius
On Aug 14, 7:06 am, Naftoli Gugenheim wrote:
> What I would like to do:
> Name class="special" style="vertical-align: top" maxlength="5" tabindex="1" />
> Okay, just a little contrived...
> My understanding is you can do this by prefixing the attribute with "lift:";
> otherwise it will not be output but is available to the snippet code, i.e.,
> without the prefix you are making an attribute available to the snippet but
> that's it.
> I'm getting this from Exploring Lift page 115.
>
> -
>
> David Pollak wrote:
>
> On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim
> wrote:
>
>
>
> > Why was the decision made, if I understand correctly, that normal
> > attributes are not preserved in a bound node, and are are only available for
> > the snippet's usage, and if you want the attribute to be "sticky" you have
> > to prefix it with "lift:"? Wouldn't it be better the other way?
>
> I don't understand your question. Are you talking about Helpers.bind() or
> are you talking about snippet dispatching?
>
> Can you please provide an example of what happens now and what you would
> expect to happen?
>
>
>
> > One of lift's design goals is to help keep the static html in the view and
> > the logic in the code, and to provide a templating system that doesn't
> > interfere with visual web designers. It seems to me that it would further
> > this goal if html attributes could be properly specified in the view html.
>
> --
> 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: is that a lift's bug?
"marius d." writes: [...] >> besides, does all pages accessible in lift project must be import to >> Sitemap? > > To access a page you should put it in the SiteMap. You can choose to > not use SiteMap at all but rather work only with DispatchPF and so on, > but for a web application this is impractical. You could also add LiftRules.passNotFoundToChain = true in order to serve static content from your webapp /Jeppe --~--~-~--~~~---~--~~ 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: is that a lift's bug?
On Aug 14, 11:10 am, "xiaomingzhen...@gmail.com"
wrote:
> i am a newer to lift, and now i am reading the book the definitive
> guide to lift. In chapter 5.1, book told me this:
> val helpMenu = Menu(Loc("helpHome",("help" :: "" :: Nil) ->
> true,"Help")) make all the files under help folder accessible, but i
> found the loc object in the Menu item should write like this:
> ("help" :: Nil) -> true. Is that book wrong?
>
> and sometimes i wrote Menu(Loc("Home", "/", "Home")) and got a compile
> wrong, and i have to write Menu(Loc("Home", "/" :: Nil, "Home")). i
> have imported Loc._, why "/" string can not convert to a list? is that
> a lift bug?
String and List are unrelated types. You can write if you want in
implicit conversion function but IMHO is not worth it.
Menu(Loc("Home", List("/"), "Home"))
For this construct Lift already has an implicit conversion
strLstToLink from a Seq[String] to a Link which is what Loc apply
expects.
So List[String] is expected because a path is not expressed as a plain
string but rather as a List of path parts.
>
> besides, does all pages accessible in lift project must be import to
> Sitemap?
To access a page you should put it in the SiteMap. You can choose to
not use SiteMap at all but rather work only with DispatchPF and so on,
but for a web application this is impractical.
>if so, when the website is large, the work may be tiring?
You only define the sitemap once. You can break it to modules etc.
that return specific lists of Menus but that's about application
design. If you're doing RIA style application you'll probably won't
need a tremendous amount of pages anyways.
--~--~-~--~~~---~--~~
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] is that a lift's bug?
i am a newer to lift, and now i am reading the book the definitive
guide to lift. In chapter 5.1, book told me this:
val helpMenu = Menu(Loc("helpHome",("help" :: "" :: Nil) ->
true,"Help")) make all the files under help folder accessible, but i
found the loc object in the Menu item should write like this:
("help" :: Nil) -> true. Is that book wrong?
and sometimes i wrote Menu(Loc("Home", "/", "Home")) and got a compile
wrong, and i have to write Menu(Loc("Home", "/" :: Nil, "Home")). i
have imported Loc._, why "/" string can not convert to a list? is that
a lift bug?
besides, does all pages accessible in lift project must be import to
Sitemap? if so, when the website is large, the work may be tiring?
--~--~-~--~~~---~--~~
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 committers] Welcome Joni Freeman to the Lift committers
Bienvenue On Thu, Aug 13, 2009 at 18:06, David Pollak wrote: > Folks, > > I'm pleased to announce that Joni Freeman has joined the Lift committers. > > Joni will be adding his high performance JSON library as a module in Lift... > and I certainly hope that Lift's JSON support will improve. > > Please join me in welcoming Joni! > > 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] Re: how to use BySql query
pravin writes:
> Hi,
> I am new to lift .
> I am using mapper framework.
> i have table emp with name ,salary, location columns
>
>
> now i want to put query to find employee whose salary is less than
> 1 and greater that 1000 and location is California.
>
> For this i am using BySql query...as foolows ->
>
> val emp_List = emp_details.findAll(BySql("salary between ? and ?,
> 1000,1",IHaveValidatedThisSQL("pravin",""2009-08-03)));
>
> but when i compileing this i get following error ->
I don't think this is problem with your sql (though I think you need to
provide the params as a list as the last parameter:-) but with the
encoding of your source file. Please verify that it is UTF8 encoded if
it contains non-ascii characters or specify the correct encoding when
compiling
/Jeppe
--~--~-~--~~~---~--~~
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: Welcome Joni Freeman to the Lift committers
David Pollak writes: > * DSL to produce valid JSON > > Examples: > http://github.com/jonifreeman/liftweb/tree/e2e59b63a427258e7dde9b0877691322c29c8552/lift-json Sweet! Will this be integrated with Lift's Js constructs so we can use this to e.g construct a JsObj? /Jeppe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
