[Lift] Re: Lift compiles with 2.7.3.RC2

[Marius]

Awesome !

On Jan 10, 9:01 am, "Jorge Ortiz"  wrote:
> I've made two Git branches which compile Lift against Scala 2.7.3-SNAPSHOT
> and 2.7.3.RC2.
>
> As soon as Scala 2.7.3 goes final we'll release Lift 1.0.RC1.
>
> --j
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Lift compiles with 2.7.3.RC2

[Jorge Ortiz]

I've made two Git branches which compile Lift against Scala 2.7.3-SNAPSHOT
and 2.7.3.RC2.

As soon as Scala 2.7.3 goes final we'll release Lift 1.0.RC1.

--j

--~--~-~--~~~---~--~~
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: AppTest.scala in lift-archetype-basic

[Jorge Ortiz]

Good catch, I've committed your patch.

Thanks Marc!

--j

On Fri, Jan 9, 2009 at 2:55 PM, Marc Boschma

> wrote:

> I've just noticed that the test in AppTest.scala for XML and XHTML etc
> doesn't take into account Html entities...
>
> >
>
>
>
>
> So I suggest the following change (as a diff -c) and attached the full
> file...
>
> --
> *** AppTest.scala.orig  2009-01-10 09:19:45.0 +1100
> --- AppTest.scala   2009-01-10 09:49:47.0 +1100
> ***
> *** 4,9 
> --- 4,10 
>   import _root_.junit.framework._
>   import Assert._
>   import _root_.scala.xml.XML
> + import _root_.net.liftweb.util._
>
>   object AppTest {
> def suite: Test = {
> ***
> *** 36,56 
> def testXml() = {
>   var failed: List[File] = Nil
>
> ! def handled(file: String) =
> !   file.endsWith(".html") || file.endsWith(".xml") ||
> !   file.endsWith(".htm")  || file.endsWith(".xhtml")
>
>   def wellFormed(file: File) {
> if (file.isDirectory)
>   for (f <- file.listFiles) wellFormed(f)
>
> !   if (file.isFile && handled(file.getName)) {
>   try {
> XML.loadFile(file)
>   } catch {
> case e: _root_.org.xml.sax.SAXParseException => failed =
> file :: failed
>   }
> }
>   }
>
>   wellFormed(new File("src/main/webapp"))
> --- 37,65 
> def testXml() = {
>   var failed: List[File] = Nil
>
> ! def handledXml(file: String) =
> !   file.endsWith(".xml")
> !
> ! def handledXHtml(file: String) =
> !   file.endsWith(".html") || file.endsWith(".htm") ||
> file.endsWith(".xhtml")
>
>   def wellFormed(file: File) {
> if (file.isDirectory)
>   for (f <- file.listFiles) wellFormed(f)
>
> !   if (file.isFile && handledXml(file.getName)) {
>   try {
> XML.loadFile(file)
>   } catch {
> case e: _root_.org.xml.sax.SAXParseException => failed =
> file :: failed
>   }
> }
> +   if (file.isFile && handledXHtml(file.getName)) {
> +   PCDataXmlParser(new java.io.FileInputStream(file.getAbsolutePath))
> match {
> + case Full(_) => // file is ok
> + case _ => failed = file :: failed
> +   }
> +   }
>   }
>
>   wellFormed(new File("src/main/webapp"))
>
>
>

--~--~-~--~~~---~--~~
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: Swampland

[Kris Nuttycombe]

The GPL doesn't come into effect unless you distribute software based upon
the GPL'ed code. The AGPL extends the definition of "distribution" to using
the software to provide a service on the web.

Kris

On Fri, Jan 9, 2009 at 8:45 PM, Josh Suereth wrote:

> If you keep a good plugin system, that is very helpful!  I'm excited to see
> what this looks like.
>
> Here's my list of "bug tracking neatos"
>
> * Easy Query/filter with dynamic fields on bugs  ->  Some bug tracking
> tools really don't do this well(Gforge...)
> * Easy creation of "Change list" or "new features" for a  release.
> * Custom dashboard when logging in that lets me see pertinent information
> for my development on a project.  -> I tend to use Eclipse Mylyn to make up
> for lacking bug tracking websites
> * Easy/Fast to enter/edit bugs -> We used GForge for a few projects I had,
> and the bug tracking was ok, except it took FOREVER to create/edit/delete
> bugs.  Part of this was that you couldn't multi-select/multi-edit.
>
>
> If you need beta testers (when the time is ready), I'm willing to use it to
> track bugs for a few of my open source projects (once I find a host).
>
> Also, I've recently heard of the GNU Affero license.   I head it's "GPL for
> the web". What's the main difference between this and vanilla GPL?
>
>
> - Josh
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Swampland

[Kris Nuttycombe]

My bug tracking wishlist:

1) Pluggable integration with source control systems so that fixed bugs can
easily be associated with the relevant patch sets in the vcs.. The rise of
distributed version control systems like Git has had me thinking about the
possibility of providing a patch as a link or list of changesets to pull
from instead of a text file that may or may not apply cleanly to the current
version of the trunk. Being able to rebase someone else's patchset against
the current trunk could be incredibly useful.

2) Mailing list integration. It's not uncommon for bug trackers to post new
bugs to relevant addresses or mailing lists, but I've never seen one where
the bug tracker itself can filter out and record the resulting thread from
the list; often the on-list discussion is pretty valuable to the resolution.

3) Most bug trackers that I've seen have utterly crap ways of prioritizing
bugs (a scale from 1-5 is useless) or relating bugs/feature requests to one
another. Often when I'm working on a project, I'll organize my non-critical
bugfixes so that they are handled when I  touch the relevant sections of
code for other purposes; if I'm planning to add a feature somewhere in my
app, it's not uncommon that in the process of refactoring that section
existing bugs get taken care of as part of the process. In terms of
prioritization, I'd love a system that gives my manager/users a clear idea
of when a particular bug will be fixed, and perhaps why it's behind a bunch
of other, more pressing issues. People love it when they can see their
issues trickling towards the head of the queue.

Kris



On Fri, Jan 9, 2009 at 5:38 PM, David Pollak
wrote:

> Folks,
>
> I'm please to announce my latest open source project: Swampland.
> http://github.com/dpp/swampland/tree/master
>
> Swampland is a bug/issue tracking system built on Lift.  It's licensed
> under the GNU Affero General Public License (there will be a classpath
> exception so Swampland can be run in non-free web containers).
>
> I'm going to be working on Swampland over the next bunch of weeks and it
> will form the basis for the Lift project's bug tracking system.  It will
> also likely be the project the I use in the Lift book.
>
> Early in the process, I'd love to hear from folks about the good and bad of
> various bug tracking system they use so I can use the good and avoid
> pitfalls.
>
> My key goal for Swampland is to build something that's got a very usable
> UI, but also has a RESTful interface that's a first-class part of the
> system.  It will support plugins.
>
> I'm licensing it under a GPL license because I want to make sure that
> anyone who uses it and updates it contributes code back to the project.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Swampland

[Josh Suereth]

If you keep a good plugin system, that is very helpful!  I'm excited to see
what this looks like.

Here's my list of "bug tracking neatos"

* Easy Query/filter with dynamic fields on bugs  ->  Some bug tracking tools
really don't do this well(Gforge...)
* Easy creation of "Change list" or "new features" for a  release.
* Custom dashboard when logging in that lets me see pertinent information
for my development on a project.  -> I tend to use Eclipse Mylyn to make up
for lacking bug tracking websites
* Easy/Fast to enter/edit bugs -> We used GForge for a few projects I had,
and the bug tracking was ok, except it took FOREVER to create/edit/delete
bugs.  Part of this was that you couldn't multi-select/multi-edit.


If you need beta testers (when the time is ready), I'm willing to use it to
track bugs for a few of my open source projects (once I find a host).

Also, I've recently heard of the GNU Affero license.   I head it's "GPL for
the web". What's the main difference between this and vanilla GPL?


- Josh

--~--~-~--~~~---~--~~
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: JPA/Lift many-to-many driving me insane

[Charles F. Munat]

Good idea. I still think that there ought to be an easier way -- after 
all, I do this all the time on sites -- but at this point I'll take 
whatever works.

Thanks!

Chas.

Derek Chen-Becker wrote:
> Not much time to properly respond, but make sure to override equals and 
> hashcode on the objects so that to /value-identical/ instances are 
> treated as the same instance. Usually with JPA you're not looking for 
> object equivalence but value equivalence.
> 
> Derek
> 
> On Fri, Jan 9, 2009 at 5:18 PM, Charles F. Munat  > wrote:
> 
> 
> I'm trying to create a way for users to add multiple "worm" objects to
> an "apple" object in a many-to-many relationship, so I could access them
> as apple.worms (which returns a Java set, it seems).
> 
> The first hassle was trying to find the best interface. I rejected a
> multi-select box because people have a hell of a time with it,
> especially on an edit where if you forget to hold the Control (Command)
> key down while selecting, you could delete the previously selected
> objects.
> 
> I also rejected a two-box solution where you use left and right arrows
> to move from the pool of objects to the attached objects (or back
> again). This also is difficult for some people and a pain to implement.
> 
> Instead, I like the idea of a simple single item select menu and an Add
> button using AJAX to add the worm to the apple. To make this simpler, by
> form is multi-page. You create an apple first, then on the next page you
> can add worms (and other m-m things). So the AJAX always has a
> persistent apple to which to add the worms.
> 
> Better ideas welcome, but this is sufficient.
> 
> The worms then have a Remove button next to them which permits the
> association between them and the apple to be deleted.
> 
> (I also plan a pop-up form that allows one to add new worms from within
> the apple form.)
> 
> So now I want to populate the drop down menu with the names of those
> worms *not already associated with the apple*. My first attempt was by
> pulling down a set of all the worms (there won't be many) and stuffing
> it in a val. Then I made a list of all the worms associated with the
> apple. Then -- heh, heh -- I cleverly subtracted the latter from the
> former to get the unused worms.
> 
> Except that it didn't work, of course. They may be the same worms, but
> the system sees them as two different objects for some reason. Now it's
> getting complicated. Do I have to compare them on the ID?
> 
> There must be a better way.
> 
> So, has anyone done anything like this using JPA/Hibernate and Lift, or
> am I on my own?
> 
> Thanks!
> 
> Chas.
> 
> P.S. As usual, I need this like yesterday, so I'll continue working
> on it...
> 
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
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: Swampland

[Warren Henning]

On Fri, Jan 9, 2009 at 4:38 PM, David Pollak
 wrote:
> It's licensed under
> the GNU Affero General Public License
> I'm licensing it under a GPL license because I want to make sure that anyone
> who uses it and updates it contributes code back to the project.

Wow, I'm surprised to see a grizzled old veteran use a license so, er,
aggressively copyleft.

I don't like issue trackers and software project management systems
that try to do too much and which care way too much about quantitative
"metrics" that are at best useless and at worst extremely misleading.
Simple software gets used, complex software makes people think "gee,
think of all those things I *could* do I'm not doing *now*" and then
they never do those things.

Warren

--~--~-~--~~~---~--~~
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: Swampland

[Derek Chen-Becker]

David, this is awesome. I'll put together a list of my hates/loves with bug
systems I've used.

Derek

On Fri, Jan 9, 2009 at 5:38 PM, David Pollak
wrote:

> Folks,
>
> I'm please to announce my latest open source project: Swampland.
> http://github.com/dpp/swampland/tree/master
>
> Swampland is a bug/issue tracking system built on Lift.  It's licensed
> under the GNU Affero General Public License (there will be a classpath
> exception so Swampland can be run in non-free web containers).
>
> I'm going to be working on Swampland over the next bunch of weeks and it
> will form the basis for the Lift project's bug tracking system.  It will
> also likely be the project the I use in the Lift book.
>
> Early in the process, I'd love to hear from folks about the good and bad of
> various bug tracking system they use so I can use the good and avoid
> pitfalls.
>
> My key goal for Swampland is to build something that's got a very usable
> UI, but also has a RESTful interface that's a first-class part of the
> system.  It will support plugins.
>
> I'm licensing it under a GPL license because I want to make sure that
> anyone who uses it and updates it contributes code back to the project.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: JPA/Lift many-to-many driving me insane

[Derek Chen-Becker]

Not much time to properly respond, but make sure to override equals and
hashcode on the objects so that to *value-identical* instances are treated
as the same instance. Usually with JPA you're not looking for object
equivalence but value equivalence.

Derek

On Fri, Jan 9, 2009 at 5:18 PM, Charles F. Munat  wrote:

>
> I'm trying to create a way for users to add multiple "worm" objects to
> an "apple" object in a many-to-many relationship, so I could access them
> as apple.worms (which returns a Java set, it seems).
>
> The first hassle was trying to find the best interface. I rejected a
> multi-select box because people have a hell of a time with it,
> especially on an edit where if you forget to hold the Control (Command)
> key down while selecting, you could delete the previously selected objects.
>
> I also rejected a two-box solution where you use left and right arrows
> to move from the pool of objects to the attached objects (or back
> again). This also is difficult for some people and a pain to implement.
>
> Instead, I like the idea of a simple single item select menu and an Add
> button using AJAX to add the worm to the apple. To make this simpler, by
> form is multi-page. You create an apple first, then on the next page you
> can add worms (and other m-m things). So the AJAX always has a
> persistent apple to which to add the worms.
>
> Better ideas welcome, but this is sufficient.
>
> The worms then have a Remove button next to them which permits the
> association between them and the apple to be deleted.
>
> (I also plan a pop-up form that allows one to add new worms from within
> the apple form.)
>
> So now I want to populate the drop down menu with the names of those
> worms *not already associated with the apple*. My first attempt was by
> pulling down a set of all the worms (there won't be many) and stuffing
> it in a val. Then I made a list of all the worms associated with the
> apple. Then -- heh, heh -- I cleverly subtracted the latter from the
> former to get the unused worms.
>
> Except that it didn't work, of course. They may be the same worms, but
> the system sees them as two different objects for some reason. Now it's
> getting complicated. Do I have to compare them on the ID?
>
> There must be a better way.
>
> So, has anyone done anything like this using JPA/Hibernate and Lift, or
> am I on my own?
>
> Thanks!
>
> Chas.
>
> P.S. As usual, I need this like yesterday, so I'll continue working on
> it...
>
> >
>

--~--~-~--~~~---~--~~
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] Swampland

[David Pollak]

Folks,

I'm please to announce my latest open source project: Swampland.
http://github.com/dpp/swampland/tree/master

Swampland is a bug/issue tracking system built on Lift.  It's licensed under
the GNU Affero General Public License (there will be a classpath exception
so Swampland can be run in non-free web containers).

I'm going to be working on Swampland over the next bunch of weeks and it
will form the basis for the Lift project's bug tracking system.  It will
also likely be the project the I use in the Lift book.

Early in the process, I'd love to hear from folks about the good and bad of
various bug tracking system they use so I can use the good and avoid
pitfalls.

My key goal for Swampland is to build something that's got a very usable UI,
but also has a RESTful interface that's a first-class part of the system.
It will support plugins.

I'm licensing it under a GPL license because I want to make sure that anyone
who uses it and updates it contributes code back to the project.

Thanks,

David

-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Lift O-R Mappings

[Charles F. Munat]

That sounds kinda smart. Is there any chance you could post some example 
code?

Chas.

Kris Nuttycombe wrote:
> Oh, I'm not complaining about the way User is handled - my response was 
> more about the general hate towards MVC upthread. Having a sensible 
> default for a standard use case is great, even when I'll probably never 
> use the default.
> 
> In my Lift app, my shortcut to different renderings (well, different 
> bindings, really) is to keep all the binding logic for a specific case 
> in a trait and have an implicit conversion from my model to the 
> appropriate trait in the relevant scope. You still have to do the work, 
> but it makes the bindings a lot easier to reuse.
> 
> Kris
> 
> On Fri, Jan 9, 2009 at 4:46 PM, Charles F. Munat  > wrote:
> 
> 
> I don't see how you're any worse off if the model can render itself in
> one way. And if that way is a common standards-compliant way, such as
> rendering to XML, and you include semantic information, then you can
> layer any other layers you want on top to do the mapping to the 30
> different contexts.
> 
> Saying that an object should know how to render itself to some
> universally recognized format is not the same as saying that that solves
> all rendering issues.
> 
> Is there some shortcut to 30 different renderings that I'm missing, or
> do you have to do the work either way?
> 
> Chas.
> 
> Kris Nuttycombe wrote:
>  > If you want to render a model 30 different ways in 30 different
>  > contexts, it kind of sucks though, doesn't it?
>  >
>  > Or what if, shock horror, you don't know how the eventual system is
>  > going to want to render the model (i.e., the person doing the
> rendering
>  > won't be able to change the model code.) Not too uncommon, I
> don't think...
>  >
>  > Kris
>  >
>  > On Sun, Jan 4, 2009 at 9:58 AM, Michael http://mike.sr>
>  > @gmail.com  >
> wrote:
>  >
>  >
>  >  > Also I was looking at the sample model source code (User,
> ProtoUser)
>  >  > and saw presentation logic mixed in it. Shouldn't the
> business and
>  >  > model logic be kept separated from the presentation logic
> or is there
>  >  > a Lift strategy it?
>  >
>  > Hmm, a model that can render itself ... That sounds like this
> crazy
>  > paradigm called object-oriented programming. Some radicals
> say it has
>  > some advantages over the more procedural style of MVC.
>  >
>  > -- Michael
>  >
>  >
>  >
>  >
>  > >
> 
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

On Fri, Jan 9, 2009 at 2:12 PM, Marc Boschma

> wrote:

>
> Ok, cool to see the attr.apply code aligned with the trait.
>
> One simple question - is it safe to assume the Info/NodeSeq will never
> be null?


Yes.


>
>
> Marc
>
> On 10/01/2009, at 2:53 AM, Marius wrote:
>
> >
> > Ok I don't think it is a compiler bug.
> >
> >
> > Marc called it like:
> >
> > var singular = BindHelpers.attr("singular", {s: String =>
> > {s.toLowerCase ...}, false}
> >
> > BUT
> >
> > the apply function is defined as
> >
> > def apply[T](key: String, f: Info => T, default: => T): T
> >
> > Note that function f takes an Info not a T as parameter and for attr
> > object Info = NodeSeq and not String.
> >
> > => compiler errors.
> >
> > So Marc your conversion function is provided here with a NodeSeq and
> > not a String so you can say:
> >
> > var singular = BindHelpers.attr[Boolean]("singular", {s: NodeSeq=>
> > {...}, false}
> >
> >
> >
> > Br's,
> > Marius
> >
> > On Jan 9, 2:59 pm, Marius  wrote:
> >> I hate git on windows ... I use it for the book unfortunatelly.
> >>
> >> On Jan 9, 1:46 pm, "David Pollak" 
> >> wrote:
> >>
> >>
> >>
> >>> On Fri, Jan 9, 2009 at 2:59 AM, Marius 
> >>> wrote:
> >>
>  That's weird. I see that someone modified the code that I committed
>  moving most of the logic in the trait itself. I'm not sure if David
>  did that cause in git I see "unknown" author.
> >>
> >>> Yep... it was me... from my Windows machine which has a less
> >>> than awesome support for Git.
> >>
>  I do  like those changes
>  but I need to look later on today when I get home if they have
>  something to do with your problem. Since apply functions are
>  implemented in the trait itself it it seems that compiler does
>  not see
>  that Info abstract type is in fact a String in the attr object
>  context. I wonder if it's a compiler bug :D
> >>
> >>> Hmmm... that'd suck.
> >>
> >> Oh yeah big time ... If indeed my assumption is correct (which I need
> >> to verify) I'll open a compiler bug and see if I can fix it. Worst
> >> case scenario rollback ... which I hope it won't be the case.
> >>
> >>
> >>
>  In my tests I used similar examples as you did and worked with no
>  problems. But I did not test with latest changed.
> >>
>  Br's,
>  Marius
> >>
>  On Jan 9, 10:35 am, Marc Boschma 
>  
>   %2blift...@boschma.cx>>
>  wrote:
> > Me either (rather embarrassing, had an old copy of
> > BindHelpers.scala
> > lying about :/ )
> >>
> > However, a rather strange outcome...
> >>
> > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/
> > liftworkshop/
> > snippet/TD.scala:99: error: overloaded method value apply with
> > alternatives [T](String,String,
> > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> > (String,
> > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> > (String,String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > T)Option[T]
> >  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > T)Option[T]  (String,String,=>
> > net
> > .liftweb
> > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> >  (String,=>
> > net
> > .liftweb
> > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> > 
> > (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]
> >  (String)Option[net.liftweb.util.BindHelpers.attr.Info]
> > cannot be
> > applied to (java.lang.String,(String) => Boolean,() => Boolean)
> > [WARNING]   val singular: Boolean =
>  BindHelpers.attr("singular", {s:
> > String => s.toLowerCase match {
> >>
> > What I find weird is that the references to
> > net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
> >>
> > The offending line of code:
> >  val singular: Boolean =
> > BindHelpers.attr("singular",
> > {s: String => s.toLowerCase match {
> >  case "" => true
> >  case "true" => true
> >  case "t" => true
> >  case "yes" => true
> >  case "y" => true
> >  case _ => false}}, () => false)
> >>
> > I have also tried
> >>
> >  val singular: Boolean =
> > BindHelpers.attr("singular",
> > {s: String => s.toLowerCase match {
> >  case "" => true
> >  case "true" => true
> >  case "t" => true
> >  case "yes" => true
> >  case "y" => true
> >  case _ => false}}, false)
> >>
> > which gets
> >>
> > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/
> > liftworkshop/
> > snippet/TD.scala:99: error: type mismatch;
> > [WARNING]  found   : (Stri

[Lift] JPA/Lift many-to-many driving me insane

[Charles F. Munat]

I'm trying to create a way for users to add multiple "worm" objects to 
an "apple" object in a many-to-many relationship, so I could access them 
as apple.worms (which returns a Java set, it seems).

The first hassle was trying to find the best interface. I rejected a 
multi-select box because people have a hell of a time with it, 
especially on an edit where if you forget to hold the Control (Command) 
key down while selecting, you could delete the previously selected objects.

I also rejected a two-box solution where you use left and right arrows 
to move from the pool of objects to the attached objects (or back 
again). This also is difficult for some people and a pain to implement.

Instead, I like the idea of a simple single item select menu and an Add 
button using AJAX to add the worm to the apple. To make this simpler, by 
form is multi-page. You create an apple first, then on the next page you 
can add worms (and other m-m things). So the AJAX always has a 
persistent apple to which to add the worms.

Better ideas welcome, but this is sufficient.

The worms then have a Remove button next to them which permits the 
association between them and the apple to be deleted.

(I also plan a pop-up form that allows one to add new worms from within 
the apple form.)

So now I want to populate the drop down menu with the names of those 
worms *not already associated with the apple*. My first attempt was by 
pulling down a set of all the worms (there won't be many) and stuffing 
it in a val. Then I made a list of all the worms associated with the 
apple. Then -- heh, heh -- I cleverly subtracted the latter from the 
former to get the unused worms.

Except that it didn't work, of course. They may be the same worms, but 
the system sees them as two different objects for some reason. Now it's 
getting complicated. Do I have to compare them on the ID?

There must be a better way.

So, has anyone done anything like this using JPA/Hibernate and Lift, or 
am I on my own?

Thanks!

Chas.

P.S. As usual, I need this like yesterday, so I'll continue working on it...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Lift O-R Mappings

[Kris Nuttycombe]

Oh, I'm not complaining about the way User is handled - my response was more
about the general hate towards MVC upthread. Having a sensible default for a
standard use case is great, even when I'll probably never use the default.

In my Lift app, my shortcut to different renderings (well, different
bindings, really) is to keep all the binding logic for a specific case in a
trait and have an implicit conversion from my model to the appropriate trait
in the relevant scope. You still have to do the work, but it makes the
bindings a lot easier to reuse.

Kris

On Fri, Jan 9, 2009 at 4:46 PM, Charles F. Munat  wrote:

>
> I don't see how you're any worse off if the model can render itself in
> one way. And if that way is a common standards-compliant way, such as
> rendering to XML, and you include semantic information, then you can
> layer any other layers you want on top to do the mapping to the 30
> different contexts.
>
> Saying that an object should know how to render itself to some
> universally recognized format is not the same as saying that that solves
> all rendering issues.
>
> Is there some shortcut to 30 different renderings that I'm missing, or
> do you have to do the work either way?
>
> Chas.
>
> Kris Nuttycombe wrote:
> > If you want to render a model 30 different ways in 30 different
> > contexts, it kind of sucks though, doesn't it?
> >
> > Or what if, shock horror, you don't know how the eventual system is
> > going to want to render the model (i.e., the person doing the rendering
> > won't be able to change the model code.) Not too uncommon, I don't
> think...
> >
> > Kris
> >
> > On Sun, Jan 4, 2009 at 9:58 AM, Michael  > @gmail.com > wrote:
> >
> >
> >  > Also I was looking at the sample model source code (User,
> ProtoUser)
> >  > and saw presentation logic mixed in it. Shouldn't the business and
> >  > model logic be kept separated from the presentation logic or is
> there
> >  > a Lift strategy it?
> >
> > Hmm, a model that can render itself ... That sounds like this crazy
> > paradigm called object-oriented programming. Some radicals say it has
> > some advantages over the more procedural style of MVC.
> >
> > -- Michael
> >
> >
> >
> >
> > >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Lift O-R Mappings

[David Pollak]

When I've got a lot of potential subclasses that come from one row (e.g., an
event), I find that it's best to have a converter on the DB model that will
render the immutable thing (e.g., event).

Another alternative is to use the findMap method that will allow you to map
each row into a thing.

On Fri, Jan 9, 2009 at 3:46 PM, Charles F. Munat  wrote:

>
> I don't see how you're any worse off if the model can render itself in
> one way. And if that way is a common standards-compliant way, such as
> rendering to XML, and you include semantic information, then you can
> layer any other layers you want on top to do the mapping to the 30
> different contexts.
>
> Saying that an object should know how to render itself to some
> universally recognized format is not the same as saying that that solves
> all rendering issues.
>
> Is there some shortcut to 30 different renderings that I'm missing, or
> do you have to do the work either way?
>
> Chas.
>
> Kris Nuttycombe wrote:
> > If you want to render a model 30 different ways in 30 different
> > contexts, it kind of sucks though, doesn't it?
> >
> > Or what if, shock horror, you don't know how the eventual system is
> > going to want to render the model (i.e., the person doing the rendering
> > won't be able to change the model code.) Not too uncommon, I don't
> think...
> >
> > Kris
> >
> > On Sun, Jan 4, 2009 at 9:58 AM, Michael  > @gmail.com > wrote:
> >
> >
> >  > Also I was looking at the sample model source code (User,
> ProtoUser)
> >  > and saw presentation logic mixed in it. Shouldn't the business and
> >  > model logic be kept separated from the presentation logic or is
> there
> >  > a Lift strategy it?
> >
> > Hmm, a model that can render itself ... That sounds like this crazy
> > paradigm called object-oriented programming. Some radicals say it has
> > some advantages over the more procedural style of MVC.
> >
> > -- Michael
> >
> >
> >
> >
> > >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Lift O-R Mappings

[Charles F. Munat]

I don't see how you're any worse off if the model can render itself in 
one way. And if that way is a common standards-compliant way, such as 
rendering to XML, and you include semantic information, then you can 
layer any other layers you want on top to do the mapping to the 30 
different contexts.

Saying that an object should know how to render itself to some 
universally recognized format is not the same as saying that that solves 
all rendering issues.

Is there some shortcut to 30 different renderings that I'm missing, or 
do you have to do the work either way?

Chas.

Kris Nuttycombe wrote:
> If you want to render a model 30 different ways in 30 different 
> contexts, it kind of sucks though, doesn't it?
> 
> Or what if, shock horror, you don't know how the eventual system is 
> going to want to render the model (i.e., the person doing the rendering 
> won't be able to change the model code.) Not too uncommon, I don't think...
> 
> Kris
> 
> On Sun, Jan 4, 2009 at 9:58 AM, Michael  @gmail.com > wrote:
> 
> 
>  > Also I was looking at the sample model source code (User, ProtoUser)
>  > and saw presentation logic mixed in it. Shouldn't the business and
>  > model logic be kept separated from the presentation logic or is there
>  > a Lift strategy it?
> 
> Hmm, a model that can render itself ... That sounds like this crazy
> paradigm called object-oriented programming. Some radicals say it has
> some advantages over the more procedural style of MVC.
> 
> -- Michael
> 
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Lift O-R Mappings

[Kris Nuttycombe]

If you want to render a model 30 different ways in 30 different contexts, it
kind of sucks though, doesn't it?

Or what if, shock horror, you don't know how the eventual system is going to
want to render the model (i.e., the person doing the rendering won't be able
to change the model code.) Not too uncommon, I don't think...

Kris

On Sun, Jan 4, 2009 at 9:58 AM, Michael  wrote:

>
> > Also I was looking at the sample model source code (User, ProtoUser)
> > and saw presentation logic mixed in it. Shouldn't the business and
> > model logic be kept separated from the presentation logic or is there
> > a Lift strategy it?
>
> Hmm, a model that can render itself ... That sounds like this crazy
> paradigm called object-oriented programming. Some radicals say it has
> some advantages over the more procedural style of MVC.
>
> -- Michael
>
> >
>

--~--~-~--~~~---~--~~
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] AppTest.scala in lift-archetype-basic

[Marc Boschma]

I've just noticed that the test in AppTest.scala for XML and XHTML etc  
doesn't take into account Html entities...

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



AppTest.scala
Description: Binary data



So I suggest the following change (as a diff -c) and attached the full  
file...

--
*** AppTest.scala.orig  2009-01-10 09:19:45.0 +1100
--- AppTest.scala   2009-01-10 09:49:47.0 +1100
***
*** 4,9 
--- 4,10 
   import _root_.junit.framework._
   import Assert._
   import _root_.scala.xml.XML
+ import _root_.net.liftweb.util._

   object AppTest {
 def suite: Test = {
***
*** 36,56 
 def testXml() = {
   var failed: List[File] = Nil

! def handled(file: String) =
!   file.endsWith(".html") || file.endsWith(".xml") ||
!   file.endsWith(".htm")  || file.endsWith(".xhtml")

   def wellFormed(file: File) {
 if (file.isDirectory)
   for (f <- file.listFiles) wellFormed(f)

!   if (file.isFile && handled(file.getName)) {
   try {
 XML.loadFile(file)
   } catch {
 case e: _root_.org.xml.sax.SAXParseException => failed =  
file :: failed
   }
 }
   }

   wellFormed(new File("src/main/webapp"))
--- 37,65 
 def testXml() = {
   var failed: List[File] = Nil

! def handledXml(file: String) =
!   file.endsWith(".xml")
!
! def handledXHtml(file: String) =
!   file.endsWith(".html") || file.endsWith(".htm") ||  
file.endsWith(".xhtml")

   def wellFormed(file: File) {
 if (file.isDirectory)
   for (f <- file.listFiles) wellFormed(f)

!   if (file.isFile && handledXml(file.getName)) {
   try {
 XML.loadFile(file)
   } catch {
 case e: _root_.org.xml.sax.SAXParseException => failed =  
file :: failed
   }
 }
+   if (file.isFile && handledXHtml(file.getName)) {
+   PCDataXmlParser(new java.io.FileInputStream(file.getAbsolutePath))  
match {
+ case Full(_) => // file is ok
+ case _ => failed = file :: failed
+   }
+   }
   }

   wellFormed(new File("src/main/webapp"))

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

Ok, cool to see the attr.apply code aligned with the trait.

One simple question - is it safe to assume the Info/NodeSeq will never  
be null?

Marc

On 10/01/2009, at 2:53 AM, Marius wrote:

>
> Ok I don't think it is a compiler bug.
>
>
> Marc called it like:
>
> var singular = BindHelpers.attr("singular", {s: String =>
> {s.toLowerCase ...}, false}
>
> BUT
>
> the apply function is defined as
>
> def apply[T](key: String, f: Info => T, default: => T): T
>
> Note that function f takes an Info not a T as parameter and for attr
> object Info = NodeSeq and not String.
>
> => compiler errors.
>
> So Marc your conversion function is provided here with a NodeSeq and
> not a String so you can say:
>
> var singular = BindHelpers.attr[Boolean]("singular", {s: NodeSeq=>
> {...}, false}
>
>
>
> Br's,
> Marius
>
> On Jan 9, 2:59 pm, Marius  wrote:
>> I hate git on windows ... I use it for the book unfortunatelly.
>>
>> On Jan 9, 1:46 pm, "David Pollak" 
>> wrote:
>>
>>
>>
>>> On Fri, Jan 9, 2009 at 2:59 AM, Marius   
>>> wrote:
>>
 That's weird. I see that someone modified the code that I committed
 moving most of the logic in the trait itself. I'm not sure if David
 did that cause in git I see "unknown" author.
>>
>>> Yep... it was me... from my Windows machine which has a less
>>> than awesome support for Git.
>>
 I do  like those changes
 but I need to look later on today when I get home if they have
 something to do with your problem. Since apply functions are
 implemented in the trait itself it it seems that compiler does  
 not see
 that Info abstract type is in fact a String in the attr object
 context. I wonder if it's a compiler bug :D
>>
>>> Hmmm... that'd suck.
>>
>> Oh yeah big time ... If indeed my assumption is correct (which I need
>> to verify) I'll open a compiler bug and see if I can fix it. Worst
>> case scenario rollback ... which I hope it won't be the case.
>>
>>
>>
 In my tests I used similar examples as you did and worked with no
 problems. But I did not test with latest changed.
>>
 Br's,
 Marius
>>
 On Jan 9, 10:35 am, Marc Boschma >>> %2blift...@boschma.cx>>
 wrote:
> Me either (rather embarrassing, had an old copy of  
> BindHelpers.scala
> lying about :/ )
>>
> However, a rather strange outcome...
>>
> [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/ 
> liftworkshop/
> snippet/TD.scala:99: error: overloaded method value apply with
> alternatives [T](String,String,
> (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T] 
> (String,
> (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> (String,String,(net.liftweb.util.BindHelpers.attr.Info) =>  
> T)Option[T]
>  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>
> T)Option[T]  (String,String,=>
> net
> .liftweb
> .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
>  (String,=>
> net
> .liftweb
> .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
>   
> (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]
>  (String)Option[net.liftweb.util.BindHelpers.attr.Info]  
> cannot be
> applied to (java.lang.String,(String) => Boolean,() => Boolean)
> [WARNING]   val singular: Boolean =
 BindHelpers.attr("singular", {s:
> String => s.toLowerCase match {
>>
> What I find weird is that the references to
> net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
>>
> The offending line of code:
>  val singular: Boolean =  
> BindHelpers.attr("singular",
> {s: String => s.toLowerCase match {
>  case "" => true
>  case "true" => true
>  case "t" => true
>  case "yes" => true
>  case "y" => true
>  case _ => false}}, () => false)
>>
> I have also tried
>>
>  val singular: Boolean =  
> BindHelpers.attr("singular",
> {s: String => s.toLowerCase match {
>  case "" => true
>  case "true" => true
>  case "t" => true
>  case "yes" => true
>  case "y" => true
>  case _ => false}}, false)
>>
> which gets
>>
> [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/ 
> liftworkshop/
> snippet/TD.scala:99: error: type mismatch;
> [WARNING]  found   : (String) => Boolean
> [WARNING]  required: (net.liftweb.util.BindHelpers.attr.Info) =>  
> Boolean
> [WARNING]   val singular: Boolean =
 BindHelpers.attr("singular", {s:
> String => s.toLowerCase match {
>>
> Once again the references to  
> (net.liftweb.util.BindHelpers.attr.Info)
> => Boolean puzzle me...
>

[Lift] Re: What tags cannot be "open/close" in IE?

[Marius]

Purely from XML perspective ...

http://www.w3.org/TR/REC-xml/#NT-element section 3.1

Perhaps I'm missing something but  or  are both considered
empty elements. Of course  SHOULD be used if in DTD it is declared
as EMPTY.

Br's,
Marius

On Jan 9, 8:01 pm, "John Nilsson"  wrote:
> Ah here it is:http://www.wlmark.com/xhtml-html.php
>
> about half way down is a dicussion about , browsers, xml vs sgml and
> such matters.
>
> BR,
> John
>
> On Fri, Jan 9, 2009 at 6:50 PM, John Nilsson  wrote:
> > As it should. I don't think even the XML standard say that  is
> > equvalent to . I've had problems withd DTDs or Schemas that only
> > allowed one form for some definitions.
> > Now if you mean IE6 then XML isn't on the topic either way as it only
> > supports HTML. IIRC the HTML standard (before version 4) standardized 
> > to mean new line no matter what and  is of course a stand alone new line
> > even in HTML 4. Maybe  shouldn't be treated as a new line. I guess if
> > the browser is in tag soup mode it is the sane thing to do.
>
> > BR,
> > John
>
> > On Thu, Jan 8, 2009 at 8:27 PM, David Pollak <
> > feeder.of.the.be...@gmail.com> wrote:
>
> >> Folks,
>
> >> IE barfs on  (it treats them as 2 BR tags).  What other tags are
> >> in this category in IE?
>
> >> Thanks,
>
> >> David
>
> >> --
> >> Lift, the simply functional web frameworkhttp://liftweb.net
> >> Collaborative Task Managementhttp://much4.us
> >> Follow me:http://twitter.com/dpp
> >> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: What tags cannot be "open/close" in IE?

[John Nilsson]

Ah here it is:
http://www.wlmark.com/xhtml-html.php

about half way down is a dicussion about , browsers, xml vs sgml and
such matters.

BR,
John

On Fri, Jan 9, 2009 at 6:50 PM, John Nilsson  wrote:

> As it should. I don't think even the XML standard say that  is
> equvalent to . I've had problems withd DTDs or Schemas that only
> allowed one form for some definitions.
> Now if you mean IE6 then XML isn't on the topic either way as it only
> supports HTML. IIRC the HTML standard (before version 4) standardized 
> to mean new line no matter what and  is of course a stand alone new line
> even in HTML 4. Maybe  shouldn't be treated as a new line. I guess if
> the browser is in tag soup mode it is the sane thing to do.
>
> BR,
> John
>
> On Thu, Jan 8, 2009 at 8:27 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Folks,
>>
>> IE barfs on  (it treats them as 2 BR tags).  What other tags are
>> in this category in IE?
>>
>> Thanks,
>>
>> David
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: What tags cannot be "open/close" in IE?

[John Nilsson]

As it should. I don't think even the XML standard say that  is
equvalent to . I've had problems withd DTDs or Schemas that only
allowed one form for some definitions.
Now if you mean IE6 then XML isn't on the topic either way as it only
supports HTML. IIRC the HTML standard (before version 4) standardized 
to mean new line no matter what and  is of course a stand alone new line
even in HTML 4. Maybe  shouldn't be treated as a new line. I guess if
the browser is in tag soup mode it is the sane thing to do.

BR,
John

On Thu, Jan 8, 2009 at 8:27 PM, David Pollak
wrote:

> Folks,
>
> IE barfs on  (it treats them as 2 BR tags).  What other tags are
> in this category in IE?
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

Ok I don't think it is a compiler bug.


Marc called it like:

var singular = BindHelpers.attr("singular", {s: String =>
{s.toLowerCase ...}, false}

BUT

the apply function is defined as

def apply[T](key: String, f: Info => T, default: => T): T

Note that function f takes an Info not a T as parameter and for attr
object Info = NodeSeq and not String.

=> compiler errors.

So Marc your conversion function is provided here with a NodeSeq and
not a String so you can say:

var singular = BindHelpers.attr[Boolean]("singular", {s: NodeSeq=>
{...}, false}



Br's,
Marius

On Jan 9, 2:59 pm, Marius  wrote:
> I hate git on windows ... I use it for the book unfortunatelly.
>
> On Jan 9, 1:46 pm, "David Pollak" 
> wrote:
>
>
>
> > On Fri, Jan 9, 2009 at 2:59 AM, Marius  wrote:
>
> > > That's weird. I see that someone modified the code that I committed
> > > moving most of the logic in the trait itself. I'm not sure if David
> > > did that cause in git I see "unknown" author.
>
> > Yep... it was me... from my Windows machine which has a less
> > than awesome support for Git.
>
> > > I do  like those changes
> > > but I need to look later on today when I get home if they have
> > > something to do with your problem. Since apply functions are
> > > implemented in the trait itself it it seems that compiler does not see
> > > that Info abstract type is in fact a String in the attr object
> > > context. I wonder if it's a compiler bug :D
>
> > Hmmm... that'd suck.
>
> Oh yeah big time ... If indeed my assumption is correct (which I need
> to verify) I'll open a compiler bug and see if I can fix it. Worst
> case scenario rollback ... which I hope it won't be the case.
>
>
>
> > > In my tests I used similar examples as you did and worked with no
> > > problems. But I did not test with latest changed.
>
> > > Br's,
> > > Marius
>
> > > On Jan 9, 10:35 am, Marc Boschma 
> > > >
> > > wrote:
> > > > Me either (rather embarrassing, had an old copy of BindHelpers.scala
> > > > lying about :/ )
>
> > > > However, a rather strange outcome...
>
> > > > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > > > snippet/TD.scala:99: error: overloaded method value apply with
> > > > alternatives [T](String,String,
> > > > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T](String,
> > > > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> > > > (String,String,(net.liftweb.util.BindHelpers.attr.Info) => T)Option[T]
> > > >  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > > > T)Option[T]  (String,String,=>
> > > > net
> > > > .liftweb
> > > > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> > > >  (String,=>
> > > > net
> > > > .liftweb
> > > > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> > > >  (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]
> > > >  (String)Option[net.liftweb.util.BindHelpers.attr.Info] cannot be
> > > > applied to (java.lang.String,(String) => Boolean,() => Boolean)
> > > > [WARNING]               val singular: Boolean =
> > > BindHelpers.attr("singular", {s:
> > > > String => s.toLowerCase match {
>
> > > > What I find weird is that the references to
> > > > net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
>
> > > > The offending line of code:
> > > >                  val singular: Boolean = BindHelpers.attr("singular",
> > > > {s: String => s.toLowerCase match {
> > > >                          case "" => true
> > > >                          case "true" => true
> > > >                          case "t" => true
> > > >                          case "yes" => true
> > > >                          case "y" => true
> > > >                          case _ => false}}, () => false)
>
> > > > I have also tried
>
> > > >                  val singular: Boolean = BindHelpers.attr("singular",
> > > > {s: String => s.toLowerCase match {
> > > >                          case "" => true
> > > >                          case "true" => true
> > > >                          case "t" => true
> > > >                          case "yes" => true
> > > >                          case "y" => true
> > > >                          case _ => false}}, false)
>
> > > > which gets
>
> > > > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > > > snippet/TD.scala:99: error: type mismatch;
> > > > [WARNING]  found   : (String) => Boolean
> > > > [WARNING]  required: (net.liftweb.util.BindHelpers.attr.Info) => Boolean
> > > > [WARNING]               val singular: Boolean =
> > > BindHelpers.attr("singular", {s:
> > > > String => s.toLowerCase match {
>
> > > > Once again the references to (net.liftweb.util.BindHelpers.attr.Info)
> > > > => Boolean puzzle me...
>
> > > > It is like     def apply[T](key: String, f: String => T, default: =>
> > > > T): T = attr(key).map(n => f(n.toString)).getOrElse(default)
> > > > doesn't match...
>
> > > > I tried to help the compiler with
>
> > > >                  val singular: Boolean = Bin

[Lift] Re: Building the Lift book?

[Kris Nuttycombe]

How odd; it appears that the lyx binaries for amd64 must not have the same
layouts as i386, because on my work machine (i386) the book compiles fine.

Good to go now, thanks

Kris

On Thu, Jan 8, 2009 at 10:54 PM, Derek Chen-Becker wrote:

> Actually, I had to compile LyX 1.6.1 from source. My Intrepid install only
> shows LyX 1.5.6 as the most recent. Did you install from source, too, or did
> you find a dpkg somewhere?
>
> Derek
>
>
> On Thu, Jan 8, 2009 at 10:52 PM, Derek Chen-Becker 
> wrote:
>
>> I actually show book.layout as being part of Lyx:
>>
>> /usr/share/lyx/layouts/book.layout
>>
>> Bizarre...
>>
>>
>>
>> On Thu, Jan 8, 2009 at 10:01 PM, Kris Nuttycombe <
>> kris.nuttyco...@gmail.com> wrote:
>>
>>> It seems that upgrading to Ubuntu Intrepid has for some reason made me
>>> unable to build Tyler/Derek/Marius's Lift book. I'm a total LaTeX noob - can
>>> somebody help me out with how to figure out what the missing document class
>>> is, as referred to in this helpful error message? I'm almost sure I was able
>>> to build the book a few weeks ago.
>>>
>>> The layout file requested by this document,
>>> book.layout,
>>> is not usable. This is probably because a LaTeX
>>> class or style file required by it is not
>>> available. See the Customization documentation
>>> for more information.
>>> LyX will not be able to produce output.
>>> Warning: Document class not available
>>>
>>> I'm using Lyx version 1.6.1
>>>
>>> Kris
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Building the Lift book?

[Alex Boisvert]

For Ubuntu Ibex, I got mine from:
http://www.getdeb.net/release/3591

boisv...@boog:~$ dpkg -l | grep lyx
ii  lyx
1.6.1-1~getdeb1 Document Processor
ii  lyx-common
1.6.1-1~getdeb1 Architecture-independent files for
LyX

alex

On Thu, Jan 8, 2009 at 9:54 PM, Derek Chen-Becker wrote:

> Actually, I had to compile LyX 1.6.1 from source. My Intrepid install only
> shows LyX 1.5.6 as the most recent. Did you install from source, too, or did
> you find a dpkg somewhere?
>
> Derek
>
>
> On Thu, Jan 8, 2009 at 10:52 PM, Derek Chen-Becker 
> wrote:
>
>> I actually show book.layout as being part of Lyx:
>>
>> /usr/share/lyx/layouts/book.layout
>>
>> Bizarre...
>>
>>
>>
>> On Thu, Jan 8, 2009 at 10:01 PM, Kris Nuttycombe <
>> kris.nuttyco...@gmail.com> wrote:
>>
>>> It seems that upgrading to Ubuntu Intrepid has for some reason made me
>>> unable to build Tyler/Derek/Marius's Lift book. I'm a total LaTeX noob - can
>>> somebody help me out with how to figure out what the missing document class
>>> is, as referred to in this helpful error message? I'm almost sure I was able
>>> to build the book a few weeks ago.
>>>
>>> The layout file requested by this document,
>>> book.layout,
>>> is not usable. This is probably because a LaTeX
>>> class or style file required by it is not
>>> available. See the Customization documentation
>>> for more information.
>>> LyX will not be able to produce output.
>>> Warning: Document class not available
>>>
>>> I'm using Lyx version 1.6.1
>>>
>>> Kris
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Building the Lift book?

[Kris Nuttycombe]

I found the debs for 1.6.1 at getdeb.net

Kris

On Thu, Jan 8, 2009 at 10:54 PM, Derek Chen-Becker wrote:

> Actually, I had to compile LyX 1.6.1 from source. My Intrepid install only
> shows LyX 1.5.6 as the most recent. Did you install from source, too, or did
> you find a dpkg somewhere?
>
> Derek
>
>
> On Thu, Jan 8, 2009 at 10:52 PM, Derek Chen-Becker 
> wrote:
>
>> I actually show book.layout as being part of Lyx:
>>
>> /usr/share/lyx/layouts/book.layout
>>
>> Bizarre...
>>
>>
>>
>> On Thu, Jan 8, 2009 at 10:01 PM, Kris Nuttycombe <
>> kris.nuttyco...@gmail.com> wrote:
>>
>>> It seems that upgrading to Ubuntu Intrepid has for some reason made me
>>> unable to build Tyler/Derek/Marius's Lift book. I'm a total LaTeX noob - can
>>> somebody help me out with how to figure out what the missing document class
>>> is, as referred to in this helpful error message? I'm almost sure I was able
>>> to build the book a few weeks ago.
>>>
>>> The layout file requested by this document,
>>> book.layout,
>>> is not usable. This is probably because a LaTeX
>>> class or style file required by it is not
>>> available. See the Customization documentation
>>> for more information.
>>> LyX will not be able to produce output.
>>> Warning: Document class not available
>>>
>>> I'm using Lyx version 1.6.1
>>>
>>> Kris
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

I hate git on windows ... I use it for the book unfortunatelly.

On Jan 9, 1:46 pm, "David Pollak" 
wrote:
> On Fri, Jan 9, 2009 at 2:59 AM, Marius  wrote:
>
> > That's weird. I see that someone modified the code that I committed
> > moving most of the logic in the trait itself. I'm not sure if David
> > did that cause in git I see "unknown" author.
>
> Yep... it was me... from my Windows machine which has a less
> than awesome support for Git.
>
> > I do  like those changes
> > but I need to look later on today when I get home if they have
> > something to do with your problem. Since apply functions are
> > implemented in the trait itself it it seems that compiler does not see
> > that Info abstract type is in fact a String in the attr object
> > context. I wonder if it's a compiler bug :D
>
> Hmmm... that'd suck.

Oh yeah big time ... If indeed my assumption is correct (which I need
to verify) I'll open a compiler bug and see if I can fix it. Worst
case scenario rollback ... which I hope it won't be the case.

>
>
>
>
>
> > In my tests I used similar examples as you did and worked with no
> > problems. But I did not test with latest changed.
>
> > Br's,
> > Marius
>
> > On Jan 9, 10:35 am, Marc Boschma 
> > >
> > wrote:
> > > Me either (rather embarrassing, had an old copy of BindHelpers.scala
> > > lying about :/ )
>
> > > However, a rather strange outcome...
>
> > > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > > snippet/TD.scala:99: error: overloaded method value apply with
> > > alternatives [T](String,String,
> > > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T](String,
> > > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> > > (String,String,(net.liftweb.util.BindHelpers.attr.Info) => T)Option[T]
> > >  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > > T)Option[T]  (String,String,=>
> > > net
> > > .liftweb
> > > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> > >  (String,=>
> > > net
> > > .liftweb
> > > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> > >  (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]
> > >  (String)Option[net.liftweb.util.BindHelpers.attr.Info] cannot be
> > > applied to (java.lang.String,(String) => Boolean,() => Boolean)
> > > [WARNING]               val singular: Boolean =
> > BindHelpers.attr("singular", {s:
> > > String => s.toLowerCase match {
>
> > > What I find weird is that the references to
> > > net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
>
> > > The offending line of code:
> > >                  val singular: Boolean = BindHelpers.attr("singular",
> > > {s: String => s.toLowerCase match {
> > >                          case "" => true
> > >                          case "true" => true
> > >                          case "t" => true
> > >                          case "yes" => true
> > >                          case "y" => true
> > >                          case _ => false}}, () => false)
>
> > > I have also tried
>
> > >                  val singular: Boolean = BindHelpers.attr("singular",
> > > {s: String => s.toLowerCase match {
> > >                          case "" => true
> > >                          case "true" => true
> > >                          case "t" => true
> > >                          case "yes" => true
> > >                          case "y" => true
> > >                          case _ => false}}, false)
>
> > > which gets
>
> > > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > > snippet/TD.scala:99: error: type mismatch;
> > > [WARNING]  found   : (String) => Boolean
> > > [WARNING]  required: (net.liftweb.util.BindHelpers.attr.Info) => Boolean
> > > [WARNING]               val singular: Boolean =
> > BindHelpers.attr("singular", {s:
> > > String => s.toLowerCase match {
>
> > > Once again the references to (net.liftweb.util.BindHelpers.attr.Info)
> > > => Boolean puzzle me...
>
> > > It is like     def apply[T](key: String, f: String => T, default: =>
> > > T): T = attr(key).map(n => f(n.toString)).getOrElse(default)
> > > doesn't match...
>
> > > I tried to help the compiler with
>
> > >                  val singular: Boolean = BindHelpers.attr[Boolean]
> > > ("singular", {s: String => s.toLowerCase match {
> > >                          case "" => true
> > >                          case "true" => true
> > >                          case "t" => true
> > >                          case "yes" => true
> > >                          case "y" => true
> > >                          case _ => false}}, false)
>
> > > and got
>
> > > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > > snippet/TD.scala:99: error: overloaded method value apply with
> > > alternatives (String,String,(net.liftweb.util.BindHelpers.attr.Info)
> > > => Boolean,=> Boolean)Boolean  (String,
> > > (net.liftweb.util.BindHelpers.attr.Info) => Boolean,=> Boolean)Boolean
> > >  (String,String,(net.liftweb.util.Bin

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

On Fri, Jan 9, 2009 at 2:59 AM, Marius  wrote:

>
> That's weird. I see that someone modified the code that I committed
> moving most of the logic in the trait itself. I'm not sure if David
> did that cause in git I see "unknown" author.


Yep... it was me... from my Windows machine which has a less
than awesome support for Git.


> I do  like those changes
> but I need to look later on today when I get home if they have
> something to do with your problem. Since apply functions are
> implemented in the trait itself it it seems that compiler does not see
> that Info abstract type is in fact a String in the attr object
> context. I wonder if it's a compiler bug :D


Hmmm... that'd suck.


>
>
> In my tests I used similar examples as you did and worked with no
> problems. But I did not test with latest changed.
>
>
> Br's,
> Marius
>
> On Jan 9, 10:35 am, Marc Boschma 
> >
> wrote:
> > Me either (rather embarrassing, had an old copy of BindHelpers.scala
> > lying about :/ )
> >
> > However, a rather strange outcome...
> >
> > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > snippet/TD.scala:99: error: overloaded method value apply with
> > alternatives [T](String,String,
> > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T](String,
> > (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> > (String,String,(net.liftweb.util.BindHelpers.attr.Info) => T)Option[T]
> >  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > T)Option[T]  (String,String,=>
> > net
> > .liftweb
> > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> >  (String,=>
> > net
> > .liftweb
> > .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info
> >  (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]
> >  (String)Option[net.liftweb.util.BindHelpers.attr.Info] cannot be
> > applied to (java.lang.String,(String) => Boolean,() => Boolean)
> > [WARNING]   val singular: Boolean =
> BindHelpers.attr("singular", {s:
> > String => s.toLowerCase match {
> >
> > What I find weird is that the references to
> > net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
> >
> > The offending line of code:
> >  val singular: Boolean = BindHelpers.attr("singular",
> > {s: String => s.toLowerCase match {
> >  case "" => true
> >  case "true" => true
> >  case "t" => true
> >  case "yes" => true
> >  case "y" => true
> >  case _ => false}}, () => false)
> >
> > I have also tried
> >
> >  val singular: Boolean = BindHelpers.attr("singular",
> > {s: String => s.toLowerCase match {
> >  case "" => true
> >  case "true" => true
> >  case "t" => true
> >  case "yes" => true
> >  case "y" => true
> >  case _ => false}}, false)
> >
> > which gets
> >
> > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > snippet/TD.scala:99: error: type mismatch;
> > [WARNING]  found   : (String) => Boolean
> > [WARNING]  required: (net.liftweb.util.BindHelpers.attr.Info) => Boolean
> > [WARNING]   val singular: Boolean =
> BindHelpers.attr("singular", {s:
> > String => s.toLowerCase match {
> >
> > Once again the references to (net.liftweb.util.BindHelpers.attr.Info)
> > => Boolean puzzle me...
> >
> > It is like def apply[T](key: String, f: String => T, default: =>
> > T): T = attr(key).map(n => f(n.toString)).getOrElse(default)
> > doesn't match...
> >
> > I tried to help the compiler with
> >
> >  val singular: Boolean = BindHelpers.attr[Boolean]
> > ("singular", {s: String => s.toLowerCase match {
> >  case "" => true
> >  case "true" => true
> >  case "t" => true
> >  case "yes" => true
> >  case "y" => true
> >  case _ => false}}, false)
> >
> > and got
> >
> > [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> > snippet/TD.scala:99: error: overloaded method value apply with
> > alternatives (String,String,(net.liftweb.util.BindHelpers.attr.Info)
> > => Boolean,=> Boolean)Boolean  (String,
> > (net.liftweb.util.BindHelpers.attr.Info) => Boolean,=> Boolean)Boolean
> >  (String,String,(net.liftweb.util.BindHelpers.attr.Info) =>
> > Boolean)Option[Boolean]  (String,
> > (net.liftweb.util.BindHelpers.attr.Info) => Boolean)Option[Boolean]
> > cannot be applied to (java.lang.String,(String) => Boolean,Boolean)
> > [WARNING]   val singular: Boolean = BindHelpers.attr[Boolean]
> > ("singular", {s: String => s.toLowerCase match {
> >
> > Marc
> >
> > On 09/01/2009, at 3:44 PM, David Pollak wrote:
> >
> > > Marc,
> >
> > > Sorry... dunno what to tell you. :-(
>

Re: Build problem. Was: [Lift] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

That's weird. I see that someone modified the code that I committed
moving most of the logic in the trait itself. I'm not sure if David
did that cause in git I see "unknown" author. I do  like those changes
but I need to look later on today when I get home if they have
something to do with your problem. Since apply functions are
implemented in the trait itself it it seems that compiler does not see
that Info abstract type is in fact a String in the attr object
context. I wonder if it's a compiler bug :D

In my tests I used similar examples as you did and worked with no
problems. But I did not test with latest changed.


Br's,
Marius

On Jan 9, 10:35 am, Marc Boschma  wrote:
> Me either (rather embarrassing, had an old copy of BindHelpers.scala  
> lying about :/ )
>
> However, a rather strange outcome...
>
> [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> snippet/TD.scala:99: error: overloaded method value apply with  
> alternatives [T](String,String,
> (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T](String,
> (net.liftweb.util.BindHelpers.attr.Info) => T,=> T)T  [T]
> (String,String,(net.liftweb.util.BindHelpers.attr.Info) => T)Option[T]  
>  [T](String,(net.liftweb.util.BindHelpers.attr.Info) =>  
> T)Option[T]  (String,String,=>  
> net
> .liftweb
> .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info  
>  (String,=>  
> net
> .liftweb
> .util.BindHelpers.attr.Info)net.liftweb.util.BindHelpers.attr.Info  
>  (String,String)Option[net.liftweb.util.BindHelpers.attr.Info]  
>  (String)Option[net.liftweb.util.BindHelpers.attr.Info] cannot be  
> applied to (java.lang.String,(String) => Boolean,() => Boolean)
> [WARNING]               val singular: Boolean = BindHelpers.attr("singular", 
> {s:  
> String => s.toLowerCase match {
>
> What I find weird is that the references to  
> net.liftweb.util.BindHelpers.attr.Info (NodeSeq)
>
> The offending line of code:
>                  val singular: Boolean = BindHelpers.attr("singular",  
> {s: String => s.toLowerCase match {
>                          case "" => true
>                          case "true" => true
>                          case "t" => true
>                          case "yes" => true
>                          case "y" => true
>                          case _ => false}}, () => false)
>
> I have also tried
>
>                  val singular: Boolean = BindHelpers.attr("singular",  
> {s: String => s.toLowerCase match {
>                          case "" => true
>                          case "true" => true
>                          case "t" => true
>                          case "yes" => true
>                          case "y" => true
>                          case _ => false}}, false)
>
> which gets
>
> [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> snippet/TD.scala:99: error: type mismatch;
> [WARNING]  found   : (String) => Boolean
> [WARNING]  required: (net.liftweb.util.BindHelpers.attr.Info) => Boolean
> [WARNING]               val singular: Boolean = BindHelpers.attr("singular", 
> {s:  
> String => s.toLowerCase match {
>
> Once again the references to (net.liftweb.util.BindHelpers.attr.Info)  
> => Boolean puzzle me...
>
> It is like     def apply[T](key: String, f: String => T, default: =>  
> T): T = attr(key).map(n => f(n.toString)).getOrElse(default)      
> doesn't match...
>
> I tried to help the compiler with
>
>                  val singular: Boolean = BindHelpers.attr[Boolean]
> ("singular", {s: String => s.toLowerCase match {
>                          case "" => true
>                          case "true" => true
>                          case "t" => true
>                          case "yes" => true
>                          case "y" => true
>                          case _ => false}}, false)
>
> and got
>
> [WARNING] /Users/marc/src/dad/todo/src/main/scala/com/liftworkshop/
> snippet/TD.scala:99: error: overloaded method value apply with  
> alternatives (String,String,(net.liftweb.util.BindHelpers.attr.Info)  
> => Boolean,=> Boolean)Boolean  (String,
> (net.liftweb.util.BindHelpers.attr.Info) => Boolean,=> Boolean)Boolean  
>  (String,String,(net.liftweb.util.BindHelpers.attr.Info) =>  
> Boolean)Option[Boolean]  (String,
> (net.liftweb.util.BindHelpers.attr.Info) => Boolean)Option[Boolean]  
> cannot be applied to (java.lang.String,(String) => Boolean,Boolean)
> [WARNING]               val singular: Boolean = BindHelpers.attr[Boolean]
> ("singular", {s: String => s.toLowerCase match {
>
> Marc
>
> On 09/01/2009, at 3:44 PM, David Pollak wrote:
>
> > Marc,
>
> > Sorry... dunno what to tell you. :-(
>
> > David
>
> > On Thu, Jan 8, 2009 at 3:47 PM, Marc Boschma  > +lift...@boschma.cx> wrote:
> > Very cool indeed, except... I now get:
>
> > [WARNING] /Users/marc/src/todo/src/main/scala/com/liftworkshop/
> > snippet/TD.scala:99: error: value attr is not a member of object  
> > net.liftweb.util.BindHelpers
> > [WARNING]          val singular = BindH