[Lift] Re: Binding enumerations with radio buttons or select list
Ok, I've made an in depth article on the wiki for this:
http://wiki.github.com/dpp/liftweb/how-to-make-radio-lists-and-drop-downs-from-enumerations
Let me know if I'm missing anything.
Strom
On Oct 28, 5:53 pm, Naftoli Gugenheim wrote:
> The wiki on GitHub. You probably only need a GitHub account.
>
> -
>
> Strom wrote:
>
> I would post on the wiki, but I've never added content to a wiki, and
> I can't create an account for the LiftWiki (only admins can make new
> accounts?). If someone wants to post this information on there
> somewhere, go for it!
>
> Strom
>
> On Oct 28, 5:39 pm, Ross Mellgren wrote:
>
> > +1 -- nice detailed writeup
>
> > -Ross
>
> > On Oct 28, 2009, at 8:38 PM, Naftoli Gugenheim wrote:
>
> > > Why not put it on the wiki? :)
>
> > > -
> > > Strom wrote:
>
> > > Thanks again Ross!
>
> > > I also found out that I could use the ChoiceHolder.toForm method for a
> > > little less customization (saves a ton of code though).
>
> > > The following rundown is for newbies like me who are having trouble
> > > with radio buttons and enumerations. Please see the enumeration
> > > definition in my first post, and also make sure to name your
> > > Enumeration.Value what you want to show to end users, as the following
> > > code uses the Value's toString method to populate the XHTML.
>
> > > XHTML:
> > >
>
> > > Snippet:
> > > def SnippetName(xhtml: NodeSeq) : NodeSeq = {
> > > ...
> > > val radios = SHtml.radio( ExchangeMethod.elements.toList.map
> > > ( _.toString ), Empty,
> > > selected => exchangeMethod = Box
> > > ( ExchangeMethod.valueOf( selected ) )
> > > )
> > > ...
> > > bind( "item", xhtml,
> > > "exchangeMethod" -> radios.toForm
> > > ...//more binding for other tags
> > > )
> > > ...
> > > }
>
> > > Explanation:
> > > 1. The XHTML should be pretty self explanatory, as it's the same as
> > > all other bind tags.
>
> > > 2a. In the snippet, I made a "val radios" that uses the method:
> > > SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
> > > submitFunction: (String) => Any, attributes: (String, String)* )
>
> > > 2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
> > > so I had to use the map method on lists to convert it to List[String],
> > > which matches the SHtml.radio method signature.
>
> > > 2c. There is no default value for the radio choices, so use Empty,
> > > which is the EmptyBox singleton (see "Notes on Box" below).
>
> > > 2d. The function executed on submit is using Box's apply(in: Option
> > > [T]) "constructor" to yield a new Box from an Option, since
> > > ExchangeMethod.valueOf(selected: String) returns an Option.
>
> > > 3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
> > > radio" is actually a ChoiceHolder (more info:
> > >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/C...
> > > ).
>
> > > The actual structure for my "val radio" is
> > > ChoiceHolder( List(
> > > ChoiceItem(Pickup, ...XHTML...),
> > > ChoiceItem(Ship, ...XHTML...),
> > > ChoiceItem(Pickup or Ship, ...XHTML...) ) )
>
> > > You could probably manipulate the XHTML if you wanted to, but I
> > > haven't gotten that far yet.
>
> > > **Notes on Box**
> > > Boxes are like Scala's Option class with extra goodies, so basically
> > > it's just a container for things so you don't get Null Pointer
> > > Exceptions all over the place. Use Full(object) to make a Box that
> > > contains something, or Empty if you want an empty Box. David Pollack
> > > says the Box class and object are moving to net.liftweb.common from
> > > net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
> > > 1.1. However, for my purposes I was using this explanation of Box:
> > >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
>
> > > This post might be overkill, but I figured someone who is completely
> > > lost, like I was, will find some useful information.
>
> > > Strom
>
> > > On Oct 28, 2:47 pm, Ross Mellgren wrote:
> > >> (untested, uncompiled, and generally just a suggestion ;-) )
>
> > >> XHTML:
>
> > >>
> > >>
> > >>
>
> > >> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>
> > >> bind("item", xhtml",
> > >> "exchangeMethod" -> { (ns: NodeSeq) =>
> > >> (SHtml.radio(ExchangeMethod.elements.map
> > >> (_.toString).toList,
> > >> exchangeMethod, s => exchangeMethod =
> > >> ExchangeMethod.valueOf(s))
> > >> .flatMap(choice => bind("method", ns, "input" ->
> > >> choice.xhtml, "label" -> choice.key)))
> > >> })
>
> > >> Note that I didn't do the right thing with the label for each input
> > >> here -- good practices dictates that the label should be wrapped with
> > >> ... for accessibility and clickability.
>
> > >> -Ross
>
> > >> On Oct 28, 2009, at 5:18
[Lift] Re: Proposal : Lift ticketing system
I had actually thought about the upgrade paths for DB schemas and I was thinking of coding up a schema executor that would store a schema version in the db and could then be used to apply appropriate "diff" or "clean" schemas against the DB as needed. I think schemifier generally does a very good job, but this would give more control over exactly what's going on in the DB. As for the custom fields, I think it sounds interesting but I think I want to start with the basic fields as I have them defined and I can look at it more in phase 2. Derek On Wed, Oct 28, 2009 at 3:20 PM, Naftoli Gugenheim wrote: > > I hear that. > Personally I think it would be more maintainable, not less; there's just a > bit more upfront complexity, although it's something I've already done and I > can share my code. You could trivially have flexible user-defined fields. In > my project you can edit the fields and the lookup tables via the web > interface. > Another consideration is, if you add more hardcoded MappedFields at some > point and a user installs the new version, it will have to schemify. So > you're running Schemifier on a populated production database. There isn't > necessarily anything wrong with that though. (Although recently I corrupted > a database that way: maven had upgraded H2 to a newer beta, which thought my > tables didn't exist. So Schemifier created new ones, wiping it out!) > But again, it depends what you want it to be. > > > - > Derek Chen-Becker wrote: > > The goal is to have a system that we can use for Lift's issue tracking. I > don't know that it has to be as big and bad as, say, JIRA, but it needs to > work well, have a reasonable set of features, and be usable by other people > if they want it. I'm open to suggestions on architecture, but at this point > I would like to keep things relatively simple so that this doesn't grow > into > something that I can't finish. > > Derek > > On Wed, Oct 28, 2009 at 2:39 PM, Naftoli Gugenheim >wrote: > > > > > What is the goal of this system? Is it to be a nice, useful ticketing > > system that will serve as a demo to Lift? Or is it also to be a product > that > > will eventually compete with other issue trackers such as Lift? > > If you're thinking big then I would suggest to think in terms of > > flexibility and extensibility. In particular I would not hard code > > attributes of the ticket but, at the cost of more starting complexity, I > > would have the fields be looked up in a table. I have done this more or > less > > in two projects. It's tricky with Mapper but when you get it right is > very > > powerful. I'll try to upload my code later this week if you wish. > Basically > > the idea is that you have a table or tables of fields. Fields come in > > different types, including lookup, which is what priority would be, > except > > that instead of the choices being hard coded they are in a table that is > > editable. So lookup fields specify a lookup table. There can be number > > fields, etc. This way plugins can add fields. For example Trac has a > plugin > > that tracks hours. Of course you could just include every single possible > > field hard coded. It all depends what you're aiming for. > > > > > > > > - > > Derek Chen-Becker wrote: > > > > OK, I just pushed the initial revision of my model to GitHub at > > http://github.com/dchenbecker/LiftTicket. I think that this covers most > of > > the features that Marius discussed in his response. I agree with all of > it, > > although I'm not 100% sure about having both a severity and priority > field > > on the ticket. This was kind of a code vomit, so I'm going to split the > > classes out into separate Scala files once I get some feedback and a > better > > idea of what needs to be done. > > > > Cheers, > > > > Derek > > > > On Mon, Oct 26, 2009 at 12:29 AM, Derek Chen-Becker > > wrote: > > > > > I'm a fan of Trac, which is one incarnation of Wiki+Tracking+Planning. > > I've > > > set up a repo here: > > > > > > http://github.com/dchenbecker/LiftTicket > > > > > > My preference is for this to be an issue tracking system first and a > > > Wiki/CMS second, but I'm open to any and all ideas on how this can be > > > fleshed out. I would also like to plan on doing a couple of iterations > to > > > get it all working. I like Marius' list of features but I'd like to > start > > > with a subset of those and expand it. My first "milestone" would be > > getting > > > it to the point where it could self-host its own planning for > > enhancements > > > and bug tracking, and I think I can do that with a small set of initial > > > features. > > > > > > Derek > > > > > > > > > On Sat, Oct 24, 2009 at 9:17 PM, Naftoli Gugenheim < > naftoli...@gmail.com > > >wrote: > > > > > >> > > >> How about we integrate the wiki, blog, forum, and issue tracker into > the > > >> CMS? ;) > > >> Seriously, maybe it would be a good idea to create a repo and list, > a
[Lift] Re: Get the subfolders and all the files in the Directory in the Lift ?
The best you can hope for is to try to access the ServletContext: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/index.html Specifically, the getResourcePaths call: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletContext.html#getResourcePaths%28java.lang.String%29 On Wed, Oct 28, 2009 at 6:46 PM, Neil.Lv wrote: > > Hi all, > > I have a silly question about the directory. > > How can i get the subfolders and all the files in the specify > directory, such as /images . > > I want to use the Dtree to show these files and folders . > > Thanks for any suggestion ! :) > > Cheers, > Neil > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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] Get the subfolders and all the files in the Directory in the Lift ?
Hi all, I have a silly question about the directory. How can i get the subfolders and all the files in the specify directory, such as /images . I want to use the Dtree to show these files and folders . Thanks for any suggestion ! :) Cheers, Neil --~--~-~--~~~---~--~~ 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: Binding enumerations with radio buttons or select list
The wiki on GitHub. You probably only need a GitHub account.
-
Strom wrote:
I would post on the wiki, but I've never added content to a wiki, and
I can't create an account for the LiftWiki (only admins can make new
accounts?). If someone wants to post this information on there
somewhere, go for it!
Strom
On Oct 28, 5:39 pm, Ross Mellgren wrote:
> +1 -- nice detailed writeup
>
> -Ross
>
> On Oct 28, 2009, at 8:38 PM, Naftoli Gugenheim wrote:
>
>
>
> > Why not put it on the wiki? :)
>
> > -
> > Strom wrote:
>
> > Thanks again Ross!
>
> > I also found out that I could use the ChoiceHolder.toForm method for a
> > little less customization (saves a ton of code though).
>
> > The following rundown is for newbies like me who are having trouble
> > with radio buttons and enumerations. Please see the enumeration
> > definition in my first post, and also make sure to name your
> > Enumeration.Value what you want to show to end users, as the following
> > code uses the Value's toString method to populate the XHTML.
>
> > XHTML:
> >
>
> > Snippet:
> > def SnippetName(xhtml: NodeSeq) : NodeSeq = {
> > ...
> > val radios = SHtml.radio( ExchangeMethod.elements.toList.map
> > ( _.toString ), Empty,
> > selected => exchangeMethod = Box
> > ( ExchangeMethod.valueOf( selected ) )
> > )
> > ...
> > bind( "item", xhtml,
> > "exchangeMethod" -> radios.toForm
> > ...//more binding for other tags
> > )
> > ...
> > }
>
> > Explanation:
> > 1. The XHTML should be pretty self explanatory, as it's the same as
> > all other bind tags.
>
> > 2a. In the snippet, I made a "val radios" that uses the method:
> > SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
> > submitFunction: (String) => Any, attributes: (String, String)* )
>
> > 2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
> > so I had to use the map method on lists to convert it to List[String],
> > which matches the SHtml.radio method signature.
>
> > 2c. There is no default value for the radio choices, so use Empty,
> > which is the EmptyBox singleton (see "Notes on Box" below).
>
> > 2d. The function executed on submit is using Box's apply(in: Option
> > [T]) "constructor" to yield a new Box from an Option, since
> > ExchangeMethod.valueOf(selected: String) returns an Option.
>
> > 3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
> > radio" is actually a ChoiceHolder (more info:
> >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/C...
> > ).
>
> > The actual structure for my "val radio" is
> > ChoiceHolder( List(
> > ChoiceItem(Pickup, ...XHTML...),
> > ChoiceItem(Ship, ...XHTML...),
> > ChoiceItem(Pickup or Ship, ...XHTML...) ) )
>
> > You could probably manipulate the XHTML if you wanted to, but I
> > haven't gotten that far yet.
>
> > **Notes on Box**
> > Boxes are like Scala's Option class with extra goodies, so basically
> > it's just a container for things so you don't get Null Pointer
> > Exceptions all over the place. Use Full(object) to make a Box that
> > contains something, or Empty if you want an empty Box. David Pollack
> > says the Box class and object are moving to net.liftweb.common from
> > net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
> > 1.1. However, for my purposes I was using this explanation of Box:
> >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
>
> > This post might be overkill, but I figured someone who is completely
> > lost, like I was, will find some useful information.
>
> > Strom
>
> > On Oct 28, 2:47 pm, Ross Mellgren wrote:
> >> (untested, uncompiled, and generally just a suggestion ;-) )
>
> >> XHTML:
>
> >>
> >>
> >>
>
> >> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>
> >> bind("item", xhtml",
> >> "exchangeMethod" -> { (ns: NodeSeq) =>
> >> (SHtml.radio(ExchangeMethod.elements.map
> >> (_.toString).toList,
> >> exchangeMethod, s => exchangeMethod =
> >> ExchangeMethod.valueOf(s))
> >> .flatMap(choice => bind("method", ns, "input" ->
> >> choice.xhtml, "label" -> choice.key)))
> >> })
>
> >> Note that I didn't do the right thing with the label for each input
> >> here -- good practices dictates that the label should be wrapped with
> >> ... for accessibility and clickability.
>
> >> -Ross
>
> >> On Oct 28, 2009, at 5:18 PM, Strom wrote:
>
> >>> Hey Ross. Thanks for the tips. I found out you have to call the
> >>> toList
> >>> () method before you can map the enumeration elements.
>
> >>> So it would be like this:
> >>> XTHML:
> >>>
>
> >>> Snippet:
> >>> def SnippetName(xhtml:NodeSeq): NodeSeq = {
> >>> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
> >>> ...
> >>> bind("item", xhtml,
> >>> "exchangeMethod" -> SHtml.selectObj[Ex
[Lift] Re: Binding enumerations with radio buttons or select list
I would post on the wiki, but I've never added content to a wiki, and
I can't create an account for the LiftWiki (only admins can make new
accounts?). If someone wants to post this information on there
somewhere, go for it!
Strom
On Oct 28, 5:39 pm, Ross Mellgren wrote:
> +1 -- nice detailed writeup
>
> -Ross
>
> On Oct 28, 2009, at 8:38 PM, Naftoli Gugenheim wrote:
>
>
>
> > Why not put it on the wiki? :)
>
> > -
> > Strom wrote:
>
> > Thanks again Ross!
>
> > I also found out that I could use the ChoiceHolder.toForm method for a
> > little less customization (saves a ton of code though).
>
> > The following rundown is for newbies like me who are having trouble
> > with radio buttons and enumerations. Please see the enumeration
> > definition in my first post, and also make sure to name your
> > Enumeration.Value what you want to show to end users, as the following
> > code uses the Value's toString method to populate the XHTML.
>
> > XHTML:
> >
>
> > Snippet:
> > def SnippetName(xhtml: NodeSeq) : NodeSeq = {
> > ...
> > val radios = SHtml.radio( ExchangeMethod.elements.toList.map
> > ( _.toString ), Empty,
> > selected => exchangeMethod = Box
> > ( ExchangeMethod.valueOf( selected ) )
> > )
> > ...
> > bind( "item", xhtml,
> > "exchangeMethod" -> radios.toForm
> > ...//more binding for other tags
> > )
> > ...
> > }
>
> > Explanation:
> > 1. The XHTML should be pretty self explanatory, as it's the same as
> > all other bind tags.
>
> > 2a. In the snippet, I made a "val radios" that uses the method:
> > SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
> > submitFunction: (String) => Any, attributes: (String, String)* )
>
> > 2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
> > so I had to use the map method on lists to convert it to List[String],
> > which matches the SHtml.radio method signature.
>
> > 2c. There is no default value for the radio choices, so use Empty,
> > which is the EmptyBox singleton (see "Notes on Box" below).
>
> > 2d. The function executed on submit is using Box's apply(in: Option
> > [T]) "constructor" to yield a new Box from an Option, since
> > ExchangeMethod.valueOf(selected: String) returns an Option.
>
> > 3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
> > radio" is actually a ChoiceHolder (more info:
> >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/C...
> > ).
>
> > The actual structure for my "val radio" is
> > ChoiceHolder( List(
> > ChoiceItem(Pickup, ...XHTML...),
> > ChoiceItem(Ship, ...XHTML...),
> > ChoiceItem(Pickup or Ship, ...XHTML...) ) )
>
> > You could probably manipulate the XHTML if you wanted to, but I
> > haven't gotten that far yet.
>
> > **Notes on Box**
> > Boxes are like Scala's Option class with extra goodies, so basically
> > it's just a container for things so you don't get Null Pointer
> > Exceptions all over the place. Use Full(object) to make a Box that
> > contains something, or Empty if you want an empty Box. David Pollack
> > says the Box class and object are moving to net.liftweb.common from
> > net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
> > 1.1. However, for my purposes I was using this explanation of Box:
> >http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
>
> > This post might be overkill, but I figured someone who is completely
> > lost, like I was, will find some useful information.
>
> > Strom
>
> > On Oct 28, 2:47 pm, Ross Mellgren wrote:
> >> (untested, uncompiled, and generally just a suggestion ;-) )
>
> >> XHTML:
>
> >>
> >>
> >>
>
> >> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>
> >> bind("item", xhtml",
> >> "exchangeMethod" -> { (ns: NodeSeq) =>
> >> (SHtml.radio(ExchangeMethod.elements.map
> >> (_.toString).toList,
> >> exchangeMethod, s => exchangeMethod =
> >> ExchangeMethod.valueOf(s))
> >> .flatMap(choice => bind("method", ns, "input" ->
> >> choice.xhtml, "label" -> choice.key)))
> >> })
>
> >> Note that I didn't do the right thing with the label for each input
> >> here -- good practices dictates that the label should be wrapped with
> >> ... for accessibility and clickability.
>
> >> -Ross
>
> >> On Oct 28, 2009, at 5:18 PM, Strom wrote:
>
> >>> Hey Ross. Thanks for the tips. I found out you have to call the
> >>> toList
> >>> () method before you can map the enumeration elements.
>
> >>> So it would be like this:
> >>> XTHML:
> >>>
>
> >>> Snippet:
> >>> def SnippetName(xhtml:NodeSeq): NodeSeq = {
> >>> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
> >>> ...
> >>> bind("item", xhtml,
> >>> "exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
> >>> ( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
> >>> selected => excha
[Lift] Re: Binding enumerations with radio buttons or select list
+1 -- nice detailed writeup
-Ross
On Oct 28, 2009, at 8:38 PM, Naftoli Gugenheim wrote:
>
> Why not put it on the wiki? :)
>
> -
> Strom wrote:
>
>
> Thanks again Ross!
>
> I also found out that I could use the ChoiceHolder.toForm method for a
> little less customization (saves a ton of code though).
>
> The following rundown is for newbies like me who are having trouble
> with radio buttons and enumerations. Please see the enumeration
> definition in my first post, and also make sure to name your
> Enumeration.Value what you want to show to end users, as the following
> code uses the Value's toString method to populate the XHTML.
>
> XHTML:
>
>
> Snippet:
> def SnippetName(xhtml: NodeSeq) : NodeSeq = {
> ...
> val radios = SHtml.radio( ExchangeMethod.elements.toList.map
> ( _.toString ), Empty,
> selected => exchangeMethod = Box
> ( ExchangeMethod.valueOf( selected ) )
>)
> ...
> bind( "item", xhtml,
>"exchangeMethod" -> radios.toForm
>...//more binding for other tags
> )
> ...
> }
>
> Explanation:
> 1. The XHTML should be pretty self explanatory, as it's the same as
> all other bind tags.
>
> 2a. In the snippet, I made a "val radios" that uses the method:
> SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
> submitFunction: (String) => Any, attributes: (String, String)* )
>
> 2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
> so I had to use the map method on lists to convert it to List[String],
> which matches the SHtml.radio method signature.
>
> 2c. There is no default value for the radio choices, so use Empty,
> which is the EmptyBox singleton (see "Notes on Box" below).
>
> 2d. The function executed on submit is using Box's apply(in: Option
> [T]) "constructor" to yield a new Box from an Option, since
> ExchangeMethod.valueOf(selected: String) returns an Option.
>
> 3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
> radio" is actually a ChoiceHolder (more info:
> http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/ChoiceHolder.html
>
> ).
>
> The actual structure for my "val radio" is
> ChoiceHolder( List(
> ChoiceItem(Pickup, ...XHTML...),
> ChoiceItem(Ship, ...XHTML...),
> ChoiceItem(Pickup or Ship, ...XHTML...) ) )
>
> You could probably manipulate the XHTML if you wanted to, but I
> haven't gotten that far yet.
>
> **Notes on Box**
> Boxes are like Scala's Option class with extra goodies, so basically
> it's just a container for things so you don't get Null Pointer
> Exceptions all over the place. Use Full(object) to make a Box that
> contains something, or Empty if you want an empty Box. David Pollack
> says the Box class and object are moving to net.liftweb.common from
> net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
> 1.1. However, for my purposes I was using this explanation of Box:
> http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
>
> This post might be overkill, but I figured someone who is completely
> lost, like I was, will find some useful information.
>
> Strom
>
> On Oct 28, 2:47 pm, Ross Mellgren wrote:
>> (untested, uncompiled, and generally just a suggestion ;-) )
>>
>> XHTML:
>>
>>
>>
>>
>>
>> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>>
>> bind("item", xhtml",
>> "exchangeMethod" -> { (ns: NodeSeq) =>
>> (SHtml.radio(ExchangeMethod.elements.map
>> (_.toString).toList,
>>exchangeMethod, s => exchangeMethod =
>> ExchangeMethod.valueOf(s))
>>.flatMap(choice => bind("method", ns, "input" ->
>> choice.xhtml, "label" -> choice.key)))
>> })
>>
>> Note that I didn't do the right thing with the label for each input
>> here -- good practices dictates that the label should be wrapped with
>> ... for accessibility and clickability.
>>
>> -Ross
>>
>> On Oct 28, 2009, at 5:18 PM, Strom wrote:
>>
>>
>>
>>> Hey Ross. Thanks for the tips. I found out you have to call the
>>> toList
>>> () method before you can map the enumeration elements.
>>
>>> So it would be like this:
>>> XTHML:
>>>
>>
>>> Snippet:
>>> def SnippetName(xhtml:NodeSeq): NodeSeq = {
>>> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>>> ...
>>> bind("item", xhtml,
>>> "exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
>>> ( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
>>> selected => exchangeMethod = Full(selected) )
>>> ...) //end bind
>>> }
>>
>>> The missing key for me was the type declaration for selectObj. Now
>>> does anyone know how to do the same type of thing with radio
>>> buttons?
>>
>>> On Oct 28, 12:06 pm, Ross Mellgren wrote:
SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map
(el
=> (el, el.toString)), Empty, selected => println(selected))
>>
?
>>
-Ross
>>
On Oct 2
[Lift] Re: Binding enumerations with radio buttons or select list
Why not put it on the wiki? :)
-
Strom wrote:
Thanks again Ross!
I also found out that I could use the ChoiceHolder.toForm method for a
little less customization (saves a ton of code though).
The following rundown is for newbies like me who are having trouble
with radio buttons and enumerations. Please see the enumeration
definition in my first post, and also make sure to name your
Enumeration.Value what you want to show to end users, as the following
code uses the Value's toString method to populate the XHTML.
XHTML:
Snippet:
def SnippetName(xhtml: NodeSeq) : NodeSeq = {
...
val radios = SHtml.radio( ExchangeMethod.elements.toList.map
( _.toString ), Empty,
selected => exchangeMethod = Box
( ExchangeMethod.valueOf( selected ) )
)
...
bind( "item", xhtml,
"exchangeMethod" -> radios.toForm
...//more binding for other tags
)
...
}
Explanation:
1. The XHTML should be pretty self explanatory, as it's the same as
all other bind tags.
2a. In the snippet, I made a "val radios" that uses the method:
SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
submitFunction: (String) => Any, attributes: (String, String)* )
2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
so I had to use the map method on lists to convert it to List[String],
which matches the SHtml.radio method signature.
2c. There is no default value for the radio choices, so use Empty,
which is the EmptyBox singleton (see "Notes on Box" below).
2d. The function executed on submit is using Box's apply(in: Option
[T]) "constructor" to yield a new Box from an Option, since
ExchangeMethod.valueOf(selected: String) returns an Option.
3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
radio" is actually a ChoiceHolder (more info:
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/ChoiceHolder.html).
The actual structure for my "val radio" is
ChoiceHolder( List(
ChoiceItem(Pickup, ...XHTML...),
ChoiceItem(Ship, ...XHTML...),
ChoiceItem(Pickup or Ship, ...XHTML...) ) )
You could probably manipulate the XHTML if you wanted to, but I
haven't gotten that far yet.
**Notes on Box**
Boxes are like Scala's Option class with extra goodies, so basically
it's just a container for things so you don't get Null Pointer
Exceptions all over the place. Use Full(object) to make a Box that
contains something, or Empty if you want an empty Box. David Pollack
says the Box class and object are moving to net.liftweb.common from
net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
1.1. However, for my purposes I was using this explanation of Box:
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
This post might be overkill, but I figured someone who is completely
lost, like I was, will find some useful information.
Strom
On Oct 28, 2:47 pm, Ross Mellgren wrote:
> (untested, uncompiled, and generally just a suggestion ;-) )
>
> XHTML:
>
>
>
>
>
> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>
> bind("item", xhtml",
> "exchangeMethod" -> { (ns: NodeSeq) =>
> (SHtml.radio(ExchangeMethod.elements.map(_.toString).toList,
> exchangeMethod, s => exchangeMethod =
> ExchangeMethod.valueOf(s))
> .flatMap(choice => bind("method", ns, "input" ->
> choice.xhtml, "label" -> choice.key)))
> })
>
> Note that I didn't do the right thing with the label for each input
> here -- good practices dictates that the label should be wrapped with
> ... for accessibility and clickability.
>
> -Ross
>
> On Oct 28, 2009, at 5:18 PM, Strom wrote:
>
>
>
> > Hey Ross. Thanks for the tips. I found out you have to call the toList
> > () method before you can map the enumeration elements.
>
> > So it would be like this:
> > XTHML:
> >
>
> > Snippet:
> > def SnippetName(xhtml:NodeSeq): NodeSeq = {
> > var exchangeMethod: Box[ExchangeMethod.Value] = Empty
> > ...
> > bind("item", xhtml,
> > "exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
> > ( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
> > selected => exchangeMethod = Full(selected) )
> > ...) //end bind
> > }
>
> > The missing key for me was the type declaration for selectObj. Now
> > does anyone know how to do the same type of thing with radio buttons?
>
> > On Oct 28, 12:06 pm, Ross Mellgren wrote:
> >> SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map(el
> >> => (el, el.toString)), Empty, selected => println(selected))
>
> >> ?
>
> >> -Ross
>
> >> On Oct 28, 2009, at 2:59 PM, Strom wrote:
>
> >>> Has anyone figure out how to bind enumerations as radio buttons or a
> >>> drop down list?
>
> >>> I have an enumeration:
> >>> object ExchangeMethod extends Enumeration {
> >>> val Pickup = Value("Pickup")
> >>> val Ship = Value("Ship")
> >>> v
[Lift] Re: Binding enumerations with radio buttons or select list
Thanks again Ross!
I also found out that I could use the ChoiceHolder.toForm method for a
little less customization (saves a ton of code though).
The following rundown is for newbies like me who are having trouble
with radio buttons and enumerations. Please see the enumeration
definition in my first post, and also make sure to name your
Enumeration.Value what you want to show to end users, as the following
code uses the Value's toString method to populate the XHTML.
XHTML:
Snippet:
def SnippetName(xhtml: NodeSeq) : NodeSeq = {
...
val radios = SHtml.radio( ExchangeMethod.elements.toList.map
( _.toString ), Empty,
selected => exchangeMethod = Box
( ExchangeMethod.valueOf( selected ) )
)
...
bind( "item", xhtml,
"exchangeMethod" -> radios.toForm
...//more binding for other tags
)
...
}
Explanation:
1. The XHTML should be pretty self explanatory, as it's the same as
all other bind tags.
2a. In the snippet, I made a "val radios" that uses the method:
SHtml.radio( radioChoices: Seq[String], defaultVal: Box[String],
submitFunction: (String) => Any, attributes: (String, String)* )
2b. ExchangeMethod.elements.toList returns List[ExchangeMethod.Value],
so I had to use the map method on lists to convert it to List[String],
which matches the SHtml.radio method signature.
2c. There is no default value for the radio choices, so use Empty,
which is the EmptyBox singleton (see "Notes on Box" below).
2d. The function executed on submit is using Box's apply(in: Option
[T]) "constructor" to yield a new Box from an Option, since
ExchangeMethod.valueOf(selected: String) returns an Option.
3. Calling radio.toForm XHTML-izes the radio buttons for you. "val
radio" is actually a ChoiceHolder (more info:
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/SHtml/ChoiceHolder.html).
The actual structure for my "val radio" is
ChoiceHolder( List(
ChoiceItem(Pickup, ...XHTML...),
ChoiceItem(Ship, ...XHTML...),
ChoiceItem(Pickup or Ship, ...XHTML...) ) )
You could probably manipulate the XHTML if you wanted to, but I
haven't gotten that far yet.
**Notes on Box**
Boxes are like Scala's Option class with extra goodies, so basically
it's just a container for things so you don't get Null Pointer
Exceptions all over the place. Use Full(object) to make a Box that
contains something, or Empty if you want an empty Box. David Pollack
says the Box class and object are moving to net.liftweb.common from
net.liftweb.util, so just be aware if you're using Lift 1.0 or Lift
1.1. However, for my purposes I was using this explanation of Box:
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/Box.html
This post might be overkill, but I figured someone who is completely
lost, like I was, will find some useful information.
Strom
On Oct 28, 2:47 pm, Ross Mellgren wrote:
> (untested, uncompiled, and generally just a suggestion ;-) )
>
> XHTML:
>
>
>
>
>
> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
>
> bind("item", xhtml",
> "exchangeMethod" -> { (ns: NodeSeq) =>
> (SHtml.radio(ExchangeMethod.elements.map(_.toString).toList,
> exchangeMethod, s => exchangeMethod =
> ExchangeMethod.valueOf(s))
> .flatMap(choice => bind("method", ns, "input" ->
> choice.xhtml, "label" -> choice.key)))
> })
>
> Note that I didn't do the right thing with the label for each input
> here -- good practices dictates that the label should be wrapped with
> ... for accessibility and clickability.
>
> -Ross
>
> On Oct 28, 2009, at 5:18 PM, Strom wrote:
>
>
>
> > Hey Ross. Thanks for the tips. I found out you have to call the toList
> > () method before you can map the enumeration elements.
>
> > So it would be like this:
> > XTHML:
> >
>
> > Snippet:
> > def SnippetName(xhtml:NodeSeq): NodeSeq = {
> > var exchangeMethod: Box[ExchangeMethod.Value] = Empty
> > ...
> > bind("item", xhtml,
> > "exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
> > ( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
> > selected => exchangeMethod = Full(selected) )
> > ...) //end bind
> > }
>
> > The missing key for me was the type declaration for selectObj. Now
> > does anyone know how to do the same type of thing with radio buttons?
>
> > On Oct 28, 12:06 pm, Ross Mellgren wrote:
> >> SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map(el
> >> => (el, el.toString)), Empty, selected => println(selected))
>
> >> ?
>
> >> -Ross
>
> >> On Oct 28, 2009, at 2:59 PM, Strom wrote:
>
> >>> Has anyone figure out how to bind enumerations as radio buttons or a
> >>> drop down list?
>
> >>> I have an enumeration:
> >>> object ExchangeMethod extends Enumeration {
> >>> val Pickup = Value("Pickup")
> >>> val Ship = Value("Ship")
> >>> val PickupOrShip = Value("Pickup or Ship")
> >>> }
>
> >>> And I want to put radio but
[Lift] Re: path based and hostname based UrlRewriting interacting badly
It's a bug. Please open a ticket for it. I'll get it fixed tonight.
On Wed, Oct 28, 2009 at 11:03 AM, harryh wrote:
>
> First, I rewrite URLs like /user/harryh to /user?uid=harryh
> Also, requests to http://m.harryh.org/foo/bar get rewritten to /
> subdomain/mobile/foo/bar
>
> Doing this with the following code:
>
> val urlRewriter: LiftRules.RewritePF = NamedPF("URLRewrite") {
> case RewriteRequest(ParsePath("user" :: uid :: Nil, _, true, _), _,
> _) => {
>RewriteResponse(ParsePath("user" :: Nil, "", true, false), Map
> ("uid" -> uid))
> }
>
> case RewriteRequest(path, _, req) if
> (req.serverName.toLowerCase.startsWith("m.")) => {
>RewriteResponse(ParsePath("subdomain" :: "mobile" ::
> path.partPath, path.suffix, path.absolute, path.endSlash), emptyMap,
> true)
> }
> }
>
> LiftRules.rewrite.append(urlRewriter)
>
> The problem is that emtyMap in the second RewriteResponse. The
> uid=harryh parameter that gets created by the first rewrite rule is
> being destroyed at which point bad things happen.
>
> Is there a better way to do what I am trying to do here?
>
> -harryh
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
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: Binding enumerations with radio buttons or select list
(untested, uncompiled, and generally just a suggestion ;-) )
XHTML:
var exchangeMethod: Box[ExchangeMethod.Value] = Empty
bind("item", xhtml",
"exchangeMethod" -> { (ns: NodeSeq) =>
(SHtml.radio(ExchangeMethod.elements.map(_.toString).toList,
exchangeMethod, s => exchangeMethod =
ExchangeMethod.valueOf(s))
.flatMap(choice => bind("method", ns, "input" ->
choice.xhtml, "label" -> choice.key)))
})
Note that I didn't do the right thing with the label for each input
here -- good practices dictates that the label should be wrapped with
... for accessibility and clickability.
-Ross
On Oct 28, 2009, at 5:18 PM, Strom wrote:
>
> Hey Ross. Thanks for the tips. I found out you have to call the toList
> () method before you can map the enumeration elements.
>
> So it would be like this:
> XTHML:
>
>
> Snippet:
> def SnippetName(xhtml:NodeSeq): NodeSeq = {
> var exchangeMethod: Box[ExchangeMethod.Value] = Empty
> ...
> bind("item", xhtml,
> "exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
> ( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
> selected => exchangeMethod = Full(selected) )
> ...) //end bind
> }
>
> The missing key for me was the type declaration for selectObj. Now
> does anyone know how to do the same type of thing with radio buttons?
>
> On Oct 28, 12:06 pm, Ross Mellgren wrote:
>> SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map(el
>> => (el, el.toString)), Empty, selected => println(selected))
>>
>> ?
>>
>> -Ross
>>
>> On Oct 28, 2009, at 2:59 PM, Strom wrote:
>>
>>
>>
>>> Has anyone figure out how to bind enumerations as radio buttons or a
>>> drop down list?
>>
>>> I have an enumeration:
>>> object ExchangeMethod extends Enumeration {
>>> val Pickup = Value("Pickup")
>>> val Ship = Value("Ship")
>>> val PickupOrShip = Value("Pickup or Ship")
>>> }
>>
>>> And I want to put radio buttons in an html file from this
>>> enumeration
>>> without hardcoding the number of options (say I add another
>>> ExchangeMethod.Value called "Online Transfer").
>>
>>> Basically I'm trying to get this enumeration to display as radio
>>> buttons with text labels for each value in a form that I can
>>> customize
>>> with CSS.
> >
--~--~-~--~~~---~--~~
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: Proposal : Lift ticketing system
I hear that. Personally I think it would be more maintainable, not less; there's just a bit more upfront complexity, although it's something I've already done and I can share my code. You could trivially have flexible user-defined fields. In my project you can edit the fields and the lookup tables via the web interface. Another consideration is, if you add more hardcoded MappedFields at some point and a user installs the new version, it will have to schemify. So you're running Schemifier on a populated production database. There isn't necessarily anything wrong with that though. (Although recently I corrupted a database that way: maven had upgraded H2 to a newer beta, which thought my tables didn't exist. So Schemifier created new ones, wiping it out!) But again, it depends what you want it to be. - Derek Chen-Becker wrote: The goal is to have a system that we can use for Lift's issue tracking. I don't know that it has to be as big and bad as, say, JIRA, but it needs to work well, have a reasonable set of features, and be usable by other people if they want it. I'm open to suggestions on architecture, but at this point I would like to keep things relatively simple so that this doesn't grow into something that I can't finish. Derek On Wed, Oct 28, 2009 at 2:39 PM, Naftoli Gugenheim wrote: > > What is the goal of this system? Is it to be a nice, useful ticketing > system that will serve as a demo to Lift? Or is it also to be a product that > will eventually compete with other issue trackers such as Lift? > If you're thinking big then I would suggest to think in terms of > flexibility and extensibility. In particular I would not hard code > attributes of the ticket but, at the cost of more starting complexity, I > would have the fields be looked up in a table. I have done this more or less > in two projects. It's tricky with Mapper but when you get it right is very > powerful. I'll try to upload my code later this week if you wish. Basically > the idea is that you have a table or tables of fields. Fields come in > different types, including lookup, which is what priority would be, except > that instead of the choices being hard coded they are in a table that is > editable. So lookup fields specify a lookup table. There can be number > fields, etc. This way plugins can add fields. For example Trac has a plugin > that tracks hours. Of course you could just include every single possible > field hard coded. It all depends what you're aiming for. > > > > - > Derek Chen-Becker wrote: > > OK, I just pushed the initial revision of my model to GitHub at > http://github.com/dchenbecker/LiftTicket. I think that this covers most of > the features that Marius discussed in his response. I agree with all of it, > although I'm not 100% sure about having both a severity and priority field > on the ticket. This was kind of a code vomit, so I'm going to split the > classes out into separate Scala files once I get some feedback and a better > idea of what needs to be done. > > Cheers, > > Derek > > On Mon, Oct 26, 2009 at 12:29 AM, Derek Chen-Becker > wrote: > > > I'm a fan of Trac, which is one incarnation of Wiki+Tracking+Planning. > I've > > set up a repo here: > > > > http://github.com/dchenbecker/LiftTicket > > > > My preference is for this to be an issue tracking system first and a > > Wiki/CMS second, but I'm open to any and all ideas on how this can be > > fleshed out. I would also like to plan on doing a couple of iterations to > > get it all working. I like Marius' list of features but I'd like to start > > with a subset of those and expand it. My first "milestone" would be > getting > > it to the point where it could self-host its own planning for > enhancements > > and bug tracking, and I think I can do that with a small set of initial > > features. > > > > Derek > > > > > > On Sat, Oct 24, 2009 at 9:17 PM, Naftoli Gugenheim >wrote: > > > >> > >> How about we integrate the wiki, blog, forum, and issue tracker into the > >> CMS? ;) > >> Seriously, maybe it would be a good idea to create a repo and list, and > >> start serious discussion on all aspects of its design. Maybe it could > become > >> a big community project, with lots of feedback to Lift. > >> > >> > >> - > >> jlist9 wrote: > >> > >> > >> CMS, wiki, blog, forum also sound more interesting than bug tracking > >> system to me :-) > >> > >> On Sat, Oct 24, 2009 at 11:13 AM, aw wrote: > >> > > >> > I don't mean to be negative, but are other options being considered > >> > besides a ticketing system? I kind of wonder if the effort is worth > >> > it when excellent alternatives exist (like JIRA -- their Git > >> > integration may interest you: > >> https://plugins.atlassian.com/plugin/details/4984 > >> > -- I have used their Subversion integration and was very pleased). > >> > > >> > I would be far more interested in seeing something done
[Lift] Re: Binding enumerations with radio buttons or select list
Hey Ross. Thanks for the tips. I found out you have to call the toList
() method before you can map the enumeration elements.
So it would be like this:
XTHML:
Snippet:
def SnippetName(xhtml:NodeSeq): NodeSeq = {
var exchangeMethod: Box[ExchangeMethod.Value] = Empty
...
bind("item", xhtml,
"exchangeMethod" -> SHtml.selectObj[ExchangeMethod.Value]
( ExchangeMethod.elements.toList.map(v => (v,v.toString)), Empty,
selected => exchangeMethod = Full(selected) )
...) //end bind
}
The missing key for me was the type declaration for selectObj. Now
does anyone know how to do the same type of thing with radio buttons?
On Oct 28, 12:06 pm, Ross Mellgren wrote:
> SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map(el
> => (el, el.toString)), Empty, selected => println(selected))
>
> ?
>
> -Ross
>
> On Oct 28, 2009, at 2:59 PM, Strom wrote:
>
>
>
> > Has anyone figure out how to bind enumerations as radio buttons or a
> > drop down list?
>
> > I have an enumeration:
> > object ExchangeMethod extends Enumeration {
> > val Pickup = Value("Pickup")
> > val Ship = Value("Ship")
> > val PickupOrShip = Value("Pickup or Ship")
> > }
>
> > And I want to put radio buttons in an html file from this enumeration
> > without hardcoding the number of options (say I add another
> > ExchangeMethod.Value called "Online Transfer").
>
> > Basically I'm trying to get this enumeration to display as radio
> > buttons with text labels for each value in a form that I can customize
> > with CSS.
--~--~-~--~~~---~--~~
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: Proposal : Lift ticketing system
The goal is to have a system that we can use for Lift's issue tracking. I don't know that it has to be as big and bad as, say, JIRA, but it needs to work well, have a reasonable set of features, and be usable by other people if they want it. I'm open to suggestions on architecture, but at this point I would like to keep things relatively simple so that this doesn't grow into something that I can't finish. Derek On Wed, Oct 28, 2009 at 2:39 PM, Naftoli Gugenheim wrote: > > What is the goal of this system? Is it to be a nice, useful ticketing > system that will serve as a demo to Lift? Or is it also to be a product that > will eventually compete with other issue trackers such as Lift? > If you're thinking big then I would suggest to think in terms of > flexibility and extensibility. In particular I would not hard code > attributes of the ticket but, at the cost of more starting complexity, I > would have the fields be looked up in a table. I have done this more or less > in two projects. It's tricky with Mapper but when you get it right is very > powerful. I'll try to upload my code later this week if you wish. Basically > the idea is that you have a table or tables of fields. Fields come in > different types, including lookup, which is what priority would be, except > that instead of the choices being hard coded they are in a table that is > editable. So lookup fields specify a lookup table. There can be number > fields, etc. This way plugins can add fields. For example Trac has a plugin > that tracks hours. Of course you could just include every single possible > field hard coded. It all depends what you're aiming for. > > > > - > Derek Chen-Becker wrote: > > OK, I just pushed the initial revision of my model to GitHub at > http://github.com/dchenbecker/LiftTicket. I think that this covers most of > the features that Marius discussed in his response. I agree with all of it, > although I'm not 100% sure about having both a severity and priority field > on the ticket. This was kind of a code vomit, so I'm going to split the > classes out into separate Scala files once I get some feedback and a better > idea of what needs to be done. > > Cheers, > > Derek > > On Mon, Oct 26, 2009 at 12:29 AM, Derek Chen-Becker > wrote: > > > I'm a fan of Trac, which is one incarnation of Wiki+Tracking+Planning. > I've > > set up a repo here: > > > > http://github.com/dchenbecker/LiftTicket > > > > My preference is for this to be an issue tracking system first and a > > Wiki/CMS second, but I'm open to any and all ideas on how this can be > > fleshed out. I would also like to plan on doing a couple of iterations to > > get it all working. I like Marius' list of features but I'd like to start > > with a subset of those and expand it. My first "milestone" would be > getting > > it to the point where it could self-host its own planning for > enhancements > > and bug tracking, and I think I can do that with a small set of initial > > features. > > > > Derek > > > > > > On Sat, Oct 24, 2009 at 9:17 PM, Naftoli Gugenheim >wrote: > > > >> > >> How about we integrate the wiki, blog, forum, and issue tracker into the > >> CMS? ;) > >> Seriously, maybe it would be a good idea to create a repo and list, and > >> start serious discussion on all aspects of its design. Maybe it could > become > >> a big community project, with lots of feedback to Lift. > >> > >> > >> - > >> jlist9 wrote: > >> > >> > >> CMS, wiki, blog, forum also sound more interesting than bug tracking > >> system to me :-) > >> > >> On Sat, Oct 24, 2009 at 11:13 AM, aw wrote: > >> > > >> > I don't mean to be negative, but are other options being considered > >> > besides a ticketing system? I kind of wonder if the effort is worth > >> > it when excellent alternatives exist (like JIRA -- their Git > >> > integration may interest you: > >> https://plugins.atlassian.com/plugin/details/4984 > >> > -- I have used their Subversion integration and was very pleased). > >> > > >> > I would be far more interested in seeing something done for the > >> > benefit of the Lift Web Site. (Is it written with Lift?) I don't see > >> > a Lift CMS -- and that is something that could evolve well over time. > >> > I think it is important for a web framework to use their own stuff, > >> > and it should be indicative of the cool things that it can do, > >> > stability, scale, and performance... (I am amazed that I have seen > >> > rather poor demonstrations of this, specifically by Adobe and JBoss -- > >> > but again, I'm not trying to be negative...) > >> > > >> > I see the Lift site integrating Google Analytics... Is that something > >> > that could be "out of the box" with Lift? That could be a selling > >> > point to people making external web sites. > >> > > >> > Another area that would be neat to develop is instrumentation. Sort > >> > of the JMX-Console equivalent for Lift. For scalability and sizing > >>
[Lift] Re: Register new StatefulSnippet
Thanks. I greatly appreciate it. - David Pollak wrote: I opened a ticket for this. I'll expose functionality so you can register stateful snippets as part of the request process. On Sun, Oct 25, 2009 at 1:09 PM, Naftoli Gugenheim wrote: > > This may be more of a feature request than a question. > I generally use StatefulSnippets rather than RequestVars. I have several > places in my Lift webapp where one should be redirected to a screen managed > by a StatefulSnippet. Until recently I thought it would suffice to use > S.mapSnippet to map the StatefulSnippet's method as a function. > However, this approach has two shortcomings: (1) If the page uses multiple > snippet methods it become tedious to write mapSnippet for each one. (2) > Since the snippet can't be registered because it can only get a snippetName > via private[http] API, any stateful links, redirects, or submits don't work. > Of course a workaround may be custom replacement methods on the snippet that > use multiple mapSnippets rather than registerThisSnippet, but again this can > become tedious. > Would it be possible to create a public API either to assign a snippet its > name so it can be registered, or to retreive a snippet by name? Or better > yet, assign its name in its constructor or the first time > registerThisSnippet etc. is called? > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: Proposal : Lift ticketing system
What is the goal of this system? Is it to be a nice, useful ticketing system that will serve as a demo to Lift? Or is it also to be a product that will eventually compete with other issue trackers such as Lift? If you're thinking big then I would suggest to think in terms of flexibility and extensibility. In particular I would not hard code attributes of the ticket but, at the cost of more starting complexity, I would have the fields be looked up in a table. I have done this more or less in two projects. It's tricky with Mapper but when you get it right is very powerful. I'll try to upload my code later this week if you wish. Basically the idea is that you have a table or tables of fields. Fields come in different types, including lookup, which is what priority would be, except that instead of the choices being hard coded they are in a table that is editable. So lookup fields specify a lookup table. There can be number fields, etc. This way plugins can add fields. For example Trac has a plugin that tracks hours. Of course you could just include every single possible field hard coded. It all depends what you're aiming for. - Derek Chen-Becker wrote: OK, I just pushed the initial revision of my model to GitHub at http://github.com/dchenbecker/LiftTicket. I think that this covers most of the features that Marius discussed in his response. I agree with all of it, although I'm not 100% sure about having both a severity and priority field on the ticket. This was kind of a code vomit, so I'm going to split the classes out into separate Scala files once I get some feedback and a better idea of what needs to be done. Cheers, Derek On Mon, Oct 26, 2009 at 12:29 AM, Derek Chen-Becker wrote: > I'm a fan of Trac, which is one incarnation of Wiki+Tracking+Planning. I've > set up a repo here: > > http://github.com/dchenbecker/LiftTicket > > My preference is for this to be an issue tracking system first and a > Wiki/CMS second, but I'm open to any and all ideas on how this can be > fleshed out. I would also like to plan on doing a couple of iterations to > get it all working. I like Marius' list of features but I'd like to start > with a subset of those and expand it. My first "milestone" would be getting > it to the point where it could self-host its own planning for enhancements > and bug tracking, and I think I can do that with a small set of initial > features. > > Derek > > > On Sat, Oct 24, 2009 at 9:17 PM, Naftoli Gugenheim > wrote: > >> >> How about we integrate the wiki, blog, forum, and issue tracker into the >> CMS? ;) >> Seriously, maybe it would be a good idea to create a repo and list, and >> start serious discussion on all aspects of its design. Maybe it could become >> a big community project, with lots of feedback to Lift. >> >> >> - >> jlist9 wrote: >> >> >> CMS, wiki, blog, forum also sound more interesting than bug tracking >> system to me :-) >> >> On Sat, Oct 24, 2009 at 11:13 AM, aw wrote: >> > >> > I don't mean to be negative, but are other options being considered >> > besides a ticketing system? I kind of wonder if the effort is worth >> > it when excellent alternatives exist (like JIRA -- their Git >> > integration may interest you: >> https://plugins.atlassian.com/plugin/details/4984 >> > -- I have used their Subversion integration and was very pleased). >> > >> > I would be far more interested in seeing something done for the >> > benefit of the Lift Web Site. (Is it written with Lift?) I don't see >> > a Lift CMS -- and that is something that could evolve well over time. >> > I think it is important for a web framework to use their own stuff, >> > and it should be indicative of the cool things that it can do, >> > stability, scale, and performance... (I am amazed that I have seen >> > rather poor demonstrations of this, specifically by Adobe and JBoss -- >> > but again, I'm not trying to be negative...) >> > >> > I see the Lift site integrating Google Analytics... Is that something >> > that could be "out of the box" with Lift? That could be a selling >> > point to people making external web sites. >> > >> > Another area that would be neat to develop is instrumentation. Sort >> > of the JMX-Console equivalent for Lift. For scalability and sizing >> > analysis, this would be really useful. >> > >> > >> > Having said that, one major feature that I feel is missing from github >> > is the lack of attachments for an issue. How do you attach test cases >> > or patches for an issue? >> > >> > > >> > >> >> >> >> >> >> > --~--~-~--~~~---~--~~ 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: Binding enumerations with radio buttons or select list
SHtml.selectObj[ExchangeMethod.Value](ExchangeMethod.elements.map(el
=> (el, el.toString)), Empty, selected => println(selected))
?
-Ross
On Oct 28, 2009, at 2:59 PM, Strom wrote:
>
> Has anyone figure out how to bind enumerations as radio buttons or a
> drop down list?
>
> I have an enumeration:
> object ExchangeMethod extends Enumeration {
> val Pickup = Value("Pickup")
> val Ship = Value("Ship")
> val PickupOrShip = Value("Pickup or Ship")
> }
>
> And I want to put radio buttons in an html file from this enumeration
> without hardcoding the number of options (say I add another
> ExchangeMethod.Value called "Online Transfer").
>
> Basically I'm trying to get this enumeration to display as radio
> buttons with text labels for each value in a form that I can customize
> with CSS.
> >
--~--~-~--~~~---~--~~
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] Binding enumerations with radio buttons or select list
Has anyone figure out how to bind enumerations as radio buttons or a
drop down list?
I have an enumeration:
object ExchangeMethod extends Enumeration {
val Pickup = Value("Pickup")
val Ship = Value("Ship")
val PickupOrShip = Value("Pickup or Ship")
}
And I want to put radio buttons in an html file from this enumeration
without hardcoding the number of options (say I add another
ExchangeMethod.Value called "Online Transfer").
Basically I'm trying to get this enumeration to display as radio
buttons with text labels for each value in a form that I can customize
with CSS.
--~--~-~--~~~---~--~~
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] path based and hostname based UrlRewriting interacting badly
First, I rewrite URLs like /user/harryh to /user?uid=harryh
Also, requests to http://m.harryh.org/foo/bar get rewritten to /
subdomain/mobile/foo/bar
Doing this with the following code:
val urlRewriter: LiftRules.RewritePF = NamedPF("URLRewrite") {
case RewriteRequest(ParsePath("user" :: uid :: Nil, _, true, _), _,
_) => {
RewriteResponse(ParsePath("user" :: Nil, "", true, false), Map
("uid" -> uid))
}
case RewriteRequest(path, _, req) if
(req.serverName.toLowerCase.startsWith("m.")) => {
RewriteResponse(ParsePath("subdomain" :: "mobile" ::
path.partPath, path.suffix, path.absolute, path.endSlash), emptyMap,
true)
}
}
LiftRules.rewrite.append(urlRewriter)
The problem is that emtyMap in the second RewriteResponse. The
uid=harryh parameter that gets created by the first rewrite rule is
being destroyed at which point bad things happen.
Is there a better way to do what I am trying to do here?
-harryh
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Changes in 1.1 production mode?
On Wed, Oct 28, 2009 at 9:21 AM, David Pollak wrote:
> Yeah, the signatures are convuluted... gotta change them to
> FactoryMaker[Boolean] rather than FactoryMaker[() => Boolean]
See http://github.com/dpp/liftweb/issues/#issue/141
>
>
>
> On Wed, Oct 28, 2009 at 8:34 AM, Ross Mellgren wrote:
>
>>
>> I had to slog through some factory maker stuff recently. What I found
>> out was that it was amazingly flexible, but that made the simple case
>> non-obvious. For the simple case (set site-wide), the way I found to
>> to do it was
>>
>> factory.default(() => defaultValue)
>>
>> e.g.
>>
>> LiftRules.stripComments.default(() => () => false)
>>
>> The other complication has to do with the fact that you can have
>> scoped values for this, values computed based on current state and so
>> on (if I read all the code correctly), e.g.
>>
>> LiftRules.stripComments.request(computeStripCommentsPerRequest)
>>
>> Personally, I agree it's confusing and it'd be nice if it were
>> consistently used or not.
>>
>> -Ross
>>
>>
>> On Oct 28, 2009, at 11:23 AM, Timothy Perrett wrote:
>>
>> >
>> > Perhaps David can shed more light on it... I didn't write the strip
>> > comments stuff nor the FactoryMaker stuff and David has yet to detail
>> > how that stuff actually works or when it should be used. To that end,
>> > I can see the issue here and don't disagree.
>> >
>> > Cheers, Tim
>> >
>> > On 28 Oct 2009, at 15:20, Yousry Abdallah wrote:
>> >
>> >>
>> >> I downloaded the library source yesterday and stumbled on the
>> >> (abstract) factory pattern in the LiftRules Class.
>> >>
>> >> Do you think this is the desired way to change a parameter?
>> >>
>> >> Sometimes you use simple assignment:
>> >>
>> >> LiftRules.useXhtmlMimeType = false
>> >>
>> >> or you apply a value:
>> >>
>> >> LiftRules.setSiteMap(...)
>> >>
>> >> and now you do:
>> >>
>> >> LiftRules.stripComments(false){}
>> >>
>> >> Could this be simplified?
>> >>
>> >> I think this is confusing and time-consuming at the moment to work
>> >> with LiftRules.
>> >>
>> >> On 28 Okt., 15:00, Timothy Perrett wrote:
>> >>> Looking at the definition:
>> >>>
>> >>> val stripComments: FactoryMaker[() => Boolean] =
>> >>> new FactoryMaker(() => {() => {
>> >>> if (Props.devMode)
>> >>> false
>> >>> else true
>> >>> }}) {}
>> >>>
>> >>> try doing:
>> >>>
>> >>> LiftRules.stripComments(false){}
>> >>>
>> >>> Cheers, Tim
>> >>>
>> >>> On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
>> >>>
>> >>>
>> >>>
>> LiftRules.stripComments(false)
>> >>>
>> generates following error message:
>> >>>
>> Boot.scala:61: error: wrong number of arguments for method apply:
>> ()()
>> => Boolean in trait Vendor
>> LiftRules.stripComments(false)
>> >>>
>> On 27 Okt., 16:52, David Pollak
>> wrote:
>> > Please see LiftRules.stripComments.
>> >>>
>> > You can do LiftRules.stripComments(false)
>> >>>
>> > On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
>> > wrote:
>> >>>
>> >> Hi,
>> >> at the moment I'm testing my application against 1.1 snapshot
>> >> and I
>> >> noticed that while running lift in production mode: "-
>> >> Drun.mode=production" aside from blueprints IE6 fallback:
>> >>>
>> >> " "
>> >>>
>> >> all other comments are removed from the html output.
>> >>>
>> >> I'm using adsense and it is essential to pass "key parameters"
>> >> via
>> >> comments.
>> >>>
>> >> Did I miss some options/parameters to deactivate this new
>> >> feature?
>> >>>
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Surf the harmonics
>> >>>
>> >>
>> >
>> >
>> > >
>>
>>
>> >>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
>
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
Yeah, the signatures are convuluted... gotta change them to
FactoryMaker[Boolean] rather than FactoryMaker[() => Boolean]
On Wed, Oct 28, 2009 at 8:34 AM, Ross Mellgren wrote:
>
> I had to slog through some factory maker stuff recently. What I found
> out was that it was amazingly flexible, but that made the simple case
> non-obvious. For the simple case (set site-wide), the way I found to
> to do it was
>
> factory.default(() => defaultValue)
>
> e.g.
>
> LiftRules.stripComments.default(() => () => false)
>
> The other complication has to do with the fact that you can have
> scoped values for this, values computed based on current state and so
> on (if I read all the code correctly), e.g.
>
> LiftRules.stripComments.request(computeStripCommentsPerRequest)
>
> Personally, I agree it's confusing and it'd be nice if it were
> consistently used or not.
>
> -Ross
>
>
> On Oct 28, 2009, at 11:23 AM, Timothy Perrett wrote:
>
> >
> > Perhaps David can shed more light on it... I didn't write the strip
> > comments stuff nor the FactoryMaker stuff and David has yet to detail
> > how that stuff actually works or when it should be used. To that end,
> > I can see the issue here and don't disagree.
> >
> > Cheers, Tim
> >
> > On 28 Oct 2009, at 15:20, Yousry Abdallah wrote:
> >
> >>
> >> I downloaded the library source yesterday and stumbled on the
> >> (abstract) factory pattern in the LiftRules Class.
> >>
> >> Do you think this is the desired way to change a parameter?
> >>
> >> Sometimes you use simple assignment:
> >>
> >> LiftRules.useXhtmlMimeType = false
> >>
> >> or you apply a value:
> >>
> >> LiftRules.setSiteMap(...)
> >>
> >> and now you do:
> >>
> >> LiftRules.stripComments(false){}
> >>
> >> Could this be simplified?
> >>
> >> I think this is confusing and time-consuming at the moment to work
> >> with LiftRules.
> >>
> >> On 28 Okt., 15:00, Timothy Perrett wrote:
> >>> Looking at the definition:
> >>>
> >>> val stripComments: FactoryMaker[() => Boolean] =
> >>> new FactoryMaker(() => {() => {
> >>> if (Props.devMode)
> >>> false
> >>> else true
> >>> }}) {}
> >>>
> >>> try doing:
> >>>
> >>> LiftRules.stripComments(false){}
> >>>
> >>> Cheers, Tim
> >>>
> >>> On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
> >>>
> >>>
> >>>
> LiftRules.stripComments(false)
> >>>
> generates following error message:
> >>>
> Boot.scala:61: error: wrong number of arguments for method apply:
> ()()
> => Boolean in trait Vendor
> LiftRules.stripComments(false)
> >>>
> On 27 Okt., 16:52, David Pollak
> wrote:
> > Please see LiftRules.stripComments.
> >>>
> > You can do LiftRules.stripComments(false)
> >>>
> > On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
> > wrote:
> >>>
> >> Hi,
> >> at the moment I'm testing my application against 1.1 snapshot
> >> and I
> >> noticed that while running lift in production mode: "-
> >> Drun.mode=production" aside from blueprints IE6 fallback:
> >>>
> >> " "
> >>>
> >> all other comments are removed from the html output.
> >>>
> >> I'm using adsense and it is essential to pass "key parameters"
> >> via
> >> comments.
> >>>
> >> Did I miss some options/parameters to deactivate this new
> >> feature?
> >>>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
> >>>
> >>
> >
> >
> > >
>
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
I had to slog through some factory maker stuff recently. What I found
out was that it was amazingly flexible, but that made the simple case
non-obvious. For the simple case (set site-wide), the way I found to
to do it was
factory.default(() => defaultValue)
e.g.
LiftRules.stripComments.default(() => () => false)
The other complication has to do with the fact that you can have
scoped values for this, values computed based on current state and so
on (if I read all the code correctly), e.g.
LiftRules.stripComments.request(computeStripCommentsPerRequest)
Personally, I agree it's confusing and it'd be nice if it were
consistently used or not.
-Ross
On Oct 28, 2009, at 11:23 AM, Timothy Perrett wrote:
>
> Perhaps David can shed more light on it... I didn't write the strip
> comments stuff nor the FactoryMaker stuff and David has yet to detail
> how that stuff actually works or when it should be used. To that end,
> I can see the issue here and don't disagree.
>
> Cheers, Tim
>
> On 28 Oct 2009, at 15:20, Yousry Abdallah wrote:
>
>>
>> I downloaded the library source yesterday and stumbled on the
>> (abstract) factory pattern in the LiftRules Class.
>>
>> Do you think this is the desired way to change a parameter?
>>
>> Sometimes you use simple assignment:
>>
>> LiftRules.useXhtmlMimeType = false
>>
>> or you apply a value:
>>
>> LiftRules.setSiteMap(...)
>>
>> and now you do:
>>
>> LiftRules.stripComments(false){}
>>
>> Could this be simplified?
>>
>> I think this is confusing and time-consuming at the moment to work
>> with LiftRules.
>>
>> On 28 Okt., 15:00, Timothy Perrett wrote:
>>> Looking at the definition:
>>>
>>> val stripComments: FactoryMaker[() => Boolean] =
>>> new FactoryMaker(() => {() => {
>>> if (Props.devMode)
>>> false
>>> else true
>>> }}) {}
>>>
>>> try doing:
>>>
>>> LiftRules.stripComments(false){}
>>>
>>> Cheers, Tim
>>>
>>> On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
>>>
>>>
>>>
LiftRules.stripComments(false)
>>>
generates following error message:
>>>
Boot.scala:61: error: wrong number of arguments for method apply:
()()
=> Boolean in trait Vendor
LiftRules.stripComments(false)
>>>
On 27 Okt., 16:52, David Pollak
wrote:
> Please see LiftRules.stripComments.
>>>
> You can do LiftRules.stripComments(false)
>>>
> On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
> wrote:
>>>
>> Hi,
>> at the moment I'm testing my application against 1.1 snapshot
>> and I
>> noticed that while running lift in production mode: "-
>> Drun.mode=production" aside from blueprints IE6 fallback:
>>>
>> " "
>>>
>> all other comments are removed from the html output.
>>>
>> I'm using adsense and it is essential to pass "key parameters"
>> via
>> comments.
>>>
>> Did I miss some options/parameters to deactivate this new
>> feature?
>>>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics
>>>
>>
>
>
> >
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
Perhaps David can shed more light on it... I didn't write the strip
comments stuff nor the FactoryMaker stuff and David has yet to detail
how that stuff actually works or when it should be used. To that end,
I can see the issue here and don't disagree.
Cheers, Tim
On 28 Oct 2009, at 15:20, Yousry Abdallah wrote:
>
> I downloaded the library source yesterday and stumbled on the
> (abstract) factory pattern in the LiftRules Class.
>
> Do you think this is the desired way to change a parameter?
>
> Sometimes you use simple assignment:
>
> LiftRules.useXhtmlMimeType = false
>
> or you apply a value:
>
> LiftRules.setSiteMap(...)
>
> and now you do:
>
> LiftRules.stripComments(false){}
>
> Could this be simplified?
>
> I think this is confusing and time-consuming at the moment to work
> with LiftRules.
>
> On 28 Okt., 15:00, Timothy Perrett wrote:
>> Looking at the definition:
>>
>>val stripComments: FactoryMaker[() => Boolean] =
>>new FactoryMaker(() => {() => {
>> if (Props.devMode)
>> false
>> else true
>>}}) {}
>>
>> try doing:
>>
>> LiftRules.stripComments(false){}
>>
>> Cheers, Tim
>>
>> On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
>>
>>
>>
>>> LiftRules.stripComments(false)
>>
>>> generates following error message:
>>
>>> Boot.scala:61: error: wrong number of arguments for method apply:
>>> ()()
>>> => Boolean in trait Vendor
>>>LiftRules.stripComments(false)
>>
>>> On 27 Okt., 16:52, David Pollak
>>> wrote:
Please see LiftRules.stripComments.
>>
You can do LiftRules.stripComments(false)
>>
On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
wrote:
>>
> Hi,
> at the moment I'm testing my application against 1.1 snapshot
> and I
> noticed that while running lift in production mode: "-
> Drun.mode=production" aside from blueprints IE6 fallback:
>>
> " "
>>
> all other comments are removed from the html output.
>>
> I'm using adsense and it is essential to pass "key parameters"
> via
> comments.
>>
> Did I miss some options/parameters to deactivate this new feature?
>>
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
> >
>
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
I downloaded the library source yesterday and stumbled on the
(abstract) factory pattern in the LiftRules Class.
Do you think this is the desired way to change a parameter?
Sometimes you use simple assignment:
LiftRules.useXhtmlMimeType = false
or you apply a value:
LiftRules.setSiteMap(...)
and now you do:
LiftRules.stripComments(false){}
Could this be simplified?
I think this is confusing and time-consuming at the moment to work
with LiftRules.
On 28 Okt., 15:00, Timothy Perrett wrote:
> Looking at the definition:
>
> val stripComments: FactoryMaker[() => Boolean] =
> new FactoryMaker(() => {() => {
> if (Props.devMode)
> false
> else true
> }}) {}
>
> try doing:
>
> LiftRules.stripComments(false){}
>
> Cheers, Tim
>
> On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
>
>
>
> > LiftRules.stripComments(false)
>
> > generates following error message:
>
> > Boot.scala:61: error: wrong number of arguments for method apply: ()()
> > => Boolean in trait Vendor
> > LiftRules.stripComments(false)
>
> > On 27 Okt., 16:52, David Pollak wrote:
> >> Please see LiftRules.stripComments.
>
> >> You can do LiftRules.stripComments(false)
>
> >> On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
> >> wrote:
>
> >>> Hi,
> >>> at the moment I'm testing my application against 1.1 snapshot and I
> >>> noticed that while running lift in production mode: "-
> >>> Drun.mode=production" aside from blueprints IE6 fallback:
>
> >>> " "
>
> >>> all other comments are removed from the html output.
>
> >>> I'm using adsense and it is essential to pass "key parameters" via
> >>> comments.
>
> >>> Did I miss some options/parameters to deactivate this new feature?
>
> >> --
> >> Lift, the simply functional web frameworkhttp://liftweb.net
> >> Beginning Scalahttp://www.apress.com/book/view/1430219890
> >> Follow me:http://twitter.com/dpp
> >> Surf the harmonics
--~--~-~--~~~---~--~~
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] Newbie problem: MenuWidget does not display deeper menu elements
The lift-modules/lift-widgets test Boot.scala contains menu entries:
val entries = Menu(Loc("Home", List("index"), "Home"),
Menu(Loc("submenu1", List("submenu1"), "submenu1")),
Menu(Loc("submenu2", List("submenu2"), "submenu2")),
Menu(Loc("submenu3", List("submenu3"), "submenu3"),
Menu(Loc("anothermenu1", List("anothermenu1"),
"anothermenu1")),
Menu(Loc("anothermenu2", List("anothermenu2"),
"anothermenu2" ::
Menu(Loc("calmonth", List("calmonth"), "CalendarMonthView")) ::
Menu(Loc("calweek", List("calweek"), "CalendarWeekView")) ::
Menu(Loc("calday", List("calday"), "CalendarDayView")) ::
Menu(Loc("rssfeed", List("rssfeed"), "RSSFeed")) ::
Menu(Loc("gravatear", List("gravatar"), "Gravatar")) ::
Menu(Loc("tree", List("tree"), "Tree")) ::
Menu(Loc("sparklines", List("sparklines"), "SparkLines")) ::
Menu(Loc("autocomplete", List("autocomplete"),
"autocomplete")) ::
Menu(Loc("uploadprogress", List("uploadprogress"), "Upload
Progress")) ::
Nil
The submenu3 does not allow to open deeper menu level
{anothermenu1,anothermenu2}
in "Lift Widgets - Test Site".
Is there way to solve the problem?
Regards,
Vytautas
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
Looking at the definition:
val stripComments: FactoryMaker[() => Boolean] =
new FactoryMaker(() => {() => {
if (Props.devMode)
false
else true
}}) {}
try doing:
LiftRules.stripComments(false){}
Cheers, Tim
On 28 Oct 2009, at 13:22, Yousry Abdallah wrote:
>
> LiftRules.stripComments(false)
>
> generates following error message:
>
> Boot.scala:61: error: wrong number of arguments for method apply: ()()
> => Boolean in trait Vendor
>LiftRules.stripComments(false)
>
>
> On 27 Okt., 16:52, David Pollak wrote:
>> Please see LiftRules.stripComments.
>>
>> You can do LiftRules.stripComments(false)
>>
>>
>>
>> On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah
>> wrote:
>>
>>> Hi,
>>> at the moment I'm testing my application against 1.1 snapshot and I
>>> noticed that while running lift in production mode: "-
>>> Drun.mode=production" aside from blueprints IE6 fallback:
>>
>>> " "
>>
>>> all other comments are removed from the html output.
>>
>>> I'm using adsense and it is essential to pass "key parameters" via
>>> comments.
>>
>>> Did I miss some options/parameters to deactivate this new feature?
>>
>> --
>> Lift, the simply functional web frameworkhttp://liftweb.net
>> Beginning Scalahttp://www.apress.com/book/view/1430219890
>> Follow me:http://twitter.com/dpp
>> Surf the harmonics
>
> >
>
--~--~-~--~~~---~--~~
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: global exception page
Yes. Thanks alot Tim.
On Wed, Oct 28, 2009 at 9:32 AM, Timothy Perrett wrote:
>
> Jack,
>
> LiftRules.exceptionHandler.prepend {
> case (Props.RunModes.Production, r, e) => {
> Log.error("IMPORTANT IMPORTANT IMPORTANT: Unhandeled error
> occoured!!",e)
> // your LiftResponse here
>RedirectResponse("/error")
> }
> }
>
> Does that clear it up for you...?
>
> Cheers, Tim
>
> On 28 Oct 2009, at 13:17, jack wrote:
>
> >
> > I would like to have one error page that appears when any exception
> > occurs. How would I do that?
> > >
> >
>
>
> >
>
--
Jack Widman
co-founder / cto, Authoritude, Inc.
203-641-9355
--~--~-~--~~~---~--~~
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: Changes in 1.1 production mode?
LiftRules.stripComments(false) generates following error message: Boot.scala:61: error: wrong number of arguments for method apply: ()() => Boolean in trait Vendor LiftRules.stripComments(false) On 27 Okt., 16:52, David Pollak wrote: > Please see LiftRules.stripComments. > > You can do LiftRules.stripComments(false) > > > > On Tue, Oct 27, 2009 at 8:18 AM, Yousry Abdallah wrote: > > > Hi, > > at the moment I'm testing my application against 1.1 snapshot and I > > noticed that while running lift in production mode: "- > > Drun.mode=production" aside from blueprints IE6 fallback: > > > " " > > > all other comments are removed from the html output. > > > I'm using adsense and it is essential to pass "key parameters" via > > comments. > > > Did I miss some options/parameters to deactivate this new feature? > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics --~--~-~--~~~---~--~~ 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: global exception page
Jack,
LiftRules.exceptionHandler.prepend {
case (Props.RunModes.Production, r, e) => {
Log.error("IMPORTANT IMPORTANT IMPORTANT: Unhandeled error
occoured!!",e)
// your LiftResponse here
RedirectResponse("/error")
}
}
Does that clear it up for you...?
Cheers, Tim
On 28 Oct 2009, at 13:17, jack wrote:
>
> I would like to have one error page that appears when any exception
> occurs. How would I do that?
> >
>
--~--~-~--~~~---~--~~
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] global exception page
I would like to have one error page that appears when any exception occurs. How would I do that? --~--~-~--~~~---~--~~ 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: Possible bug in xml to json conversion
Hi Jonathan,
Current toJson conversion does not support this case very well. The
transformation rule is such that from each leaf XML element a JSON
field is generated.
foo ->
"stats":"foo"
And if that leaf element contains attributes we do not convert it
automatically to JSON object as you expected. Instead, another field
at same level is created:
foo ->
"stats":"foo"
"count":"0"
In your case the leaf node is empty, therefore you will get a field
with null value:
->
"stats":null
"count":"0"
You can fix this for instance by postprocessing the generated JSON. In
this case it is a bit involved and verbose (example below fixes
'stats' element, similar conversion is required for 'messages'
element):
val json = toJson(xml1) map {
case JField("count", JString(count)) => JObject(JField("count", JInt
(count.toInt)) :: Nil) // lift to object
case JField("stats", _) => JNothing // remove null field
case x => x
} map {
case JField("count", x: JObject) => JField("stats", x) // rename
field "count" to "stats"
case x => x
}
Note, the conversion rule which you expected is a perfectly valid
conversion too. The rationale behind the current rule is that it never
makes conversions which changes resulting JSON structure when
attributes are missing. It is therefore more predictable. This blog
post summarizes some other valid conversion rules
http://onwebdevelopment.blogspot.com/2008/05/converting-xml-to-json.html
We could add support for other conversion rules if there's a strong
pressure to do so. But my current preference is to use a simple rule
and then handle corner cases using transformation pipelines (using
'map' function).
PS. The very last example you gave contains a bug which I try to nail
down today. XML is parsed differently when all elements are in same
line. Thanks for good examples!
Cheers Joni
On 28 loka, 09:24, Jonathan Ferguson wrote:
> Depending on the structure of the XML, attributes and child elements
> are being lost. This can be seen in example 4, where the attribute
> expiry_date and the child element status have been dropped.
>
> It would also appear when XML is being converted to JSON attributes
> are being flattened to elements. I'm not sure if this is expected or
> not, this can be seen in examples 1,2 & 3. The child
> element status with attribute count is converted to two attributes
> status with a value of null and count with the correct value.
>
> To test I added the following before the closing brace of
> XmlExamplesTest.scala in lift-json.
>
> Is this a bug or my error ?
>
> Cheers
> Jono
>
> P.S I've noticed this could be related to the thread "Possible lift-
> json bug in
> Xml.toJson"http://groups.google.com/group/liftweb/browse_thread/thread/47c581d63...
>
> /* Test */
>
> import scala.xml.Node
>
> def xml2Json(xml:Node):String = {
> val json = toJson(xml)
> compact(render(json))
> }
>
> "XML to JSON Example with multiple attributes, multiple nested
> elements " in { xml2Json(xml1) mustEqual expected1 }
> "XML to JSON Example with multiple attributes, multiple nested
> elements " in { xml2Json(xml2) mustEqual expected2 }
> "XML to JSON Example with one attribute, multiple nested elements
> " in { xml2Json(xml3) mustEqual expected3 }
> "XML to JSON Example with one attribute, one nested element " in
> { xml2Json(xml4) mustEqual expected4 }
>
> val xml1 = word="ant" self="me">
> val expected1 = """{"message":{"expiry_date":
> 20091126,"text":"text","word":"ant","self":"me","stats":{"count":
> 0},"messages":{"href":"https://domain.com/message/ant"}}}""";
> val actual1 = """{"message":
> {"expiry_date":"20091126","word":"ant","text":"text","self":"me","stats":null,"count":"0","messages":null,"href":"https://
> domain.com/message/ant"}}"""
>
> val xml2 = word="ant" self="me">
> val expected2 = """{"message":{"expiry_date":
> 20091126,"text":"text","word":"ant","self":"me","stats":{"count":
> 0},"messages":{"href":"https://domain.com/message/ant"}}}""";
> val actual2 = """{"message":
> {"expiry_date":"20091126","word":"ant","text":"text","self":"me","stats":null,"count":"0","messages":null,"href":"https://
> domain.com/message/ant"}}"""
>
> val xml3 = stats>https://domain.com/message/ant";> message>
> val expected3 = """{"message":{"expiry_date":20091126,"stats":
> {"count":0},"messages":{"href":"https://domain.com/message/ant"}}}""";
> val actual3 = """{"message":
> {"expiry_date":"20091126","stats":null,"count":"0","messages":null,"href":"https://
> domain.com/message/ant"}}"""
>
> val xml4 = stats>
> val expected4 = """{"message":{"expiry_date":20091126,"stats":
> {"count":0}}}"""
> val actual4 = """{"message":""}"""
--~--~-~--~~~---~--~~
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
liftwe
[Lift] Possible bug in xml to json conversion
Depending on the structure of the XML, attributes and child elements
are being lost. This can be seen in example 4, where the attribute
expiry_date and the child element status have been dropped.
It would also appear when XML is being converted to JSON attributes
are being flattened to elements. I'm not sure if this is expected or
not, this can be seen in examples 1,2 & 3. The child
element status with attribute count is converted to two attributes
status with a value of null and count with the correct value.
To test I added the following before the closing brace of
XmlExamplesTest.scala in lift-json.
Is this a bug or my error ?
Cheers
Jono
P.S I've noticed this could be related to the thread "Possible lift-
json bug in Xml.toJson"
http://groups.google.com/group/liftweb/browse_thread/thread/47c581d63ddc04c5/86a11ffcf3040aaa?lnk=gst&q=Json+#86a11ffcf3040aaa
/* Test */
import scala.xml.Node
def xml2Json(xml:Node):String = {
val json = toJson(xml)
compact(render(json))
}
"XML to JSON Example with multiple attributes, multiple nested
elements " in { xml2Json(xml1) mustEqual expected1 }
"XML to JSON Example with multiple attributes, multiple nested
elements " in { xml2Json(xml2) mustEqual expected2 }
"XML to JSON Example with one attribute, multiple nested elements
" in { xml2Json(xml3) mustEqual expected3 }
"XML to JSON Example with one attribute, one nested element " in
{ xml2Json(xml4) mustEqual expected4 }
val xml1 =
val expected1 = """{"message":{"expiry_date":
20091126,"text":"text","word":"ant","self":"me","stats":{"count":
0},"messages":{"href":"https://domain.com/message/ant"}}}""";
val actual1 = """{"message":
{"expiry_date":"20091126","word":"ant","text":"text","self":"me","stats":null,"count":"0","messages":null,"href":"https://
domain.com/message/ant"}}"""
val xml2 =
val expected2 = """{"message":{"expiry_date":
20091126,"text":"text","word":"ant","self":"me","stats":{"count":
0},"messages":{"href":"https://domain.com/message/ant"}}}""";
val actual2 = """{"message":
{"expiry_date":"20091126","word":"ant","text":"text","self":"me","stats":null,"count":"0","messages":null,"href":"https://
domain.com/message/ant"}}"""
val xml3 = https://domain.com/message/ant";>
val expected3 = """{"message":{"expiry_date":20091126,"stats":
{"count":0},"messages":{"href":"https://domain.com/message/ant"}}}""";
val actual3 = """{"message":
{"expiry_date":"20091126","stats":null,"count":"0","messages":null,"href":"https://
domain.com/message/ant"}}"""
val xml4 =
val expected4 = """{"message":{"expiry_date":20091126,"stats":
{"count":0}}}"""
val actual4 = """{"message":""}"""
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
