[Lift] Re: Bug in MappedEmail: emailPattern is wrong

[Marc Boschma]

Your right... I've been thinking about that and how the current mapper  
only does the regex check.. could always override the validate method...

Marc
On 27/08/2009, at 6:39 PM, Viktor Klang wrote:

>
>
> On Thu, Aug 27, 2009 at 10:27 AM, Marc Boschma  > wrote:
> Personally I use:
>
> "^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-] 
> +)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01- 
> \x09\x0b\x0c\x0e-\x7f])*")@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a- 
> z0-9](?:[a-z0-9-]*[a-z0-9])?$"
>
> Impressive!
>
> It still doesn't tell you if the email is real or not ;)
>
>
> Marc
>
> On 27/08/2009, at 9:32 AM, David Pollak wrote:
>
>> Thanks.
>>
>> Changed and pushed to GitHub.  Allow 2 hours for Maven availability.
>>
>> On Wed, Aug 26, 2009 at 4:15 PM, harryh  wrote:
>>
>> > What's the change to the RegEx?
>>
>> val emailPattern = Pattern.compile("^[a-z0-9._%-+]+@(?:[a-z0-9-]+\ 
>> \.)+
>> [a-z]{2,4}$")
>>
>> note the addition of the + to the allowed characters before the @
>>
>> -harryh
>>
>>
>>
>>
>> -- 
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>
>
>
>
>
>
> -- 
> Viktor Klang
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
>
> Lift Committer - liftweb.com
> AKKA Committer - akkasource.org
> Cassidy - github.com/viktorklang/Cassidy.git
> SoftPub founder: http://groups.google.com/group/softpub
>
> >


--~--~-~--~~~---~--~~
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: Bug in MappedEmail: emailPattern is wrong

[Marc Boschma]

Personally I use:

"^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-] 
+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01- 
\x09\x0b\x0c\x0e-\x7f])*")@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a- 
z0-9](?:[a-z0-9-]*[a-z0-9])?$"

Marc

On 27/08/2009, at 9:32 AM, David Pollak wrote:

> Thanks.
>
> Changed and pushed to GitHub.  Allow 2 hours for Maven availability.
>
> On Wed, Aug 26, 2009 at 4:15 PM, harryh  wrote:
>
> > What's the change to the RegEx?
>
> val emailPattern = Pattern.compile("^[a-z0-9._%-+]+@(?:[a-z0-9-]+\\.)+
> [a-z]{2,4}$")
>
> note the addition of the + to the allowed characters before the @
>
> -harryh
>
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >


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

[Lift] Re: Multiple sites, same login

[Marc Boschma]

Maybe https://opensso.dev.java.net/ might be of interest? Might also  
be a bit of work...

Marc

On 26/08/2009, at 2:53 AM, Charles F. Munat wrote:

>
> Now this is an interesting idea. I'll think about it...
>
> Thanks!
>
> Chas.
>
> David Pollak wrote:
>>
>>
>> On Mon, Aug 24, 2009 at 3:23 PM, Charles F. Munat > > wrote:
>>
>>
>>I'm building two Lift applications that access the same back end
>>database -- one is for the public site, and the other, which  
>> will use a
>>subdomain, is for administration of the public site.
>>
>>A third application will access a separate database, but will be  
>> related
>>to the previous two sites.
>>
>>Any suggestions as to how I might have one login that keeps the  
>> user
>>logged in across all these sites? Obviously, OpenID would work,  
>> and
>>there's complex stuff involving LDAP servers, etc., but I'd like  
>> to keep
>>it fairly simple.
>>
>>Ideas?
>>
>>
>> You could put a cookie at the top level for the domain that's an
>> encrypted mix of the user's primary key and the current time.  If the
>> user comes to another one of the sites, it could examine the cookie  
>> and
>> see if it should create a session for the user.
>>
>>
>>
>>
>>Thanks!
>>Chas.
>>
>>
>>
>>
>>
>> -- 
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>>
>
> >


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

[Lift] Re: ws-generated code in lift

[Marc Boschma]

So I assume XMPP and AMQP would be other sinks / sources? If so the  
mind is boggling with old ideas laid to rest for some time...

A thought that comes to mind is that of a source and sink are of the  
same type, eg. AMQP, would the interconnection make use of that  
technologies underlying implementation. eg. AMQP exchanges?

Time to check out the progress in git...

Marc

On 18/08/2009, at 3:20 AM, David Pollak wrote:

> With Goat Rodeo, you can define message flow with an abstract source  
> (input) and sink (output) in the form:
>
> Foo %> Bar %> (Baz * Distribution)
>
> You can define fork/join constructs, tee constructs, etc. in the  
> high level flow description.  The flow description defines the type- 
> safe progression from each logic unit.  The location of each logic  
> unit and the threading/transport model is decided at runtime.  This  
> means that you can define logic models and plug in an "Akka  
> distribution and threading" strategy for production or a "single  
> threaded" strategy for your local test harness.
>
> You'll also be able to register the composed modules that can be  
> composed into larger flows.
>
> So, how does this work with SOAP?  Well.. the SOAP piece is just a  
> source and sink for the logic flow.
>


--~--~-~--~~~---~--~~
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: Anyone tried to use Velocity with scala/lift?

[Marc Boschma]

I think your right - see

http://www.scala-lang.org/docu/files/api/scala/reflect/BeanProperty.html
and http://scala.sygneca.com/code/defining-bean-properties

for how to add the annotations to the classes for Velocity to be able  
to see the properties...

Marc

On 10/07/2009, at 3:04 AM, Ewan wrote:

>
> Bit of googling and came across some wicket/scala folks having a
> similar problem who got around the problem with the following:
>
>  implicit def listToJavaList[T](l: Seq[T]) = l.foldLeft(new
> java.util.ArrayList[T](l.size)){(al, e) => al.add(e); al}
>
> and magically I can pull out the value now.  What I can't do now are
> pull out an object's properties for example:
>
>
> #foreach($user in $headers.users)
>hello $user.firstname $user.lastname
> #end
>
> I reckon the problem is that Velocity must use bean introspection and
> without getters I can't get the values.
>
> --Ewan
>
> >


--~--~-~--~~~---~--~~
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: Pagination in lift?

[Marc Boschma]

See the Lift book (http://tinyurl.com/mta3h5), section 6.1.10 & 6.1.8  
which discusses pagination with Mapper...

Marc

On 29/06/2009, at 5:44 AM, Naftoli Gugenhem wrote:

>
> Does lift have built in support for pagination -- breaking up a  
> query and continuing it across multiple pages, and clicking the  
> headers to sort?
> If not how hard is 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: Can't embed a snippet

[Marc Boschma]

Sleeping on it the snippet would be as simple as

def group(c : scala.xml.NodeSeq) : scala.xml.NodeSeq =  
scala.xml.Group(c)

which would allow for:


Welcome
Put welcome details here


The advantage is that it is in the lift name space...

Marc

On 25/06/2009, at 8:59 PM, Marc Boschma wrote:

>
> Wouldn't this work with the Scala XML parser?
>
> 
> Welcome
> Put welcome details here.
> 
> On 25/06/2009, at 1:08 AM, Nolan Darilek wrote:
>
>>
>


--~--~-~--~~~---~--~~
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: Can't embed a snippet

[Marc Boschma]

Wouldn't this work with the Scala XML parser?


Welcome
Put welcome details here.

On 25/06/2009, at 1:08 AM, Nolan Darilek wrote:

>
> On 06/24/2009 09:40 AM, Derek Chen-Becker wrote:
>> Wait a second. I have plenty of templates that have multiple elements
>> in them. What exactly is the problem you're seeing here?
>>
> Using 1.1, I have the following in templates-hidden/welcome.html:
>
> Welcome
>
> Put welcome details here.
>
> Running mvn test gives me the following failure report:
>
> ---
> Test set: info.thewordnerd.therascribe.AppTest
> ---
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.8  
> sec
> <<< FAILURE!
> testXml(info.thewordnerd.therascribe.AppTest)  Time elapsed: 1.474 sec
> <<< FAILURE!
> junit.framework.AssertionFailedError: Malformed XML in 1 file:
> src/main/webapp/templates-hidden/welcome.html
> at junit.framework.Assert.fail(Assert.java:47)
> at info.thewordnerd.therascribe.AppTest.testXml(AppTest.scala:72)
> ..
>
> From the surefire report:
>
> Malformed XML in 1 file:
> src/main/webapp/templates-hidden/welcome.html
> 
> :3:70: document must contain exactly one element
>  ^
> 
>
> Surrounding it in a div fixes that. Must be a new addition in 1.1?
>
>
> >


--~--~-~--~~~---~--~~
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: Jetty and Apache

[Marc Boschma]

I must admit I am grappling with this at the moment (in my spare  
time). I have a VPS with ngix installed, scala etc... but have no  
background on running up a 'production' instance of a JEE stack.  
Especially in a resource constrained environment like a VPS.

I also got 'distracted' with OSGi as a possible way to use a single  
JVM in which services could be loaded and unloaded (much the same way  
one can in an Erlang environment).

Being a traditionalist I haven't embraced cPanel...

Happy to play guinea pig.

Marc


On 21/06/2009, at 2:34 PM, DFectuoso wrote:

>
> Actually... what can I do to help you create a good tutorial on how to
> take any off the shelf vpn server running a LAMP stack to have nginx,
> jetty and apache running(and still using cpanel and everything else
> for php sites). I think that having a step by step tutorial on how to
> deploy to the GAE(i know you dont like it but hey), vpn, and Amazon
> EC2 would be great; I know there are some stuff out there but for
> people who have not used any java container its pretty hard to
> undertand what going on with all this softwares
>
> Kudos
>
> On Jun 20, 6:27 pm, David Pollak 
> wrote:
>> Apache does not deal well with long polling or lots of open  
>> connections.
>> For low traffic sites, it won't be noticeable.  However, I strongly
>> recommend nginx... it's a much much better http server than apache  
>> and it's
>> got a very small memory footprint.  On my servers, I run nginx at  
>> port 80
>> and proxy to apache for php sites.
>>
>> On Jun 20, 2009 3:11 PM, "DFectuoso"  wrote:
>>
>> I have a VPS in wiredtree where i would like to run a scala/lift
>> application with jeety in a server that is running a LAMP stack. I
>> want to use comet actors so i will be using the "long http hack"  
>> and i
>> dont know if that would be important.
>>
>> So what options do i have? How can i achieve this? I read there are
>> way to do this with mod_rewrite and with mod_proxy but i have no  
>> idea!
>
> >


--~--~-~--~~~---~--~~
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: The Lift 1.1 list

[Marc Boschma]

I have been reading up on OSGi with some discipline it could allow  
Erlang like live upgrades (also nice to not have to shutdown a JVM, so  
+1.

I'm curious on the Portlet support - is that embedding portlets in  
snippets and/or creating portlets (rather than servlets)?

Marc

On 02/04/2009, at 3:11 AM, David Pollak wrote:

> Folks,
>
> I think we've got our Lift 1.1 list.  If anyone has anything to add,  
> please speak up now.
> Improved documentation: better VScalaDoc coverage as well as better  
> tutorial and cook-book documentation.
> Improved J2EE support including JTA and Portlets.
> Finish Record/Field code with backing store including JDBC, JPA and  
> Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org)
> Improved client-side JavaScript support and better JavaScript  
> abstractions.
> Client/Server data synchronization (integrated with Record/Field)
> Improved support for REST.
> Improved performance including caching templates when running in  
> production mode.
> OSGi support.
> Improved testing framework and better testing support when running  
> in "test" mode.
> Implement Servlet 3.0 support.
> HTML 5 and Web Sockets support and integration with Kaazing's Web  
> Sockets server.  Also, sensing which browser is making the request  
> and performing optimizations based on that browser's characteristics  
> (specifically, Chrome and Firefox 3.1 support)
> We will have bug-fix releases of 1.0 along the way and we'll have a  
> release off the 1.0 branch when Scala 2.8 is released.
>

--~--~-~--~~~---~--~~
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: Ticket #19 (mail and character encoding)

[Marc Boschma]

It depends upon what is meant by "plain". According to RFC 2045 (5.2)  
the default character encoding for a non-MIME message is us-ascii and  
the transfer encoding would be 7bit.

Given that I think we are speaking of MIME encoded messages I think  
that the default of UTF-8 is ok in a lift context, but that you should  
provide the case class as not all email clients understand UTF-8 and  
if building a message that has the widest support is desired then it  
should be easy to specify alternatives that can be interpreted.

What is the treatment of character encoding in the interface? ie. can  
I specify base64 or quoted-printable, etc?

Marc

On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

> I'm looking at ticket #19:
>
> http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding
>
> The setText method is essentially a shortcut for setContent(...,  
> "text/plain"), but it also allows you to specify the character  
> encoding. Would anyone be opposed to modifying the code so that  
> PlainMailBodyType uses UTF-8 for character encoding? Would it be  
> useful to provide an additional case class, a la
>
> PlainPlusBodyType(text : String, charset : String)
>
> Derek
>
> >


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

[Lift] Re: XML unescaping

[Marc Boschma]

To quote David from a previous thread on the mailing list:

> I've enhanced LiftRules as follows:
>
>  /**
>  * A partial function that determines content type based on an  
> incoming
>  * RequestState and Accept header
>  */
>  var determineContentType:
>  PartialFunction[(Can[RequestState], Can[String]), String] = {
>case (_, Full(accept)) if
> accept.toLowerCase.contains("application/xhtml+xml") =>
>  "application/xhtml+xml"
>
>case _ => "text/html"
>  }
>
> You can change the determineContentType Partial Function in Boot.scala
> to accomplish your goals.


So maybe you could add in Boot.scala

determineContentType = {
case (Full(req), _) if req.path match {
case "text" :: "only" :: _ => true
case _ => false} => "text/html"
} orElse determineContentType

which would set the return type of any page under and including "/text/ 
only" to "text/html" and if not under that would chain to the standard  
lift content type determine partial function...

Obviously you could define your own function to check the path rather  
than in-line it...

David: Would req.param("x") be the equivalent to S.param("x") ??

Regards,

Marc


On 17/03/2009, at 2:58 PM, David Pollak wrote:

>
>
> On Mon, Mar 16, 2009 at 8:51 PM, Jeremy Mawson  > wrote:
> Thanks Marc.   works nicely.
>
> For this exercise this is hypothetical, but it matches very closely  
> a project I have enabled in the past using struts and JIBX...
>
> Say the data was sourced from an external party's service and there  
> was a contractual agreement to not alter the data in any way? I.E.  
> I'm stuck with the poorly formed HTML. Probably one could agree with  
> the partner that the transformation to valid XHTML is appropriate,  
> but I'll let the question stand anyway.
>
> Is poorly formed (but otherwise supported-by-browsers) HTML  
> renderable via Lift at all?
>
> If it's supported by the browser, it will be rendered, but Firefox  
> and Chrome will both complain about malformed XHTML.
>
> You could run the String through an HTML parser (there are a few  
> floating around for Java that will parse poorly formed HTML) and  
> then walk the nodes and build XML.  I would argue that this would  
> satisfy any contractual requirements, although I no longer practice  
> law, so I can't argue it on your behalf. :-)
>
>
>
> Cheers
> Jeremy
>
>
>
> 2009/3/17 Marc Boschma 
>
>
> On 17/03/2009, at 12:36 PM, Jeremy Mawson wrote:
>
>> If I change the line to "description" ->   
>> {Unparsed(result.description)}, it compiles but I have  
>> an unwanted span tag and worse ... if result.description is not  
>> well formed XML my page will fail to render! Firefox complains of  
>> an XML Parsing Error. The description field has an unmatched   
>> tag (literally <br>) in the middle of it to force it onto two  
>> lines.
>>
>
> Try "description" -> {Unparsed(result.description)} xml:group>
>
> That wraps the string in a scala XML group node...
>
> With respect to the  tag, it should be  or  to be  
> well formed. If you want to support non-well formed XML fro the  
> database wouldn't you need to parse it and convert it to well formed  
> first or upon retrieval ?
>
> Regards,
>
> Marc
>
>
>
>
>
>
> -- 
> Jeremy Mawson
> Senior Developer | Online Directories
>
> Sensis Pty Ltd
> 222 Lonsdale St
> Melbourne 3000
> E: jeremy.maw...@sensis.com.au
>
>
>
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >


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

[Lift] Re: XML unescaping

[Marc Boschma]

On 17/03/2009, at 12:36 PM, Jeremy Mawson wrote:

> If I change the line to "description" ->   
> {Unparsed(result.description)}, it compiles but I have  
> an unwanted span tag and worse ... if result.description is not well  
> formed XML my page will fail to render! Firefox complains of an XML  
> Parsing Error. The description field has an unmatched  tag  
> (literally 
) in the middle of it to force it onto two lines.
>

Try "description" -> {Unparsed(result.description)}

That wraps the string in a scala XML group node...

With respect to the  tag, it should be  or  to be  
well formed. If you want to support non-well formed XML fro the  
database wouldn't you need to parse it and convert it to well formed  
first or upon retrieval ?

Regards,

Marc


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

[Lift] Re: xml parser, utf-8, special characters... kill me now

[Marc Boschma]

On 16/03/2009, at 6:59 AM, Charles F. Munat wrote:

>
> That was my thinking. It doesn't explain why ç in gets  
> changed to
> ç, but it explains why ç in becomes ç out. So I think  
> there
> are two separate issues here.

I tend to agree.

>
>
> The ç can be created in two different ways in UTF-8. One is the single
> "c with a cedilla" character. The second is a c character followed  
> by a
> cedilla character. I am not sure how UTF-8 indicates that these two
> characters should be displayed as one.

the c with a cedilla two character sequence is encoded as 0063 0327  
which is equivalent to 00E7 (at least optically). the 0327 is seen as  
a modifier to the 'c' (0063) character.

> Neither am I sure that this has
> anything to do with the problem. Maybe it is simply that something is
> assuming Latin1 input even though the input is UTF-8.
>
> It is definitely on the front end, because it is stored in the  
> database
> as ç.
>
> When I use ç instead, the problem is that it is *not* converted
> to ç as it goes into the database, and then on the way out the XML
> interpreter does not recognize it as a character entity reference  
> and so
> converts the & to &.

I think this is due to using the standard Scala XML load functions  
rather than the lift XML parser. From memory I don't think the  
standard parser recognises that many named entities. ie. does ç  
work instead of ç ? If so then that is probably what is  
happening on this issue.

>
>
> Chas.
>
> Marc Boschma wrote:
>> Now I have some breakfast in me, to be clear it appears that UTF-8  
>> byte
>> stream is being interpreted as Latin1 and then converted to  
>> unicode...
>>
>> Marc
>> On 16/03/2009, at 6:25 AM, Marc Boschma wrote:
>>
>>> excuse the typo:
>>> On 16/03/2009, at 6:23 AM, Marc Boschma wrote:
>>>
>>>> Just looking at http://jeppesn.dk/utf-8.html , I found the  
>>>> following
>>>> lines:
>>>> Character  Latin1  Unicode UTF-8   Latin1
>>>>codeinterpr.
>>>> ç  E7  00 E7   C3 A7   ç
>>>> Ã is C38C, § is C2 A7
>>> Ã is C383
>>>> So it appears that somewhere there is a translation to Latin 1  
>>>> going on.
>>>> Hopefully that helps some what...
>>>> Regards,
>>>> Marc
>>>>
>>>> On 16/03/2009, at 1:08 AM, Derek Chen-Becker wrote:
>>>>
>>>>> This is really interesting. I've narrowed it down to something on
>>>>> form submission. The database shows gibberish, too, and if I
>>>>> manually enter the correct value in the DB it works fine on  
>>>>> display.
>>>>> If I print the UTF-8 byte values of the string I get from the
>>>>> browser for my description when I submit a cedilla (ç), I see:
>>>>>
>>>>> INFO - Submitted desc bytes = c3 83 c2 a7
>>>>>
>>>>> A cedilla is c3 a7 in UTF-8, so I'm not sure where the "83 c2" is
>>>>> coming from. I googled around a bit and I found other people  
>>>>> having
>>>>> the same issue but it wasn't clear in those posts what the cause
>>>>> was. I did a packet capture just as a sanity check, and here's  
>>>>> what
>>>>> I got:
>>>>>
>>>>> POST / HTTP/1.1
>>>>> ... headers here ...
>>>>>
>>>>> F956759623045OFT 
>>>>> = 
>>>>> true 
>>>>> &F956759623046BU5 
>>>>> =1&F9567596230472LR=2009%2F03%2F18&F956759623048IZR= 
>>>>> %C3%A7&F956759623049S3E=3&F956759623050E25=test
>>>>>
>>>>> As you can see, the (url encoded) value of the F956759623048IZR
>>>>> field (description) is %C3%A7, so something isn't properly
>>>>> converting that. Helpers.urlDecode seems to be working properly:
>>>>>
>>>>> scala> Helpers.urlDecode("F956759623048IZR=%C3%A7")
>>>>> res1: java.lang.String = F956759623048IZR=ç
>>>>>
>>>>> So I have no idea where this is coming from. All I know is that
>>>>> between the actual POST and when my submit function is called,
>>>>> something is tweaking the string. I'm going to dig some more,  
>>>>> but I
>>>>> wanted to post this in case 

[Lift] Re: xml parser, utf-8, special characters... kill me now

[Marc Boschma]

Now I have some breakfast in me, to be clear it appears that UTF-8  
byte stream is being interpreted as Latin1 and then converted to  
unicode...

Marc
On 16/03/2009, at 6:25 AM, Marc Boschma wrote:

> excuse the typo:
> On 16/03/2009, at 6:23 AM, Marc Boschma wrote:
>
>> Just looking at http://jeppesn.dk/utf-8.html , I found the  
>> following lines:
>> CharacterLatin1  Unicode UTF-8   Latin1
>>  codeinterpr.
>> çE7  00 E7   C3 A7   ç
>> Ã is C38C, § is C2 A7
> Ã is C383
>> So it appears that somewhere there is a translation to Latin 1  
>> going on.
>> Hopefully that helps some what...
>> Regards,
>> Marc
>>
>> On 16/03/2009, at 1:08 AM, Derek Chen-Becker wrote:
>>
>>> This is really interesting. I've narrowed it down to something on  
>>> form submission. The database shows gibberish, too, and if I  
>>> manually enter the correct value in the DB it works fine on  
>>> display. If I print the UTF-8 byte values of the string I get from  
>>> the browser for my description when I submit a cedilla (ç), I see:
>>>
>>> INFO - Submitted desc bytes = c3 83 c2 a7
>>>
>>> A cedilla is c3 a7 in UTF-8, so I'm not sure where the "83 c2" is  
>>> coming from. I googled around a bit and I found other people  
>>> having the same issue but it wasn't clear in those posts what the  
>>> cause was. I did a packet capture just as a sanity check, and  
>>> here's what I got:
>>>
>>> POST / HTTP/1.1
>>> ... headers here ...
>>>
>>> F956759623045OFT 
>>> = 
>>> true 
>>> &F956759623046BU5 
>>> =1&F9567596230472LR=2009%2F03%2F18&F956759623048IZR= 
>>> %C3%A7&F956759623049S3E=3&F956759623050E25=test
>>>
>>> As you can see, the (url encoded) value of the F956759623048IZR  
>>> field (description) is %C3%A7, so something isn't properly  
>>> converting that. Helpers.urlDecode seems to be working properly:
>>>
>>> scala> Helpers.urlDecode("F956759623048IZR=%C3%A7")
>>> res1: java.lang.String = F956759623048IZR=ç
>>>
>>> So I have no idea where this is coming from. All I know is that  
>>> between the actual POST and when my submit function is called,  
>>> something is tweaking the string. I'm going to dig some more, but  
>>> I wanted to post this in case it triggers any thoughts out there.
>>>
>>> Derek
>>>
>>> PS - I just found this:
>>>
>>> http://mail-archives.apache.org/mod_mbox/struts-dev/200604.mbox/%3c3769847.1145910729808.javamail.j...@brutus%3e
>>>
>>> May be related?
>>>
>>> On Sun, Mar 15, 2009 at 7:26 AM, Derek Chen-Becker >> > wrote:
>>> OK, I can replicate this in our PocketChange app (also going  
>>> against a PostgreSQL DB). Let me dig a bit.
>>>
>>> Derek
>>>
>>>
>>> On Sun, Mar 15, 2009 at 3:58 AM, Charles F. Munat   
>>> wrote:
>>>
>>> This might help, but I don't think I was clear. I have an online  
>>> form.
>>> My clients enter text into it. Their text has characters like a c  
>>> with a
>>> cedilla. That text gets saved into a PostgreSQL database (UTF-8)  
>>> varchar
>>> field via JPA/Hibernate.
>>>
>>> Then I pull it back out and dump it into a template, and it comes  
>>> out
>>> gibberish. If I try using ç instead, I get ¸ back  
>>> out.
>>>
>>> Here is what I have:
>>>
>>> "name" -> SHtml.text(thing.name, thing.name = _, ("size", "40"))
>>>
>>> If I enter "cachaça" in the field, I get cachaça back out. The  
>>> weird
>>> thing is that sometimes when I copy and paste text from another  
>>> document
>>> into the form, it works. But if I use the keyboard, it fails every  
>>> time.
>>>
>>> I'll play around with this. Thanks.
>>>
>>> Chas.
>>>
>>> Derek Chen-Becker wrote:
>>> > Oops, forgot scala.xml.Unparsed, too:
>>> >
>>> > scala> val m = a{ scala.xml.Unparsed("ç") }b
>>> > m: scala.xml.Elem = açb
>>> >
>>> > That one might be what you're looking for.
>>> >
>>> > Derek
>>> >
>>&g

[Lift] Re: xml parser, utf-8, special characters... kill me now

[Marc Boschma]

excuse the typo:
On 16/03/2009, at 6:23 AM, Marc Boschma wrote:

> Just looking at http://jeppesn.dk/utf-8.html , I found the following  
> lines:
> Character Latin1  Unicode UTF-8   Latin1
>   codeinterpr.
> ç E7  00 E7   C3 A7   ç
> Ã is C38C, § is C2 A7
à is C383
> So it appears that somewhere there is a translation to Latin 1 going  
> on.
> Hopefully that helps some what...
> Regards,
> Marc
>
> On 16/03/2009, at 1:08 AM, Derek Chen-Becker wrote:
>
>> This is really interesting. I've narrowed it down to something on  
>> form submission. The database shows gibberish, too, and if I  
>> manually enter the correct value in the DB it works fine on  
>> display. If I print the UTF-8 byte values of the string I get from  
>> the browser for my description when I submit a cedilla (ç), I see:
>>
>> INFO - Submitted desc bytes = c3 83 c2 a7
>>
>> A cedilla is c3 a7 in UTF-8, so I'm not sure where the "83 c2" is  
>> coming from. I googled around a bit and I found other people having  
>> the same issue but it wasn't clear in those posts what the cause  
>> was. I did a packet capture just as a sanity check, and here's what  
>> I got:
>>
>> POST / HTTP/1.1
>> ... headers here ...
>>
>> F956759623045OFT 
>> = 
>> true 
>> &F956759623046BU5 
>> =1&F9567596230472LR=2009%2F03%2F18&F956759623048IZR= 
>> %C3%A7&F956759623049S3E=3&F956759623050E25=test
>>
>> As you can see, the (url encoded) value of the F956759623048IZR  
>> field (description) is %C3%A7, so something isn't properly  
>> converting that. Helpers.urlDecode seems to be working properly:
>>
>> scala> Helpers.urlDecode("F956759623048IZR=%C3%A7")
>> res1: java.lang.String = F956759623048IZR=ç
>>
>> So I have no idea where this is coming from. All I know is that  
>> between the actual POST and when my submit function is called,  
>> something is tweaking the string. I'm going to dig some more, but I  
>> wanted to post this in case it triggers any thoughts out there.
>>
>> Derek
>>
>> PS - I just found this:
>>
>> http://mail-archives.apache.org/mod_mbox/struts-dev/200604.mbox/%3c3769847.1145910729808.javamail.j...@brutus%3e
>>
>> May be related?
>>
>> On Sun, Mar 15, 2009 at 7:26 AM, Derek Chen-Becker > > wrote:
>> OK, I can replicate this in our PocketChange app (also going  
>> against a PostgreSQL DB). Let me dig a bit.
>>
>> Derek
>>
>>
>> On Sun, Mar 15, 2009 at 3:58 AM, Charles F. Munat   
>> wrote:
>>
>> This might help, but I don't think I was clear. I have an online  
>> form.
>> My clients enter text into it. Their text has characters like a c  
>> with a
>> cedilla. That text gets saved into a PostgreSQL database (UTF-8)  
>> varchar
>> field via JPA/Hibernate.
>>
>> Then I pull it back out and dump it into a template, and it comes out
>> gibberish. If I try using ç instead, I get ¸ back  
>> out.
>>
>> Here is what I have:
>>
>> "name" -> SHtml.text(thing.name, thing.name = _, ("size", "40"))
>>
>> If I enter "cachaça" in the field, I get cachaça back out. The weird
>> thing is that sometimes when I copy and paste text from another  
>> document
>> into the form, it works. But if I use the keyboard, it fails every  
>> time.
>>
>> I'll play around with this. Thanks.
>>
>> Chas.
>>
>> Derek Chen-Becker wrote:
>> > Oops, forgot scala.xml.Unparsed, too:
>> >
>> > scala> val m = a{ scala.xml.Unparsed("ç") }b
>> > m: scala.xml.Elem = açb
>> >
>> > That one might be what you're looking for.
>> >
>> > Derek
>> >
>> > On Sat, Mar 14, 2009 at 9:57 PM, Derek Chen-Becker
>> > mailto:dchenbec...@gmail.com>> wrote:
>> >
>> > I think it depends on how you're embedding them in the XML:
>> >
>> > scala> val m = açb
>> > m: scala.xml.Elem = açb
>> >
>> > scala> val m = a{"ç"}b
>> > m: scala.xml.Elem = açb
>> >
>> > scala> val m = a{"ç"}b
>> > m: scala.xml.Elem = açb
>> >
>> > That last one was input using dead keys (alt+,) on my linux  
>> (USA
>

[Lift] Re: xml parser, utf-8, special characters... kill me now

[Marc Boschma]

Just looking at http://jeppesn.dk/utf-8.html , I found the following  
lines:
Character   Latin1  Unicode UTF-8   Latin1
codeinterpr.
ç   E7  00 E7   C3 A7   ç
à is C38C, § is C2 A7
So it appears that somewhere there is a translation to Latin 1 going on.
Hopefully that helps some what...
Regards,
Marc

On 16/03/2009, at 1:08 AM, Derek Chen-Becker wrote:

> This is really interesting. I've narrowed it down to something on  
> form submission. The database shows gibberish, too, and if I  
> manually enter the correct value in the DB it works fine on display.  
> If I print the UTF-8 byte values of the string I get from the  
> browser for my description when I submit a cedilla (ç), I see:
>
> INFO - Submitted desc bytes = c3 83 c2 a7
>
> A cedilla is c3 a7 in UTF-8, so I'm not sure where the "83 c2" is  
> coming from. I googled around a bit and I found other people having  
> the same issue but it wasn't clear in those posts what the cause  
> was. I did a packet capture just as a sanity check, and here's what  
> I got:
>
> POST / HTTP/1.1
> ... headers here ...
>
> F956759623045OFT 
> = 
> true 
> &F956759623046BU5=1&F9567596230472LR=2009%2F03%2F18&F956759623048IZR= 
> %C3%A7&F956759623049S3E=3&F956759623050E25=test
>
> As you can see, the (url encoded) value of the F956759623048IZR  
> field (description) is %C3%A7, so something isn't properly  
> converting that. Helpers.urlDecode seems to be working properly:
>
> scala> Helpers.urlDecode("F956759623048IZR=%C3%A7")
> res1: java.lang.String = F956759623048IZR=ç
>
> So I have no idea where this is coming from. All I know is that  
> between the actual POST and when my submit function is called,  
> something is tweaking the string. I'm going to dig some more, but I  
> wanted to post this in case it triggers any thoughts out there.
>
> Derek
>
> PS - I just found this:
>
> http://mail-archives.apache.org/mod_mbox/struts-dev/200604.mbox/%3c3769847.1145910729808.javamail.j...@brutus%3e
>
> May be related?
>
> On Sun, Mar 15, 2009 at 7:26 AM, Derek Chen-Becker  > wrote:
> OK, I can replicate this in our PocketChange app (also going against  
> a PostgreSQL DB). Let me dig a bit.
>
> Derek
>
>
> On Sun, Mar 15, 2009 at 3:58 AM, Charles F. Munat   
> wrote:
>
> This might help, but I don't think I was clear. I have an online form.
> My clients enter text into it. Their text has characters like a c  
> with a
> cedilla. That text gets saved into a PostgreSQL database (UTF-8)  
> varchar
> field via JPA/Hibernate.
>
> Then I pull it back out and dump it into a template, and it comes out
> gibberish. If I try using ç instead, I get ¸ back  
> out.
>
> Here is what I have:
>
> "name" -> SHtml.text(thing.name, thing.name = _, ("size", "40"))
>
> If I enter "cachaça" in the field, I get cachaça back out. The weird
> thing is that sometimes when I copy and paste text from another  
> document
> into the form, it works. But if I use the keyboard, it fails every  
> time.
>
> I'll play around with this. Thanks.
>
> Chas.
>
> Derek Chen-Becker wrote:
> > Oops, forgot scala.xml.Unparsed, too:
> >
> > scala> val m = a{ scala.xml.Unparsed("ç") }b
> > m: scala.xml.Elem = açb
> >
> > That one might be what you're looking for.
> >
> > Derek
> >
> > On Sat, Mar 14, 2009 at 9:57 PM, Derek Chen-Becker
> > mailto:dchenbec...@gmail.com>> wrote:
> >
> > I think it depends on how you're embedding them in the XML:
> >
> > scala> val m = açb
> > m: scala.xml.Elem = açb
> >
> > scala> val m = a{"ç"}b
> > m: scala.xml.Elem = açb
> >
> > scala> val m = a{"ç"}b
> > m: scala.xml.Elem = açb
> >
> > That last one was input using dead keys (alt+,) on my linux (USA
> > International with dead keys) layout. Let me know if this  
> doesn't
> > help; if not, could you send the code/template that's having  
> issues?
> >
> > Derek
> >
> >
> > On Sat, Mar 14, 2009 at 6:36 PM, Charles F. Munat  
>  > > wrote:
> >
> >
> > I have a site that uses a lot of "special" characters (a  
> remarkably
> > biased description, since there is nothing "special" about  
> accented
> > characters to the people who use them daily). In  
> particular, I
> > need the
> > c with cedilla and the n with the tilde.
> >
> > These characters are being input to a database (UTF-8) via  
> an online
> > form, then spit back out onto the page.
> >
> > It's a fucking disaster. Apparently, everything goes  
> through the xml
> > parser, which is great, except when I try to enter these  
> as entity
> > references, such as ç, the parser changes & to  
> & and
> > I get
> > the literal ç back out again.
> >
> > When I type ç using the keyboard (or copy and paste it  
> from a
> > page or a
> > text editor), 

[Lift] Re: xml parser, utf-8, special characters... kill me now

[Marc Boschma]

Which parser are you using?

Quick tests with PCDataXmlParser seems to indicate all ç get  
mapped to the unicode character. In fact it does that for all entities  
in object HtmlEntities (line 26 onwards in lift-util/src/main/scala/ 
net/liftweb/util/PCDataMarkupParser.scala)

If I enter the ç into a form it gets stored as the unicode character  
\u00E7 ... and also returns as that unicode character.

Regards,

Marc

On 15/03/2009, at 11:36 AM, Charles F. Munat wrote:

>
> I have a site that uses a lot of "special" characters (a remarkably
> biased description, since there is nothing "special" about accented
> characters to the people who use them daily). In particular, I need  
> the
> c with cedilla and the n with the tilde.
>
> These characters are being input to a database (UTF-8) via an online
> form, then spit back out onto the page.
>
> It's a fucking disaster. Apparently, everything goes through the xml
> parser, which is great, except when I try to enter these as entity
> references, such as ç, the parser changes & to & and I get
> the literal ç back out again.
>
> When I type ç using the keyboard (or copy and paste it from a page  
> or a
> text editor), I get gibberish.
>
> Anyone know the trick to getting around this? I need everything from e
> acute to e grave to trademark and registered trademark symbols, and I
> need to enter them this way.
>
> Thanks for any help. If I can get this to work, I'll add an  
> explanation
> to the wiki.
>
> Chas.
>
> >


--~--~-~--~~~---~--~~
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: Why does HelloWorld index.html contain a snippet rather than a complete XHTML page?

[Marc Boschma]

Apologies for the poor wording, but David got the right  
interpretation

Marc

On 14/03/2009, at 6:57 PM, David Pollak wrote:

> index.html is well formed XML... in fact all the "html" files that  
> Lift reads must be well formed.  You may choose to include XML  
> header information in your document, however, that header  
> information will be used by the code that reads the document (e.g.,  
> defining the encoding as something other than UTF-8), but the  
> internal representation is normalized XML and the way that the XML  
> is rendered will always be UTF-8 encoded with proper headers.
>
>

--~--~-~--~~~---~--~~
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: Why does HelloWorld index.html contain a snippet rather than a complete XHTML page?

[Marc Boschma]

Hi Mal,

That aspect of the lift templating approach also warped my head for a  
while, having seen so many examples of the opposite approach (PHP,  
JSP, etc)...

There is a certain part of me that still is unsettled about it, but I  
can see the advantages of it.

Marc
Ps. can the files such as index.html in the examples be full XML  
compliant documents?

On 13/03/2009, at 3:30 PM, mal3 wrote:

>
> Why does HelloWorld index.html contain a snippet rather than a
> complete XHTML page?
>
> When I first saw the HelloWorld example I thought there must be a
> mistake,
> because the index.html file contains a snippet, while default.html
> contains
> what looked more like a complete XHTML page.
>
> Why doesn't lift initially reference a complete XHTML page and then
> pull in the snippet(s)?
>
> Is it to make it difficult/impossible for logic to creep into the
> view?
>
> Mal.
>
> >


--~--~-~--~~~---~--~~
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: Removing xmlns:lift="http://liftweb.net/" in rendered page

[Marc Boschma]

I think what Ross is asking for isn't necessarily a bad thing for a  
given page which doesn't actually use the lift namespace after all  
processing has occurred.

Think of it in a more general sense: how do I filter any namespace  
that isn't actually present in the result XML? This is actually an  
important question from a security perspective as I may not want to  
divulge a name space that is used internally. eg. a "cms" name space  
expressed in a previous thread. If plug-ins or similar functionality  
is to be supported in the future the resolution of this issue is  
probably a must.

To my mind it should be possible to search the XML for all used name  
spaces and then to remove any name spaces declared but not present.

Whether or not the "lift" name space is treated specially or not is an  
implementation issue...

It should also be possible to raise an error if an element exists in a  
XML result that has a name space that shouldn't be present (the  
counter example).

Marc

On 28/02/2009, at 1:54 AM, David Pollak wrote:

>
>
> On Fri, Feb 27, 2009 at 6:08 AM, rossputin   
> wrote:
>
> Hi.
>
> Sure, I understand it is required as the xml is processed, is there a
> post process operation in the pipeline anywhere ?
>
> Ross,
>
> Lift emits XHTML to the browser that contains tags with lift:xxx  
> attributes to support the Comet services and also used the lift:gc  
> attribute to support other services until we found a significant  
> defect in Firefox and jQuery and decided to use another mechanism to  
> replace the lift:gc attributes.  Lift makes active use of the lift  
> namespace.  The xmlns:lift attribute is removed at your peril and  
> the removal will not be supported on this list.
>
> Thanks,
>
> David
>
>
> Thanks,
>
> Ross.
>
>
> On Feb 27, 1:59 pm, Timothy Perrett  wrote:
> > Ross,
> >
> > You cannot remove this namespace as it is needed to make it valid  
> XHTML -
> > Scala XML processing uses a strict xml processer to ensure that  
> the markup
> > is valid and complete before outputting it. Because we use  
> 
> > the namespace is required for the parser to pass that markup xml  
> as valid I
> > do believe.
> >
> > Tim
> >
> > On 27/02/2009 13:40, "rossputin"  wrote:
> >
> >
> >
> >
> >
> > > Hi.
> >
> > > Sure, its something I do to simplify as much as possible any
> > > unnecessary tags or attributes.  I suppose it is a practice I  
> picked
> > > up while using Cocoon.  Ultimately, I just want the purest xhtml
> > > output possible, hopefully revealing as little about the platform
> > > which produced it as possible.
> >
> > > Ross.
> >
> > > On Feb 27, 1:31 pm, Viktor Klang  wrote:
> > >> May I ask why?
> >
> > >> Cheers,
> > >> Viktor
> >
> > >> On Fri, Feb 27, 2009 at 1:23 PM, rossputin  
>  wrote:
> >
> > >>> Hi.
> >
> > >>> I am using lift 1.0.  I was hoping to remove the   
> 'xmlns:lift="http://
> > >>> liftweb.net/"' element from :
> >
> > >>> 
> > >>>  "http://
> > >>>www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> > >>> http://liftweb.net/"; xmlns="http://www.w3.org/1999/
> > >>> xhtml">
> >
> > >>> Thanks.
> >
> > >>> Ross.
> >
> > >>> On Feb 27, 12:18 pm, Timothy Perrett   
> wrote:
> >  Hey Ross,
> >
> >  Which element are you referring to? Head items? What version  
> of lift are
> > >>> you
> >  using? (you can find out by looking in pom.xml under the lift-*
> >  dependencies)
> >
> >  Thanks
> >
> >  Tim
> >
> >  On 27/02/2009 11:36, "rossputin"  wrote:
> >
> > > Hi.
> >
> > > I must admit I have not worked my way through the book yet,  
> but I was
> > > wondering if it is possible to remove the xmlns:lift="http://
> > > liftweb.net/" attribute on the html element in the rendered  
> page?
> >
> > > Thanks.
> >
> > > Ross.
> >
> > >> --
> > >> Viktor Klang
> > >> Senior Systems Analyst
>
>
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >


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

[Lift] Re: Build problems...

[Marc Boschma]

Yep on the pull and even deleting the entire directory structure and a  
clone... Same result.

Marc

On 17/02/2009, at 8:21 PM, Tim Perrett wrote:

>
> I'm not at my mac right now, but as of last night it was compilling
> fine on mac with the very latest master.
>
> What version of maven are you using? Might be a stupid question, but
> you have done a git pull to check your fully up to date?
>
> Cheers, Tim
>
> On Feb 17, 8:34 am, David Bernard  wrote:
>> Hi,
>>
>> I don't know Mac, there is a command line length limitation (as  
>> windows) and
>> is it possible that the shell block the execution and return exit  
>> code = 139
>> (without message) ?
>>
>> which version of java do you have ?
>>
>> Sorry to not be able to help you more :(
>>
>> /davidB
>>
>>
>>
>>> On 17/02/2009, at 3:35 PM, Josh Suereth wrote:
>>
 Hm All the integration tests pass, perhaps you should try
 using the new maven-scala plugin (run mvn install on the maven- 
 scala-
 plugin directory).  You do *not* want to clear your .m2 directory
 after doing so.  Then see if the new plugin fixes whatever issue is
 causing lift to break.  The other thing is try the scala command-
 line directly and see if you get a useful error meessage.
>>
 Once again, sorry I could not be more help!
>>
>>> Same result with the built plugin... hmmm. Not a problem on the help
>>> side of things! lift applications build rather nicely. Just can't
>>> build lift itself :(
>>
>>> Marc
> >


--~--~-~--~~~---~--~~
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: [maven-and-scala] [Lift] Build problems...

[Marc Boschma]

It does sound like a command length issue... here are some  
environmental info

Mac:~ marc$ mvn -v
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix"
Mac:~ marc$ which scala
/usr/local/bin/scala
Mac:~ marc$ scala -version
Scala code runner version 2.7.3.final -- Copyright 2002-2009, LAMP/EPFL
Mac:~ marc$ which java
/usr/bin/java
Mac:~ marc$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- 
b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode)
Mac:~ marc$ env
MANPATH=/usr/local/git/man:/usr/local/man:/usr/share/man:/usr/local/ 
share/man:/usr/X11/man:/usr/local/git/man:/Library/TeX/ 
Distributions/.DefaultTeX/Contents/Man
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
TMPDIR=/var/folders/l8/l8BwvqvYFaqSqWdyxJt58k+++TI/-Tmp-/
Apple_PubSub_Socket_Render=/tmp/launch-8L93U5/Render
TERM_PROGRAM_VERSION=240
USER=marc
COMMAND_MODE=unix2003
SSH_AUTH_SOCK=/tmp/launch-Jw9hjj/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0:0
PATH=/usr/local/git/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/ 
usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/ 
bin:/opt/local/bin:/usr/local/git/bin:/usr/texbin:/Users/marc/scala/ 
bin:/usr/local/graphviz/bin:/opt/neko:/opt/haxe
PWD=/Users/marc
JAVA_HOME=/Library/Java/Home
LANG=en_AU.UTF-8
DAZSTUDIOVERSION=17236230
SHLVL=1
HOME=/Users/marc
LOGNAME=marc
DISPLAY=/tmp/launch-7hYHhj/:0
SECURITYSESSIONID=b1eb60
DAZSTUDIO=/Applications/DAZStudio
_=/usr/bin/env
Mac:~ marc$



On 17/02/2009, at 7:34 PM, David Bernard wrote:

> Hi,
>
> I don't know Mac, there is a command line length limitation (as  
> windows) and is it possible that the shell block the execution and  
> return exit code = 139 (without message) ?
>
> which version of java do you have ?
>
> Sorry to not be able to help you more :(
>
> /davidB
>
>
>
>
> On 17/02/2009, at 3:35 PM, Josh Suereth wrote:
>
> > Hm All the integration tests pass, perhaps you should try
> > using the new maven-scala plugin (run mvn install on the maven- 
> scala-
> > plugin directory).  You do *not* want to clear your .m2 directory
> > after doing so.  Then see if the new plugin fixes whatever issue is
> > causing lift to break.  The other thing is try the scala command-
> > line directly and see if you get a useful error meessage.
> >
> >
> > Once again, sorry I could not be more help!
>
> Same result with the built plugin... hmmm. Not a problem on the help
> side of things! lift applications build rather nicely. Just can't
> build lift itself :(
>
> Marc
>
>
>
>
>
> >


--~--~-~--~~~---~--~~
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: [maven-and-scala] [Lift] Build problems...

[Marc Boschma]

On 17/02/2009, at 3:35 PM, Josh Suereth wrote:

> Hm All the integration tests pass, perhaps you should try  
> using the new maven-scala plugin (run mvn install on the maven-scala- 
> plugin directory).  You do *not* want to clear your .m2 directory  
> after doing so.  Then see if the new plugin fixes whatever issue is  
> causing lift to break.  The other thing is try the scala command- 
> line directly and see if you get a useful error meessage.
>
>
> Once again, sorry I could not be more help!

Same result with the built plugin... hmmm. Not a problem on the help  
side of things! lift applications build rather nicely. Just can't  
build lift itself :(

Marc


--~--~-~--~~~---~--~~
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: [maven-and-scala] [Lift] Build problems...

[Marc Boschma]

On 17/02/2009, at 3:18 PM, Josh Suereth wrote:

> Marc, Also try running the scalac command directly.  Here's what  
> Maven is trying to run on your machine:

The result is:

Mac:liftweb marc$ sh cmd
cmd: line 1: 10785 Segmentation fault  /System/Library/Frameworks/ 
JavaVM.framework/Versions/1.5.0/Home/bin/java -classpath /Users/ 
marc/.m2/repository/org/scala-lang/scala-compiler/2.7.3/scala- 
compiler-2.7.3.jar:/Users/marc/.m2/repository/org/scala-lang/scala- 
library/2.7.3/scala-library-2.7.3.jar -Xbootclasspath/a:/Users/ 
marc/.m2/repository/org/scala-lang/scala-library/2.7.3/scala- 
library-2.7.3.jar -Xmx1024m scala.tools.nsc.Main -deprecation -Xno- 
varargs-conversion -classpath /Users/marc/src/lift/liftweb/lift-util/ 
target/classes:/Users/marc/.m2/repository/org/scala-lang/scala-library/ 
2.7.3/scala-library-2.7.3.jar:/Users/marc/.m2/repository/org/slf4j/ 
slf4j-api/1.5.6/slf4j-api-1.5.6.jar:/Users/marc/.m2/repository/log4j/ 
log4j/1.2.14/log4j-1.2.14.jar:/Users/marc/.m2/repository/javax/servlet/ 
servlet-api/2.5/servlet-api-2.5.jar:/Users/marc/.m2/repository/javax/ 
mail/mail/1.4/mail-1.4.jar:/Users/marc/.m2/repository/javax/activation/ 
activation/1.1/activation-1.1.jar:/Users/marc/.m2/repository/commons- 
httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar:/Users/ 
marc/.m2/repository/commons-logging/commons-logging/1.0.4/commons- 
logging-1.0.4.jar:/Users/marc/.m2/repository/commons-codec/commons- 
codec/1.3/commons-codec-1.3.jar:/Users/marc/.m2/repository/commons- 
fileupload/commons-fileupload/1.2.1/commons-fileupload-1.2.1.jar:/ 
Users/marc/.m2/repository/commons-collections/commons-collections/ 
3.2.1/commons-collections-3.2.1.jar -d /Users/marc/src/lift/liftweb/ 
lift-util/target/classes /Users/marc/src/lift/liftweb/lift-util/src/ 
main/scala/net/liftweb/util/ActorPing.scala /Users/marc/src/lift/ 
liftweb/lift-util/src/main/scala/net/liftweb/util/ 
BasicTypesHelpers.scala /Users/marc/src/lift/liftweb/lift-util/src/ 
main/scala/net/liftweb/util/BindHelpers.scala /Users/marc/src/lift/ 
liftweb/lift-util/src/main/scala/net/liftweb/util/Box.scala /Users/ 
marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
ClassHelpers.scala /Users/marc/src/lift/liftweb/lift-util/src/main/ 
scala/net/liftweb/util/CodeHelpers.scala /Users/marc/src/lift/liftweb/ 
lift-util/src/main/scala/net/liftweb/util/CombParserHelpers.scala / 
Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
ControlHelpers.scala /Users/marc/src/lift/liftweb/lift-util/src/main/ 
scala/net/liftweb/util/CSSHelpers.scala /Users/marc/src/lift/liftweb/ 
lift-util/src/main/scala/net/liftweb/util/Currency.scala /Users/marc/ 
src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
HeadHelper.scala /Users/marc/src/lift/liftweb/lift-util/src/main/scala/ 
net/liftweb/util/Helpers.scala /Users/marc/src/lift/liftweb/lift-util/ 
src/main/scala/net/liftweb/util/HttpHelpers.scala /Users/marc/src/lift/ 
liftweb/lift-util/src/main/scala/net/liftweb/util/IOHelpers.scala / 
Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
JSON.scala /Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/ 
liftweb/util/KeyedCache.scala /Users/marc/src/lift/liftweb/lift-util/ 
src/main/scala/net/liftweb/util/Lazy.scala /Users/marc/src/lift/ 
liftweb/lift-util/src/main/scala/net/liftweb/util/LD.scala /Users/marc/ 
src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
ListHelpers.scala /Users/marc/src/lift/liftweb/lift-util/src/main/ 
scala/net/liftweb/util/LoanWrapper.scala /Users/marc/src/lift/liftweb/ 
lift-util/src/main/scala/net/liftweb/util/Log.scala /Users/marc/src/ 
lift/liftweb/lift-util/src/main/scala/net/liftweb/util/LRU.scala / 
Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
Mailer.scala /Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/ 
liftweb/util/NamedPartialFunction.scala /Users/marc/src/lift/liftweb/ 
lift-util/src/main/scala/net/liftweb/util/PCDataMarkupParser.scala / 
Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
Props.scala /Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/ 
liftweb/util/RE.scala /Users/marc/src/lift/liftweb/lift-util/src/main/ 
scala/net/liftweb/util/SecurityHelpers.scala /Users/marc/src/lift/ 
liftweb/lift-util/src/main/scala/net/liftweb/util/Slf4jLog.scala / 
Users/marc/src/lift/liftweb/lift-util/src/main/scala/net/liftweb/util/ 
StringHelpers.scala /Users/marc/src/lift/liftweb/lift-util/src/main/ 
scala/net/liftweb/util/ThreadGlobal.scala /Users/marc/src/lift/liftweb/ 
lift-util/src/main/scala/net/liftweb/util/TimeHelpers.scala
Mac:liftweb marc$


No core is dumped, that I can find...

Marc


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

[Lift] Re: Getting the "file" out of a Put Request..

[Marc Boschma]

Cool. That will make WebDAV and CalDAV support easier :)

On 17/02/2009, at 10:38 AM, David Pollak wrote:

>
>
> On Mon, Feb 16, 2009 at 3:34 PM, Alan M   
> wrote:
> I'm using maven for builds.. on .11-SNAPSHOT.. will this go there or
> will I have to switch over to building my own?
>
> It'll get built on Hudson and if you do a mvn -U, you'll get it.
>
> See http://scala-tools.org/hudson/job/lift/
>
> When build 344 is complete, the change will be there for you.
>
>
> Alan
>
> On Feb 16, 3:31 pm, David Pollak 
> wrote:
> > Alan,
> > I'm modifying Lift.  It turns out that it treated everything
> > like application/x-www-form-urlencoded if there was not another  
> handler.
> >
> > I'm changing the code so that if the submission is not marked with
> > Content-Type application/x-www-form-urlencoded, you will have  
> access to the
> > post body.
> >
> > Give me 40 minutes to commit the change up.
> >
> > Thanks,
> >
> > David


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

[Lift] Build problems...

[Marc Boschma]

I just removed my maven repository in ~/.m2 , "git clone git:// 
github.com/dpp/liftweb.git"

and

Mac:liftweb marc$ mvn -e -U clean install
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Lift
[INFO]   Lift Utils
[INFO]   Lift WebKit
[INFO]   Lift Mapper
[INFO]   Lift Machine
[INFO]   Lift Record
[INFO]   Lift Textile
[INFO]   Lift Facebook
[INFO]   Lift AMQP
[INFO]   Lift XMPP
[INFO]   Lift Widgets
[INFO]   Lift OpenID
[INFO]   Lift OAuth
[INFO]   Lift PayPal
[INFO]   Lift TestKit
[INFO]   Lift Core (full lift)
[INFO]   Lift Sites
[INFO]   Lift Example
[INFO]   Skittr Example
[INFO]   HelloLift example application
[INFO]   HelloDarwin tutorial application
[INFO]   JPA Demo Master
[INFO]   JPADemo-spa
[INFO]   JPADemo-web
[INFO]   HTTP Authentication example
[INFO]   lift-archetype-blank
[INFO]   lift-archetype-basic
WAGON_VERSION: 1.0-beta-2
[INFO]  

[INFO] Building Lift
[INFO]task-segment: [clean, install]
[INFO]  

[INFO] artifact org.scala-tools:maven-scala-plugin: checking for  
updates from scala-tools.org
[INFO] artifact org.scala-tools:maven-scala-plugin: checking for  
updates from central
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:  
checking for updates from scala-tools.org
[INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin:  
checking for updates from central
[INFO] [clean:clean]
[INFO] Deleting directory /Users/marc/src/lift/liftweb/target
[INFO] [scala:compile {execution: default}]
[WARNING] you don't define org.scala-lang:scala-library as a  
dependency of the project
[ERROR] /Users/marc/src/lift/liftweb/src/main/scala
[WARNING] No source files found.
[INFO] [scala:testCompile {execution: default}]
[WARNING] you don't define org.scala-lang:scala-library as a  
dependency of the project
[ERROR] /Users/marc/src/lift/liftweb/src/test/scala
[ERROR] /Users/marc/src/lift/liftweb/src/test/scala/../scala
[WARNING] No source files found.
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive  
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] [install:install]
[INFO] Installing /Users/marc/src/lift/liftweb/pom.xml to /Users/ 
marc/.m2/repository/net/liftweb/lift/0.11-SNAPSHOT/lift-0.11- 
SNAPSHOT.pom
[INFO]  

[INFO] Building Lift Utils
[INFO]task-segment: [clean, install]
[INFO]  

[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin: checking for  
updates from scala-tools.org
[INFO] artifact net.sf.alchim:yuicompressor-maven-plugin: checking for  
updates from central
[INFO] [clean:clean]
[INFO] Deleting directory /Users/marc/src/lift/liftweb/lift-util/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] nb warnings: 0, nb errors: 0
[INFO] snapshot org.specs:specs:1.4.3-SNAPSHOT: checking for updates  
from scala-tools.org
[INFO] snapshot org.specs:specs:1.4.3-SNAPSHOT: checking for updates  
from scala-tools.org.snapshots
[INFO] artifact org.mortbay.jetty:jetty: checking for updates from  
scala-tools.org
[INFO] artifact org.mortbay.jetty:jetty: checking for updates from  
scala-tools.org.snapshots
[INFO] artifact org.mortbay.jetty:jetty: checking for updates from  
central
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [scala:compile {execution: default}]
[INFO] suggestion: remove the scalaVersion from pom.xml
[ERROR] /Users/marc/src/lift/liftweb/lift-util/src/main/scala
[INFO] Compiling 32 source files to /Users/marc/src/lift/liftweb/lift- 
util/target/classes
[INFO]  

[ERROR] BUILD FAILURE
[INFO]  

[INFO] command line returned non-zero value:139
[INFO]  

[INFO] Trace
org.apache.maven.BuildFailureException: command line returned non-zero  
value:139
at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 
579)
at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecuto

[Lift] Re: ** breaking change **

[Marc Boschma]

Would the same key appear if there where resource bundles for  
different variations of the same language. eg. 'en-AU', 'en-US', 'en- 
ZA', and 'en' ?

Marc

On 26/01/2009, at 4:46 AM, Marius wrote:

> If you have the same key in different files the first one found will
> be returned. Nevertheless having the same key in different files
> doesn't make much sense.
>
> If you're running into any issues please let me know.
>
> Thoughts, questions?
>
> Br's,
> Marius
> >


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

[Marc Boschma]

Not from me... can the period be configurable or turned off it  
desired? eg. the server could ask the client to back off if needed?

Do I read between the lines the heartbeat could be independent of  
comet? if so how would it work?

Marc
On 22/01/2009, at 10:52 AM, David Pollak wrote:

> Folks,
>
> I've been working on some state related stuff in Lift.  It would be  
> very helpful to have a heartbeat that goes from the browser to the  
> server every 30 seconds or so.  If you've got a Comet component on  
> the page, the heartbeat will be part of the comet request.
>
> The benefits to this kind of mechanism includes never having an idle  
> session time out.
>
> Any objections?
>
> 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: demo.liftweb.net gone? bad news from Google...

[Marc Boschma]

Ok. To clarify it is an after hours project.

I vaguely remember a thread on the list in the distant past about a  
merged parser... might look into that.

The main problem is I started with the perl version and started to  
translate that. In hindsight I might stop and attack the Textile  
parser in Lift...

I'll take it you would rather a sane implementation rather than a  
fully output compatible version?

I have been thinking of allowing the mapping to XML to be customised  
(eg say use  instead of ). That would allow you to  
massage the result to your hearts content - eg. add class based on  
href as per your example.

No promises, but will put a few other projects on hold and bring this  
up to the fore.

Marc

On 19/01/2009, at 5:46 PM, Charles F. Munat wrote:

>
> Haven't decided to yet. Just checking it out.
>
> I don't like the use of things like
>
> h1. Heading
>
> to indicate heading levels in Textile. Too much like html (why not use
> html?). In Markdown, it's simpler:
>
> # Heading 1
> ## Heading 2
>
> etc.
>
> But there are things that Textile does that Markdown does not, such as
> simple tables. (At least, I'm not aware of Markdown doing these.) Or
> adding a class name to a link (which would allow me to differentiate
> easily between on-site and off-site links). Textile appears to cover
> more bases.
>
> That said, a big part of the problem is that I'm using MarkdownJ and  
> it
> was never really fully implemented, so it has bugs. For example, say I
> wanted to do bold italic. I'd probably just nest them:
>
> ***bold italic***
>
> But this doesn't work. I get bold italic,
> which is not nested properly and crashes the XML parser. (Weirdly, in
> the standard Textile parser online, if you do this:
>
> _*bold italic*_
>
> you get this:
>
> *bold italic
>
> but if you do this:
>
> *_bold italic_*
>
> you get this:
>
> bold italic
>
> Strange, eh?)
>
> I'd thought about implementing Markdown in Scala myself, but I'd  
> have to
> clone myself to do it, or hire someone to do all my other work. If you
> get Markdown working and usable in Lift (and soon), I'd love to use  
> it.
> But I have an important site due in the next month or so, and I need
> whatever I use to just work.
>
> (That said, I've got some older sites I want to convert over and they
> use Markdown, so I'd like to stick with it there no matter what.)
>
> Keep me posted, please. And if you need testing, let me know.
>
> Does this help?
>
> Chas.
>
> Marc Boschma wrote:
>> Hey Chas, why the move from Markdown to Textile? (in the midst of
>> implementing Markdown parser in scala...)
>>
>> Marc
>>
>> On 19/01/2009, at 11:57 AM, Charles F. Munat wrote:
>>
>>> I was trying to find something on the wiki about Textile as I'm
>>> considering changing over from Markdown. I used Google to search  
>>> thus:
>>>
>>> site:liftweb.net textile
>>>
>>> And I got a list of hits back: a couple from home.liftweb.net and  
>>> the
>>> rest from demo.liftweb.net.
>>>
>>> When I went to the "home" pages, I got this:
>>>
>>> Not Found
>>>
>>> The requested URL /lift/wiki/HomePage/edit;jsessionid=kbu9tvq3yysu  
>>> was
>>> not found on this server.
>>>
>>> But when I went to the "demo" pages, I got this:
>>>
>>> 502 Bad Gateway
>>> nginx/0.6.32
>>>
>>> Not one single link on the first page of results went to a working
>>> page.
>>> One would think that Lift was out of business.
>>>
>>> Any ideas as to why this is happening? What can we do to fix it?
>>>
>>> Chas.
>>>
>>
>>
>>
>>>
>
> >


--~--~-~--~~~---~--~~
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] demo.liftweb.net gone? bad news from Google...

[Marc Boschma]

Hey Chas, why the move from Markdown to Textile? (in the midst of  
implementing Markdown parser in scala...)

Marc

On 19/01/2009, at 11:57 AM, Charles F. Munat wrote:

>
> I was trying to find something on the wiki about Textile as I'm
> considering changing over from Markdown. I used Google to search thus:
>
> site:liftweb.net textile
>
> And I got a list of hits back: a couple from home.liftweb.net and the
> rest from demo.liftweb.net.
>
> When I went to the "home" pages, I got this:
>
> Not Found
>
> The requested URL /lift/wiki/HomePage/edit;jsessionid=kbu9tvq3yysu was
> not found on this server.
>
> But when I went to the "demo" pages, I got this:
>
> 502 Bad Gateway
> nginx/0.6.32
>
> Not one single link on the first page of results went to a working  
> page.
> One would think that Lift was out of business.
>
> Any ideas as to why this is happening? What can we do to fix it?
>
> Chas.
>
> >



--~--~-~--~~~---~--~~
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: Suggested change to HeadHelpers.scala

[Marc Boschma]

That is cool.

Marc

On 17/01/2009, at 10:42 AM, David Pollak wrote:

> Marc,
>
> There's a 90% chance that HeadHelpers will be removed from the  
> render pipeline for Lift 1.0
>
> There are a number of re-write phases for the XHTML page that I'm  
> going to condense into one for performance reasons.
>
> I'll keep in mind the requirement for only 1  tag per head  
> and I'll likely hardcode that rule.
>
> Thanks,
>
> Davod
>
> On Fri, Jan 16, 2009 at 2:57 PM, Marc Boschma  +lift...@boschma.cx> wrote:
> I have been playing with templates and noticed that it is possible to
> accumulate multiple  tags in the  tag, which isn't
> compliant to XHTML. Here is a suggested patch which merges the   > tags space separating them...
>
> That should allow templates to progressively add to the title. I had
> considered initially just picking the first, but that may not be the
> correct one...
>
> Regards,
>
> Marc
>
>
>
>
> *** HeadHelper.scala.orig   2009-01-16 08:33:01.0 +1100
> --- HeadHelper.scala2009-01-17 09:45:54.0 +1100
> ***
> *** 25,30 
> --- 25,61 
>def identity(xml: NodeSeq) : NodeSeq = xml
>
>def mergeToHtmlHead(xhtml: NodeSeq) : NodeSeq = {
> + def ret(xhtml: NodeSeq): NodeSeq =  
> insertTitle(removeTitle(xhtml), mergeTitle(xhtml))
> +
> + // There should only be one  tag in a xhtml 
> + def mergeTitle(in: NodeSeq): NodeSeq =
> +   {(for (title <- in \ "head" \ "title") yield  
> title.text).mkString(" ")}
> +
> + def removeTitle(in: NodeSeq): NodeSeq = in flatMap {
> +   case e: Elem if e.label == "title" =>
> +   NodeSeq.Empty
> +   case e: Elem =>
> + Elem(e.prefix, e.label, e.attributes, e.scope,  
> removeTitle(e.child) :_*)
> +   case Group(g) =>
> + Group(removeTitle(g))
> +   case x => x
> + }
> +
> + def insertTitle(in: NodeSeq, title: NodeSeq): NodeSeq = {
> +   def insertInHEAD(in: NodeSeq): NodeSeq = in flatMap {
> + case e: Elem if e.label == "head" =>
> +   Elem(e.prefix, e.label, e.attributes, e.scope, title ++  
> e.child :_*)
> + case x => x
> +   }
> +   def insertAfterHTML(in: NodeSeq): NodeSeq = in flatMap {
> + case e: Elem if e.label == "html" =>
> +   Elem(e.prefix, e.label, e.attributes, e.scope,  
> insertInHEAD(e.child): _*)
> + case x => x
> +   }
> +   insertAfterHTML(in)
> + }
> +
> +
>  def trimText(in: NodeSeq): NodeSeq = in flatMap {
>case e: Elem =>
>  Elem(e.prefix, e.label, e.attributes, e.scope,  
> trimText(e.child) :_*)
> ***
> *** 45,51 
>head <- body \\ "head") yield trimText(head.child)).
>  toList.removeDuplicates.flatMap(a => a)
>
> ! if (headInBody.isEmpty) xhtml
>  else {
>def xform(in: NodeSeq, inBody: Boolean): NodeSeq = in flatMap {
>  case e: Elem if !inBody && e.label == "body" =>
> --- 76,82 
>head <- body \\ "head") yield trimText(head.child)).
>  toList.removeDuplicates.flatMap(a => a)
>
> ! if (headInBody.isEmpty) ret(xhtml)
>  else {
>def xform(in: NodeSeq, inBody: Boolean): NodeSeq = in flatMap {
>  case e: Elem if !inBody && e.label == "body" =>
> ***
> *** 66,75 
>  case x => x
>}
>
> !   xform(xhtml, false)
>  }
>}
>
> -
>  }
>
> --- 97,105 
>  case x => x
>}
>
> !   ret(xform(xhtml, false))
>  }
>}
>
>  }
>
>
>
>
> 
> *** HeadHelper.scala.orig   2009-01-16 08:33:01.0 +1100
> --- HeadHelper.scala2009-01-17 09:45:54.0 +1100
> ***
> *** 25,30 
> --- 25,61 
> def identity(xml: NodeSeq) : NodeSeq = xml
>
> def mergeToHtmlHead(xhtml: NodeSeq) : NodeSeq = {
> + def ret(xhtml: NodeSeq): NodeSeq =
> insertTitle(removeTitle(xhtml), mergeTitle(xhtml))
> +
> + // There should only be one  tag in a xhtml 
> + def mergeTitle(in: NodeSeq): NodeSeq =
> +   {(for (title <- in \ "head" \ "title") yield
> title.text).mkString(" ")}
> +
> + def removeTitle(in: NodeSeq): NodeSeq = in flatMap {
> +   case e: Elem if e.label == "title" =>
> +   NodeSeq.Empty
> +   case e: Elem =>
> + 

[Lift] Suggested change to HeadHelpers.scala

[Marc Boschma]

I have been playing with templates and noticed that it is possible to  
accumulate multiple  tags in the  tag, which isn't  
compliant to XHTML. Here is a suggested patch which merges the  tags space separating them...

That should allow templates to progressively add to the title. I had  
considered initially just picking the first, but that may not be the  
correct one...

Regards,

Marc


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

*** HeadHelper.scala.orig   2009-01-16 08:33:01.0 +1100
--- HeadHelper.scala2009-01-17 09:45:54.0 +1100
***
*** 25,30 
--- 25,61 
def identity(xml: NodeSeq) : NodeSeq = xml
  
def mergeToHtmlHead(xhtml: NodeSeq) : NodeSeq = {
+ def ret(xhtml: NodeSeq): NodeSeq = insertTitle(removeTitle(xhtml), 
mergeTitle(xhtml))
+ 
+ // There should only be one  tag in a xhtml 
+ def mergeTitle(in: NodeSeq): NodeSeq =
+   {(for (title <- in \ "head" \ "title") yield 
title.text).mkString(" ")}
+   
+ def removeTitle(in: NodeSeq): NodeSeq = in flatMap {
+   case e: Elem if e.label == "title" =>
+   NodeSeq.Empty
+   case e: Elem =>
+ Elem(e.prefix, e.label, e.attributes, e.scope, removeTitle(e.child) 
:_*) 
+   case Group(g) =>
+ Group(removeTitle(g))
+   case x => x
+ }
+   
+ def insertTitle(in: NodeSeq, title: NodeSeq): NodeSeq = {
+   def insertInHEAD(in: NodeSeq): NodeSeq = in flatMap {
+ case e: Elem if e.label == "head" =>
+   Elem(e.prefix, e.label, e.attributes, e.scope, title ++ e.child :_*)
+ case x => x
+   }
+   def insertAfterHTML(in: NodeSeq): NodeSeq = in flatMap {
+ case e: Elem if e.label == "html" =>
+   Elem(e.prefix, e.label, e.attributes, e.scope, 
insertInHEAD(e.child): _*)
+ case x => x
+   }
+   insertAfterHTML(in)
+ }
+   
+ 
  def trimText(in: NodeSeq): NodeSeq = in flatMap {
case e: Elem =>
  Elem(e.prefix, e.label, e.attributes, e.scope, trimText(e.child) :_*)
***
*** 45,51 
head <- body \\ "head") yield trimText(head.child)).
  toList.removeDuplicates.flatMap(a => a)
  
! if (headInBody.isEmpty) xhtml
  else {
def xform(in: NodeSeq, inBody: Boolean): NodeSeq = in flatMap {
  case e: Elem if !inBody && e.label == "body" =>
--- 76,82 
head <- body \\ "head") yield trimText(head.child)).
  toList.removeDuplicates.flatMap(a => a)
  
! if (headInBody.isEmpty) ret(xhtml)
  else {
def xform(in: NodeSeq, inBody: Boolean): NodeSeq = in flatMap {
  case e: Elem if !inBody && e.label == "body" =>
***
*** 66,75 
  case x => x
}
  
!   xform(xhtml, false)
  }
}
  
- 
  }
  
--- 97,105 
  case x => x
}
  
!   ret(xform(xhtml, false))
  }
}
  
  }
  



*** HeadHelper.scala.orig   2009-01-16 08:33:01.0 +1100
--- HeadHelper.scala2009-01-17 09:45:54.0 +1100
***
*** 25,30 
--- 25,61 
 def identity(xml: NodeSeq) : NodeSeq = xml

 def mergeToHtmlHead(xhtml: NodeSeq) : NodeSeq = {
+ def ret(xhtml: NodeSeq): NodeSeq =  
insertTitle(removeTitle(xhtml), mergeTitle(xhtml))
+
+ // There should only be one  tag in a xhtml 
+ def mergeTitle(in: NodeSeq): NodeSeq =
+   {(for (title <- in \ "head" \ "title") yield  
title.text).mkString(" ")}
+
+ def removeTitle(in: NodeSeq): NodeSeq = in flatMap {
+   case e: Elem if e.label == "title" =>
+   NodeSeq.Empty
+   case e: Elem =>
+ Elem(e.prefix, e.label, e.attributes, e.scope,  
removeTitle(e.child) :_*)
+   case Group(g) =>
+ Group(removeTitle(g))
+   case x => x
+ }
+
+ def insertTitle(in: NodeSeq, title: NodeSeq): NodeSeq = {
+   def insertInHEAD(in: NodeSeq): NodeSeq = in flatMap {
+ case e: Elem if e.label == "head" =>
+   Elem(e.prefix, e.label, e.attributes, e.scope, title ++  
e.child :_*)
+ case x => x
+   }
+   def insertAfterHTML(in: NodeSeq): NodeSeq = in flatMap {
+ case e: Elem if e.label == "html" =>
+   Elem(e.prefix, e.label, e.attributes, e.scope,  
insertInHEAD(e.child): _*)
+ case x => x
+   }
+   insertAfterHTML(in)
+ }
+
+
   def trimText(in: NodeSeq): NodeSeq = in flatMap {
 case e: Elem =>
   Elem(e.prefix, e.label, e.attributes, e.scope,  
trimText(e.child) :_*)
***
*** 45,51 
 head <- body \\ "h

[Lift] Re: Writing data to the HttpServletResponse

[Marc Boschma]

I'm not an expert but I would model a Response class in much the same  
way as:

   package net.liftweb.http

   object PlainTextResponse {
 def apply(text: String): PlainTextResponse =  
PlainTextResponse(text, Nil, 200)
 def apply(text: String, code: Int): PlainTextResponse =  
PlainTextResponse(text, Nil, code)
   }

   case class PlainTextResponse(text: String, headers: List[(String,  
String)], code: Int) extends LiftResponse {
 def toResponse = {
   val bytes = text.getBytes("UTF-8")
   InMemoryResponse(bytes, ("Content-Length",  
bytes.length.toString) :: ("Content-Type", "text/plain") :: headers,  
Nil, code)
 }
   }

from TextResponse.scala. Look at InMemoryResponse or possibly  
StreamingResponse in Response.scala.

Marc



On 11/01/2009, at 4:27 AM, Alli wrote:

>
> Hey, I have been searching the list and also the liftweb.net wiki and
> haven't found a way to do this:
>
> I have a form to upload a file that I want to manipulate and send back
> to the client. When sending it back I am using S.setHeader to set the
> content type, disposition etc but I haven't found a way to write the
> file back to the response. What I think I need is access to the
> response's printwriter (response.getWriter()) instance. Any help would
> be greatly appreciated.
>
> Cheers,
> Alli
>
> >


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

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

[Marc Boschma]

S.attr("someparam") still returns a Box[String]. However I added 2
> helper function ~ that would return Option[NodeSeq], so you can call
> S.attr ~("someparam") and get back an Option[NodeSeq].
>
> I know we could have used implicits to convert from Box[String] to
> Option[NodeSeq] but I feel that this would be an abuse of implicits as
> the use of implicits IMHO should be motivated byt strong design
> rationales and I think this is the case.
>
> Thoughts?
>
> Very cool!
>
>
>
> Br's,
> Marius
>
> On Jan 7, 7:40 pm, Marius  wrote:
> > I'll look into it.
> >
> > On Jan 7, 7:38 pm, "David Pollak" 
> > wrote:
> >
> > > Marc,
> >
> > > Good suggestion.  Marius -- do you want to do this... maybe even  
> turn the
> > > pattern into a trait that we can apply over and over?
> >
> > > Thanks,
> >
> > > David
> >
> > > On Tue, Jan 6, 2009 at 9:57 PM, Marc Boschma
> > > 
> >
> > > > wrote:
> > > > Cool code! Works nicely...
> > > > Would it make sense to also add something similar to this from  
> S.attr ?
> >
> > > >   def apply[T](what: String, f: String => T, default: => T): T
> > > > = apply(what).map(f) openOr default
> >
> > > > ie maybe:
> >
> > > >   def apply[T](prefix: String, key: String, f: String => T):  
> Option[T]
> > > > = apply(prefix, key).map(f)
> > > >   def apply[T](key: String, f: String => T): Option[T] =  
> apply(key).map(f)
> >
> > > > to BindHelpers.attr ?
> >
> > > > Thinking about it should the applys of the two attr objects be  
> aligned
> > > > (Option verses Box, etc) ? It would make the crafting of  
> snippets and bind
> > > > functions in terms of access to attributes the same, dropping  
> a potential
> > > > barrier to learning lift...
> >
> > > > ie Maybe BindHelpers.attr should have applys with the following
> > > > signatures...
> >
> > > > def apply(key: String): Box[String]
> > > > def apply(prefix: String,  key: String): Box[String]
> >
> > > > def apply(key: String, default: => String): String
> > > > def apply(prefix: String, key: String, default: =>  
> String): String
> >
> > > > def apply[T](key: String, f: String => T, default: => T): T
> > > > def apply[T](prefix: String, key: String, f: String => T,  
> default: =>
> > > > T): T
> >
> > > > Lastly, and maybe I am missing something here, but I take it  
> for a snippet
> > > > a prefixed attribute isn't accessible via S.attr ???
> >
> > > > Regards,
> >
> > > > Marc
> >
> > > > On 07/01/2009, at 6:54 AM, David Pollak wrote:
> >
> > > > On Tue, Jan 6, 2009 at 11:16 AM, Marius  
>  wrote:
> >
> > > >> Ok ... i just committed some changes:
> >
> > > >> 1. Renamed curAttr to attr
> > > >> 2. The BindHelpers vals are now private but we expose two  
> functions
> > > >> currentNode and bindNodes
> >
> > > > Cool beans!
> >
> > > >> Br's,
> > > >> Marius
> >
> > > >> On Jan 6, 8:37 pm, "David Pollak"  
> 
> > > >> wrote:
> > > >> > On Tue, Jan 6, 2009 at 10:28 AM, Marius  
> 
> > > >> wrote:
> >
> > > >> > > On Jan 6, 7:15 pm, "David Pollak"  
> 
> > > >> > > wrote:
> > > >> > > > I also added
> > > >> > > > BindHelpers.attr("tag"): Option[NodeSeq]
> > > >> > > > so you can do something like:
> >
> > > >> > > > ...
> >
> > > >> > > > and:
> > > >> > > > BindHelpers.attr("prefix", "tag")
> >
> > > >> > > I think it is committed to curAttr which personally I'm  
> not a fan ...
> > > >> > > Doyou mind if I change it to attr or nodeAttr ?
> >
> > > >> > Go for it.
> >
> > > >> > > > Thanks,
> >
> > > >> > > > David
> >
> > > >> > > > On Tue, Jan 6, 2009 at 9:13 AM, Marius  
> 
> > > >> wrote:
> >
> > > >> > > > > Very c

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

[Marc Boschma]

Cool code! Works nicely...

Would it make sense to also add something similar to this from S.attr ?

   def apply[T](what: String, f: String => T, default: => T): T =  
apply(what).map(f) openOr default

ie maybe:

   def apply[T](prefix: String, key: String, f: String => T):  
Option[T] = apply(prefix, key).map(f)
   def apply[T](key: String, f: String => T): Option[T] =  
apply(key).map(f)

to BindHelpers.attr ?

Thinking about it should the applys of the two attr objects be aligned  
(Option verses Box, etc) ? It would make the crafting of snippets and  
bind functions in terms of access to attributes the same, dropping a  
potential barrier to learning lift...

ie Maybe BindHelpers.attr should have applys with the following  
signatures...

 def apply(key: String): Box[String]
 def apply(prefix: String,  key: String): Box[String]

 def apply(key: String, default: => String): String
 def apply(prefix: String, key: String, default: => String): String

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

Lastly, and maybe I am missing something here, but I take it for a  
snippet a prefixed attribute isn't accessible via S.attr ???

Regards,

Marc



On 07/01/2009, at 6:54 AM, David Pollak wrote:

>
>
> On Tue, Jan 6, 2009 at 11:16 AM, Marius   
> wrote:
>
> Ok ... i just committed some changes:
>
> 1. Renamed curAttr to attr
> 2. The BindHelpers vals are now private but we expose two functions
> currentNode and bindNodes
>
> Cool beans!
>
>
>
> Br's,
> Marius
>
> On Jan 6, 8:37 pm, "David Pollak" 
> wrote:
> > On Tue, Jan 6, 2009 at 10:28 AM, Marius   
> wrote:
> >
> > > On Jan 6, 7:15 pm, "David Pollak" 
> > > wrote:
> > > > I also added
> > > > BindHelpers.attr("tag"): Option[NodeSeq]
> > > > so you can do something like:
> >
> > > > ...
> >
> > > > and:
> > > > BindHelpers.attr("prefix", "tag")
> >
> > > I think it is committed to curAttr which personally I'm not a  
> fan ...
> > > Doyou mind if I change it to attr or nodeAttr ?
> >
> > Go for it.
> >
> >
> >
> > > > Thanks,
> >
> > > > David
> >
> > > > On Tue, Jan 6, 2009 at 9:13 AM, Marius  
>  wrote:
> >
> > > > > Very cool Dave !
> >
> > > > > thx,
> > > > > Marius
> >
> > > > > On Jan 6, 4:36 pm, "David Pollak"  
> 
> > > > > wrote:
> > > > > > Folks,
> >
> > > > > > I'm about to commit up a non-breaking solution.
> >
> > > > > > In bind, you can call:
> > > > > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > > > > BindHelpers.currentNode.value: Elem
> >
> > > > > > bindNodes is a list of the nodes that were passed into  
> bind with the
> > > more
> > > > > > current node at the head of the list.  If you're doing  
> hierarchical
> > > > > binding,
> > > > > > you can see all the nodes that were passed into bind this  
> was.
> >
> > > > > > currentNode is available to the BindParam and it contains  
> the parent
> > > Elem
> > > > > to
> > > > > > the NodeSeq that was passed into your BindParam.  You can  
> inspect
> > > > > attributes
> > > > > > to your heart's content.
> >
> > > > > > Give it an hour or two for these changes to make their way  
> through
> > > > > Hudson.
> >
> > > > > > Thanks,
> >
> > > > > > David
> >
> > > > > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > > > >  <
> > > marc%2blift...@boschma.cx ><
> > > > > marc%2blift...@boschma.cx  <
> > > marc%252blift...@boschma.cx >>
> >
> > > > > > > wrote:
> >
> > > > > > > I've just had a thought as to how to make it not a  
> breaking change.
> >
> > > > > > > Leave your change "calcValue(s.child) I just call  
> calcValue(s)"
> >
> > > > > > > change:
> > > > > > >   case class FuncBindParam(name: String, value: NodeSeq  
> => NodeSeq)
> > > > > > > extends Tuple2(name, value) with BindParam {
> > > > &

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

[Marc Boschma]

I've just had a thought as to how to make it not a breaking change.

Leave your change "calcValue(s.child) I just call calcValue(s)"

change:
   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in)
   }

to:
   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.child)
   }

That should prevent old code breaking... which would be a good  
thing(tm) given the amount of code that uses bind(...)

then create something like:

   case class FuncMetaDataBindParam(name: String, value: (MetaData,  
NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,  
in.child)
   }

along with adding to class SuperArrowAssoc...
   def ->(in: (MetaData, NodeSeq) => NodeSeq) =  
FuncMetaDataBindParam(name, in)

That would be fairly clean...

-

Maybe for those that actually want the full node add:

   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>  
NodeSeq) extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
   }

and you could go nuts and:

   case class FuncPrefixAndLabelBindParam(name: String, value:  
(String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with  
BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,  
in.child)
   }

etc...


On 06/01/2009, at 10:51 PM, Marc Boschma wrote:

>
> (you can tel I'm sleeping well :/ - too hot)
>
> The toList function is one of David's (todo example app). I do love
> the ability to curry :)
>
> Marc
> On 06/01/2009, at 9:51 PM, Marius wrote:
>
>>
>>
>>
>> On Jan 6, 12:47 pm, Marc Boschma  wrote:
>>> A quick just before going to bed reaction is that your change would
>>> solve the issue.
>>
>> Yeah it would ... (I mean it worked fine in my tests)
>>
>>>
>>> It is interesting you focused on the "exclude" and not the
>>> "list" (which is what I have been playing with). I actually missed  
>>> it
>>> was a similar case...
>>
>> I just picked it randomly :) ... I've seen that you're using a
>> partially applied function doList ... (which I assume it is a curried
>> function):)
>>
>>>
>>> Regards,
>>>
>>> Marc
>>>
>>> On 06/01/2009, at 9:24 PM, Marius wrote:
>>>
>>>
>>>
>>>> I just did a minor modification to the lift code so the actual
>>>> node it
>>>> is passed to the BindParam and not its child. Now having:
>>>
>>>> bind("todo", html,
>>>>"exclude" ->  {node:NodeSeq =>ajaxCheckbox
>>>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>>> ... )
>>>
>>>> and the markup 
>>>
>>>> The node parameter to the anonymous function will be the
>>>>  node and not its children. So now you can access the
>>>> "param" attribute from node. The change was in in_bind function so
>>>> instead of calling calcValue(s.child) I just call calcValue(s)
>>>
>>>> Looking at the existent BindParams this change does not seem to
>>>> cause
>>>> side effects since the calcValue 'in' parameter is used only for
>>>> FuncXXXBindParam-s. The impact is that the user's function would  
>>>> now
>>>> get the actual node (from which now he can extract attributes) and
>>>> not
>>>> the child nodes. But child nodes from the actual node are trivial  
>>>> to
>>>> obtain.
>>>
>>>> I did not commit this change as I'd like to see other opinions to
>>>> see
>>>> if there is something that I missed somehow. If we get general
>>>> consensus of this change I can commit it right away and announce
>>>> it as
>>>> a "breaking change".
>>>
>>>> Thoughts?
>>>
>>>> Br's,
>>>> Marius
>>>
>>>> On Jan 6, 12:02 pm, Marius  wrote:
>>>>> A nice alternative would have been :
>>>
>>>>> bind("todo", html,
>>>>> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>>>>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>>>>  ... )
>>>
>>>>> Bu

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

[Marc Boschma]

(you can tel I'm sleeping well :/ - too hot)

The toList function is one of David's (todo example app). I do love  
the ability to curry :)

Marc
On 06/01/2009, at 9:51 PM, Marius wrote:

>
>
>
> On Jan 6, 12:47 pm, Marc Boschma  wrote:
>> A quick just before going to bed reaction is that your change would
>> solve the issue.
>
> Yeah it would ... (I mean it worked fine in my tests)
>
>>
>> It is interesting you focused on the "exclude" and not the
>> "list" (which is what I have been playing with). I actually missed it
>> was a similar case...
>
> I just picked it randomly :) ... I've seen that you're using a
> partially applied function doList ... (which I assume it is a curried
> function):)
>
>>
>> Regards,
>>
>> Marc
>>
>> On 06/01/2009, at 9:24 PM, Marius wrote:
>>
>>
>>
>>> I just did a minor modification to the lift code so the actual  
>>> node it
>>> is passed to the BindParam and not its child. Now having:
>>
>>> bind("todo", html,
>>> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>>  ... )
>>
>>> and the markup 
>>
>>> The node parameter to the anonymous function will be the
>>>  node and not its children. So now you can access the
>>> "param" attribute from node. The change was in in_bind function so
>>> instead of calling calcValue(s.child) I just call calcValue(s)
>>
>>> Looking at the existent BindParams this change does not seem to  
>>> cause
>>> side effects since the calcValue 'in' parameter is used only for
>>> FuncXXXBindParam-s. The impact is that the user's function would now
>>> get the actual node (from which now he can extract attributes) and  
>>> not
>>> the child nodes. But child nodes from the actual node are trivial to
>>> obtain.
>>
>>> I did not commit this change as I'd like to see other opinions to  
>>> see
>>> if there is something that I missed somehow. If we get general
>>> consensus of this change I can commit it right away and announce  
>>> it as
>>> a "breaking change".
>>
>>> Thoughts?
>>
>>> Br's,
>>> Marius
>>
>>> On Jan 6, 12:02 pm, Marius  wrote:
>>>> A nice alternative would have been :
>>
>>>>  bind("todo", html,
>>>>      "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>>>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>>>   ... )
>>
>>>> But here the node impersonates the childNodes not the original  
>>>> node.
>>>> So you still can not access the param attribute below
>>
>>>> 
>>
>>>> but you can do it like:
>>
>>>> 
>>
>>>> and you have full access to the meta node as it is a child of
>>>> todo:exclude. Hence you can pass state.
>>
>>>> I know, it is not ideal but should be workable until snippet child-
>>>> node attributes are exposed in one way or another.
>>
>>>> Br's,
>>>> Marius
>>
>>>> Marc Boschma wrote:
>>>>> I have been playing with the ToDo example application and having  
>>>>> fun
>>>>> in manipulating XML.
>>
>>>>> With the  node I thought it would be good if the XHTML
>>>>> designer could pass in some guidance to the doList(...) method
>>>>> used in
>>>>> bind(..). ie. ...
>>
>>>>> Looking over the bind code I noticed that the attributes are not
>>>>> accessible without ending up changing the calcValue method's
>>>>> signature. I did initially try to knock up a
>>
>>>>>case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
>>>>> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>>
>>>>> and a corresponding
>>
>>>>>case Some(ns : FuncWithAttrBindParam) =>
>>
>>>>> in in_bind(...), but it all looks like a huge kludge.
>>
>>>>> It strikes me as a little deficient to be able to utilise  
>>>>> attributes
>>>>> within the context of a snippet and yet not within a bind. I know
>>>>> bind
>>>>> is quite embedded in lift now, but I think

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

[Marc Boschma]

A quick just before going to bed reaction is that your change would  
solve the issue.

It is interesting you focused on the "exclude" and not the  
"list" (which is what I have been playing with). I actually missed it  
was a similar case...

Regards,

Marc

On 06/01/2009, at 9:24 PM, Marius wrote:

>
> I just did a minor modification to the lift code so the actual node it
> is passed to the BindParam and not its child. Now having:
>
> bind("todo", html,
> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>  ... )
>
> and the markup 
>
> The node parameter to the anonymous function will be the
>  node and not its children. So now you can access the
> "param" attribute from node. The change was in in_bind function so
> instead of calling calcValue(s.child) I just call calcValue(s)
>
> Looking at the existent BindParams this change does not seem to cause
> side effects since the calcValue 'in' parameter is used only for
> FuncXXXBindParam-s. The impact is that the user's function would now
> get the actual node (from which now he can extract attributes) and not
> the child nodes. But child nodes from the actual node are trivial to
> obtain.
>
> I did not commit this change as I'd like to see other opinions to see
> if there is something that I missed somehow. If we get general
> consensus of this change I can commit it right away and announce it as
> a "breaking change".
>
> Thoughts?
>
> Br's,
> Marius
>
>
>
> On Jan 6, 12:02 pm, Marius  wrote:
>> A nice alternative would have been :
>>
>>  bind("todo", html,
>>  "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>   ... )
>>
>> But here the node impersonates the childNodes not the original node.
>> So you still can not access the param attribute below
>>
>> 
>>
>> but you can do it like:
>>
>> 
>>
>> and you have full access to the meta node as it is a child of
>> todo:exclude. Hence you can pass state.
>>
>> I know, it is not ideal but should be workable until snippet child-
>> node attributes are exposed in one way or another.
>>
>> Br's,
>> Marius
>>
>> Marc Boschma wrote:
>>> I have been playing with the ToDo example application and having fun
>>> in manipulating XML.
>>
>>> With the  node I thought it would be good if the XHTML
>>> designer could pass in some guidance to the doList(...) method  
>>> used in
>>> bind(..). ie. ...
>>
>>> Looking over the bind code I noticed that the attributes are not
>>> accessible without ending up changing the calcValue method's
>>> signature. I did initially try to knock up a
>>
>>>case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
>>> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>>
>>> and a corresponding
>>
>>>case Some(ns : FuncWithAttrBindParam) =>
>>
>>> in in_bind(...), but it all looks like a huge kludge.
>>
>>> It strikes me as a little deficient to be able to utilise attributes
>>> within the context of a snippet and yet not within a bind. I know  
>>> bind
>>> is quite embedded in lift now, but I think that this difference  
>>> might
>>> prove a little frustrating. I know one solution is to just create a
>>> bind("todo", html,
>>>  "exclude" ->
>>> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
>>>  "list" -> doList(reDraw, false) _,
>>>"list_singular" -> doList(reDraw, true)  
>>> _)
>>
>>> But I think from the XHtml designer's perspective that is counter
>>> intuitive...
>>
>>> Thoughts?
>>
>>> --
>>
>>> It should be noted that this is different to the case class
>>> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
>>> String) extends BindParam with BindWithAttr. Which interesting  
>>> enough
>>> has no corresponding SuperArrowAssoc -> method match. Maybe
>>
>>>def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2,  
>>> t._1)
>>>def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
>>> FuncAttrBindParam(name, t._2, t._1)
>>
>>> And maybe even...
>>
>>>def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name  
>>> ->
>>> t._2).calcValue _, t._1)
>>
>>> or
>>
>>>def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1  
>>> ->
>>> t._2).calcValue _, t._1)
>>
>>> I'm not sure which is better on the last two... Just a thought.
>>
>>> Marc
> >


--~--~-~--~~~---~--~~
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] accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

I have been playing with the ToDo example application and having fun  
in manipulating XML.

With the  node I thought it would be good if the XHTML  
designer could pass in some guidance to the doList(...) method used in  
bind(..). ie. ...

Looking over the bind code I noticed that the attributes are not  
accessible without ending up changing the calcValue method's  
signature. I did initially try to knock up a

case class FuncWithAttrBindParam(name: String, value: (NodeSeq,  
MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam

and a corresponding

case Some(ns : FuncWithAttrBindParam) =>

in in_bind(...), but it all looks like a huge kludge.

It strikes me as a little deficient to be able to utilise attributes  
within the context of a snippet and yet not within a bind. I know bind  
is quite embedded in lift now, but I think that this difference might  
prove a little frustrating. I know one solution is to just create a  
bind("todo", html,
 "exclude" ->  
ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
 "list" -> doList(reDraw, false) _,
"list_singular" -> doList(reDraw, true) _)

But I think from the XHtml designer's perspective that is counter  
intuitive...

Thoughts?

--

It should be noted that this is different to the case class  
FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:  
String) extends BindParam with BindWithAttr. Which interesting enough  
has no corresponding SuperArrowAssoc -> method match. Maybe

def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2, t._1)
def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =  
FuncAttrBindParam(name, t._2, t._1)

And maybe even...

def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name ->  
t._2).calcValue _, t._1)

or

def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1 ->  
t._2).calcValue _, t._1)

I'm not sure which is better on the last two... Just a thought.

Marc


--~--~-~--~~~---~--~~
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: Can or Box or something else

[Marc Boschma]

Funny thing is the first thought that came to mind here was a Cricket  
Box :) (and not the KFC variety)

To close the season and thread with some humour:

I wanted to send some sort of Christmas (whoops I mean) holiday  
greeting to my friends, but it is so difficult in today's world to  
know exactly what to say without offending someone. So I met with my  
lawyer yesterday, and on his advice I wish to say the following to  
you, my dear friends throughout the world:

Please accept with no obligation, implied or implicit, my best wishes  
for an environmentally conscious, socially responsible, low stress,  
non-addictive, gender neutral celebration of the Summer solstice  
holiday, practised with the most enjoyable traditions of religious  
persuasion or secular practices of your choice with respect for the  
religious/secular persuasions and/or traditions of others, or their  
choice not to practice religious or secular traditions at all.

I also wish you a fiscally successful, personally fulfilling and  
medically uncomplicated recognition of the onset of the generally  
accepted calendar year 2009, but not without due respect for the  
calendars of choice of other cultures whose contributions to society  
have helped make our country great (not to imply that Australia is  
necessarily greater than any other country) and without regard to the  
race, creed, colour, age, physical ability, religious faith or sexual  
preference of the wishees.

By accepting this greeting, you are accepting these terms:

This greeting is subject to clarification or withdrawal. It is freely  
transferable with no alteration to the original greeting. It implies  
no promise by the wisher to actually implement any of the wishes for  
her/himself or others and is void where prohibited by law, and is  
revocable at the sole discretion of the wisher.

This wish is warranted to perform as expected within the usual  
application of good tidings for a period of one year or until the  
issuance of a subsequent holiday greeting, whichever comes first, and  
warranty is limited to replacement of this wish or issuance of a new  
wish at the sole discretion of the wisher.

Disclaimer: No trees were harmed in the sending of this message;  
however, a significant number of electrons were slightly inconvenienced.

On 27/12/2008, at 2:25 AM, Viktor Klang wrote:

> "Bin"
> "Slot"
> "Ref"
>
> Though, "Box" is short, self-explanatory and fills the other  
> criterias aswell.
>
> Merry Christmas
> /Viktor
>

--~--~-~--~~~---~--~~
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: Can or Box or something else

[Marc Boschma]

I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an  
alternative? That way Empty and Full still make sense...

Initially I thought 'Tin' sounded better but I recognise that term  
wouldn't be as universal.

Marc

On 26/12/2008, at 4:14 AM, Michael Campbell wrote:

>
> David Pollak wrote:
>> Folks,
>>
>> Over the year that Lift has had Can[T] as a replacement for Scala's
>> Option[T], the name "Can" has required a lot of explaining.
>
>
> I've never liked "Can" as a name; always thinking that the opposite  
> of one
> should be a "Can't".   I'm sure it's my own issue to solve, but it's
> cognitively dissonant to me.
>
> Any other container name works better for me, although of the ones  
> you listed,
> I like "Box".
>
>
> -- 
> Twitter:  http://twitter.com/campbellmichael
>
> >


--~--~-~--~~~---~--~~
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: todo_steps feedback

[Marc Boschma]

Not that I am aware of, but then I am in Australia and these days  
almost anything could be mucking about with my internet connectivity,  
but I digress...

I did however just tried going back to

mvn archetype:create -U \
 -DarchetypeGroupId=net.liftweb \
 -DarchetypeArtifactId=lift-archetype-basic \
 -DarchetypeVersion=0.10-SNAPSHOT \
 -DremoteRepositories=http://scala-tools.org/repo-snapshots \
 -DgroupId="com.smefinancialgroup" -DartifactId="homepage"


and got

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-archetype-plugin:  
checking for updates from central
[INFO]  

[INFO] Building Maven Default Project
[INFO]task-segment: [archetype:create] (aggregator-style)
[INFO]  

[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:create]
[WARNING] This goal is deprecated. Please use mvn archetype:generate  
instead
[INFO] Defaulting package to group ID: com.smefinancialgroup
[INFO] We are using command line specified remote repositories: 
http://scala-tools.org/repo-snapshots
[INFO] snapshot net.liftweb:lift-archetype-basic:0.10-SNAPSHOT:  
checking for updates from id0
[INFO]  

[INFO] Using following parameters for creating OldArchetype: lift- 
archetype-basic:0.10-SNAPSHOT
[INFO]  

[INFO] Parameter: groupId, Value: com.smefinancialgroup
[INFO] Parameter: packageName, Value: com.smefinancialgroup
[INFO] Parameter: basedir, Value: /Users/marc/src/dad
[INFO] Parameter: package, Value: com.smefinancialgroup
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: artifactId, Value: homepage
[INFO] * End of debug info from resources from  
generated POM ***
[INFO] OldArchetype created in dir: /Users/marc/src/dad/homepage
[INFO]  

[INFO] BUILD SUCCESSFUL
[INFO]  

[INFO] Total time: 6 seconds
[INFO] Finished at: Wed Dec 24 15:40:06 EST 2008
[INFO] Final Memory: 7M/14M
[INFO]  


"It lives!!!"

Strange how mvn archetype:generate didn't work...

On 24/12/2008, at 3:25 PM, David Pollak wrote:

> Are you behind some sort of proxy that has some old jars cached?
>
>
> On Dec 23, 2008 6:53 PM, "Marc Boschma"   
> wrote:
>
> Yep, checked that one...
>
> Pro:src marc$ mvn -version
> Maven version: 2.0.9 Java version: 1.5.0_16 OS name: "mac os x"  
> version: "10.5.6" arch: "i386" Fami...
>
> I also uninstalled the port and reinstalled it to make sure... same  
> result.
> On 24/12/2008, at 1:28 PM, David Pollak wrote: > Please make sure  
> you're running maven 2.0.9 > > ...
>
> You received this message because you are subscribed to the Google  
> Groups "Lift" group. To post to ...
>
>
>
>
> >


--~--~-~--~~~---~--~~
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: todo_steps feedback

[Marc Boschma]

Yep, checked that one...

Pro:src marc$ mvn -version
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix"

I also uninstalled the port and reinstalled it to make sure... same  
result.

On 24/12/2008, at 1:28 PM, David Pollak wrote:

> Please make sure you're running maven 2.0.9
>
>
> On Dec 23, 2008 6:09 PM, "Marc Boschma"   
> wrote:
>
> There is something seriously wrong with my Mac's set up... Google  
> time... as despite the reference to the right repository it ignores  
> that...
>
> Marc
> On 24/12/2008, at 10:04 AM, David Pollak wrote: > The line: >  
> > -DremoteRepositories=http...
>
> Pro:src marc$ mvn archetype:generate -U - 
> DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-archetype- 
> basic -DarchetypeVersion=0.10-SNAPSHOT 
> -DremoteRepositories=http://scala-tools.org/repo-snapshots 
>  -DgroupId=com.liftworkshop -DartifactId=todo
> [INFO] Scanning for projects... [INFO] Searching repository for  
> plugin with prefix: 'archetype'. [I...
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]  
>  
> [INFO 
> ] Total time: ...
>
> [INFO] Finished at: Wed Dec 24 13:02:08 EST 2008
> [INFO] Final Memory: 8M/15M
> [INFO]  
> 
>
> >


--~--~-~--~~~---~--~~
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: todo_steps feedback

[Marc Boschma]

There is something seriously wrong with my Mac's set up... Google  
time... as despite the reference to the right repository it ignores  
that...

Marc

On 24/12/2008, at 10:04 AM, David Pollak wrote:

> The line:
>
> -DremoteRepositories=http://scala-tools.org/repo-releases \
>
> Should be:
>
> -DremoteRepositories=http://scala-tools.org/repo-snapshots \
>
>

Pro:src marc$ mvn archetype:generate -U -DarchetypeGroupId=net.liftweb  
-DarchetypeArtifactId=lift-archetype-basic -DarchetypeVersion=0.10- 
SNAPSHOT -DremoteRepositories=http://scala-tools.org/repo-snapshots - 
DgroupId=com.liftworkshop -DartifactId=todo
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] org.apache.maven.plugins: checking for updates from central
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.apache.maven.plugins:maven-archetype-plugin:  
checking for updates from central
[INFO]  

[INFO] Building Maven Default Project
[INFO]task-segment: [archetype:generate] (aggregator-style)
[INFO]  

[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[INFO] Archetype repository missing. Using the one from  
[net.liftweb:lift-archetype-basic:RELEASE -> 
http://scala-tools.org/repo-releases 
] found in catalog internal
[INFO] snapshot net.liftweb:lift-archetype-basic:0.10-SNAPSHOT:  
checking for updates from lift-archetype-basic-repo
Downloading: 
http://scala-tools.org/repo-releases/net/liftweb/lift-archetype-basic/0.10-SNAPSHOT/lift-archetype-basic-0.10-SNAPSHOT.jar
[INFO]  

[ERROR] BUILD FAILURE
[INFO]  

[INFO] The desired archetype does not exist (net.liftweb:lift- 
archetype-basic:0.10-SNAPSHOT)
[INFO]  

[INFO] For more information, run Maven with the -e switch
[INFO]  

[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Dec 24 13:02:08 EST 2008
[INFO] Final Memory: 8M/15M
[INFO]  



--~--~-~--~~~---~--~~
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: todo_steps feedback

[Marc Boschma]

LAMP/EPFL

So it appears that maven can't find an archetypeVersion of 0.10- 
SNAPSHOT... Strange as I assume others can...

My maven version is:
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: "mac os x" version: "10.5.6" arch: "i386" Family: "unix"

Time for Breakie I think...

Marc

On 24/12/2008, at 9:18 AM, David Pollak wrote:
> Looks like you have a very old archetype that's refering to Scala  
> 2.7.1
>
>
> On Dec 23, 2008 2:15 PM, "Marc Boschma"   
> wrote:
>
> It refers to 0.10-SNAPSHOT. I added the
>
>   net.liftweb
>   lift-util
>   0.10-SNAPSHOT
> 
> 
>   net.liftweb
>   lift-webkit
>   0.10-SNAPSHOT
> 
> 
>   net.liftweb
>   lift-mapper
>   0.10-SNAPSHOT
> 
>
> after
>
> 
>   net.liftweb
>   lift-core
>   0.10-SNAPSHOT
> 
>
> In the pom.xml
>
> I also edited the Boot.scala file as per a pervious email where you  
> documented the impact of the changes.
>
> Something is still not quite there as I get the following error:
> HTTP ERROR: 500
> scala/actors/AbstractActor
> RequestURI=/
>
> Caused by:
> java.lang.NoClassDefFoundError: scala/actors/AbstractActor at  
> net.liftweb.http.LiftRules$.rewriteTable(LiftRules.scala:372) at  
> net.liftweb.http.LiftFilterTrait$$anonfun$doFilter 
> $1.apply(LiftServlet.scala:480) at net.liftweb.http.LiftFilterTrait$ 
> $anonfun$doFilter$1.apply(LiftServlet.scala:476) at  
> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply$4$ 
> $anonfun$apply$5.apply(Vars.scala:150) at  
> net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33) at  
> net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply 
> $4.apply(Vars.scala:149) at  
> net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33) at  
> net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply(Vars.scala: 
> 148) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33)  
> at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:147) at  
> net.liftweb.http.LiftFilterTrait$class.doFilter(LiftServlet.scala: 
> 475) at net.liftweb.http.LiftFilter.doFilter(LiftServlet.scala:496)  
> at org.mortbay.jetty.servlet.ServletHandler 
> $CachedChain.doFilter(ServletHandler.java:1115) at  
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 
> 361) at  
> org 
> .mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
> 216) at  
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 
> 181) at  
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 
> 766) at  
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java: 
> 417) at  
> org 
> .mortbay 
> .jetty 
> .handler 
> .ContextHandlerCollection.handle(ContextHandlerCollection.java:230)  
> at  
> org 
> .mortbay 
> .jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)  
> at  
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
> 152) at org.mortbay.jetty.Server.handle(Server.java:324) at  
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 
> 534) at org.mortbay.jetty.HttpConnection 
> $RequestHandler.headerComplete(HttpConnection.java:864) at  
> org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) at  
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) at  
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) at  
> org 
> .mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 
> 409) at org.mortbay.thread.QueuedThreadPool 
> $PoolThread.run(QueuedThreadPool.java:522)
> On 24/12/2008, at 9:09 AM, David Pollak wrote: > Marc, > > Does the  
> pom.xml file refer to Lift 0...
>
> >

--~--~-~--~~~---~--~~
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: todo_steps feedback

[Marc Boschma]

It refers to 0.10-SNAPSHOT. I added the

   net.liftweb
   lift-util
   0.10-SNAPSHOT
 
 
   net.liftweb
   lift-webkit
   0.10-SNAPSHOT
 
 
   net.liftweb
   lift-mapper
   0.10-SNAPSHOT
 

after

 
   net.liftweb
   lift-core
   0.10-SNAPSHOT
 

In the pom.xml

I also edited the Boot.scala file as per a pervious email where you  
documented the impact of the changes.

Something is still not quite there as I get the following error:
HTTP ERROR: 500
scala/actors/AbstractActor
RequestURI=/

Caused by:
java.lang.NoClassDefFoundError: scala/actors/AbstractActor at  
net.liftweb.http.LiftRules$.rewriteTable(LiftRules.scala:372) at  
net.liftweb.http.LiftFilterTrait$$anonfun$doFilter 
$1.apply(LiftServlet.scala:480) at net.liftweb.http.LiftFilterTrait$ 
$anonfun$doFilter$1.apply(LiftServlet.scala:476) at  
net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply$4$ 
$anonfun$apply$5.apply(Vars.scala:150) at  
net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33) at  
net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply 
$4.apply(Vars.scala:149) at  
net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33) at  
net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply(Vars.scala: 
148) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:33) at  
net.liftweb.http.RequestVarHandler$.apply(Vars.scala:147) at  
net.liftweb.http.LiftFilterTrait$class.doFilter(LiftServlet.scala:475)  
at net.liftweb.http.LiftFilter.doFilter(LiftServlet.scala:496) at  
org.mortbay.jetty.servlet.ServletHandler 
$CachedChain.doFilter(ServletHandler.java:1115) at  
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java: 
361) at  
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java: 
216) at  
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java: 
181) at  
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java: 
766) at  
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)  
at  
org 
.mortbay 
.jetty 
.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java: 
230) at  
org 
.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java: 
114) at  
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java: 
152) at org.mortbay.jetty.Server.handle(Server.java:324) at  
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java: 
534) at org.mortbay.jetty.HttpConnection 
$RequestHandler.headerComplete(HttpConnection.java:864) at  
org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533) at  
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) at  
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) at  
org 
.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java: 
409) at org.mortbay.thread.QueuedThreadPool 
$PoolThread.run(QueuedThreadPool.java:522)

On 24/12/2008, at 9:09 AM, David Pollak wrote:

> Marc,
>
> Does the pom.xml file refer to Lift 0.9 or 0.10-SNAPSHOT?
>
> Thanks,
>
> David
>
> On Tue, Dec 23, 2008 at 2:00 PM, Marc Boschma  +lift...@boschma.cx> wrote:
> I was just trying out the Little Lift example and noticed that the  
> archetype:generate lift-archetype-basic created an old pom.xml and  
> Boot.scala that was pre the changes that removed  
> LiftRules.addTemplateBefore(User.templates) and  
> S.addArround(User.requestLoans) lines of Boot.scala...
>
> Is there any reason why that would have occurred? I assumed that it  
> would have changed with those other changes. I did delete all my .m2  
> repository just in case. Didn't change anything...
>
> Regards,
>
> Marc
>
> On 15/12/2008, at 1:43 AM, David Pollak wrote:
>
>> Thanks!  I'll make the change.
>>
>> On Sat, Dec 13, 2008 at 7:44 PM, mal3   
>> wrote:
>>
>> David,
>>
>> I'm not sure where to send feedback on the todo_steps book. I'm
>> working my way through the todo
>> project, and I my feedback may be at times very minor in the  
>> interests
>> of doing my bit to help with
>> the final book product.
>>
>> There was a warning with the first mvn command:
>>
>> [INFO] [archetype:create]
>> [WARNING] This goals is deprecated. Please use mvn archetype:generate
>> instead
>>
>> mvn archetype:generate seemed to work just as well. If there's no
>> reason to use create rather than generate,
>> maybe change it to generate in the book.
>>
>> Mal.
>>
>>
>>
>>
>>
>> -- 
>> 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
>>
>>
>>
>
>

[Lift] Re: todo_steps feedback

[Marc Boschma]

I was just trying out the Little Lift example and noticed that the  
archetype:generate lift-archetype-basic created an old pom.xml and  
Boot.scala that was pre the changes that removed  
LiftRules.addTemplateBefore(User.templates) and  
S.addArround(User.requestLoans) lines of Boot.scala...

Is there any reason why that would have occurred? I assumed that it  
would have changed with those other changes. I did delete all my .m2  
repository just in case. Didn't change anything...

Regards,

Marc

On 15/12/2008, at 1:43 AM, David Pollak wrote:

> Thanks!  I'll make the change.
>
> On Sat, Dec 13, 2008 at 7:44 PM, mal3   
> wrote:
>
> David,
>
> I'm not sure where to send feedback on the todo_steps book. I'm
> working my way through the todo
> project, and I my feedback may be at times very minor in the interests
> of doing my bit to help with
> the final book product.
>
> There was a warning with the first mvn command:
>
> [INFO] [archetype:create]
> [WARNING] This goals is deprecated. Please use mvn archetype:generate
> instead
>
> mvn archetype:generate seemed to work just as well. If there's no
> reason to use create rather than generate,
> maybe change it to generate in the book.
>
> Mal.
>
>
>
>
>
> -- 
> 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: liftweb xml schema location

[Marc Boschma]

Maybe Oliver is being a bit lose with the language and is looking for  
the /lift/  DTD (Document Type Definition) ?

Marc

On 18/12/2008, at 4:05 AM, Viktor Klang wrote:

> Ah, I read "I have a client doesn't want an external link like
>   xmlns:lift="http://liftweb.net/"";
>
> If you're only talking about that namespace declaration, it's just  
> as David says, just a namespace declaration.
>
> /Viktor
>
> On Wed, Dec 17, 2008 at 1:29 PM, David Bernard  > wrote:
>
> It's not an external link nor a link to a schema but the definition of
> a namespace : lift
>
> On Wed, Dec 17, 2008 at 10:07, Oliver Lambert   
> wrote:
> > Don't I need the xsd or dtd specification?
> > On 17/12/2008, at 7:50 PM, Viktor Klang wrote:
> >
> > Why not just add a hosts entry and redirect that host to an internal
> > machine?
> >
> > On Wed, Dec 17, 2008 at 7:26 AM, Oliver  wrote:
> >>
> >> I have a client doesn't want an external link like
> >> xmlns:lift="http://liftweb.net/";
> >> Can I store the schema locally? How do I get it?
> >>
> >> cheers
> >> Oliver
> >>
> >>
> >
> >
> >
> > --
> > Viktor Klang
> > Senior Systems Analyst
> >
> >
> >
> >
> >
> > >
> >
>
>
>
>
>
> -- 
> Viktor Klang
> Senior Systems Analyst
>
> >


--~--~-~--~~~---~--~~
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: HTTP Client?

[Marc Boschma]

Given Lift's focus on security I envisioned that the POST URL would  
contain a random element, to reduce the threat of fake PayPal  
interactions. It is a small risk, but then it is the small risks that  
usually allow a hacker in, eventually.

David said there was support for per session dispatch, which would  
mean that URL could be set up before calling PayPal. Once the session  
ended, or the transaction, you would remove the URL support after  
PayPal responded, or not...

I would favour the PayPal support being able to live independently of  
other lift modules, with some (one) StatefulSnippets as an example?

Marc

On 26/09/2008, at 7:34 PM, Tim Perrett wrote:

>
> Great feedback - thanks guys!
>
> I'll re-jig the PDT stuff to make it more like your suggestions.
>
> Regarding the IPN pay pal stuff - I was having a think about this and
> thought that it would be good to do something along the same lines of
> ajax_requst.
>
> For instance, when you configure IPN you have to specify a location on
> your server where paypal will send the post data regarding the
> transaction - if we had:
>
> //paypal_gateway
>
> Then we could do all the processing and return an object which had all
> the data already assigned onto it. Before I start to right a bunch of
> stuff, what do people think? I don't want to pollute LiftServlet
> unless I really have to - is there someplace else I can put it, or
> would that be most suitable?
>
> Cheers
>
> Tim
>
>
>
>
> On Sep 24, 4:48 pm, David Pollak <[EMAIL PROTECTED]> wrote:
>> Kris Nuttycombe wrote:
>>> If you're going to take that approach, why not just make the
>>> constructor or factory method ensure that the object is in a valid
>>> state to begin with? When I write immutable objects, they usually
>>> don't have any setters for that very reason. It doesn't make sense  
>>> to
>>> me that one would construct a PayPal object in an unusable state.
>>
>> Agreed.  The initial "builder" (no longer using the word  
>> Constructor per
>> Viktor's suggestion) should vend an object that can be used.  Any
>> additional state (e.g., useSSL) should return a new instance of a
>> mutated object.
>>
>> As to Viktor's suggestion, having a bunch of builder methods on an
>> object rather than an explicit constructor is the right way to go.   
>> e.g.:
>>
>> trait PayPal {}
>>
>> object PayPal {
>>   def apply(): PayPal = 
>>
>> }
>>> Kris
>>
>>> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]>  
>>> wrote:
>>
 Tim,
>>
 I like the work, but I tend not to like mutable data structures  
 (stuff with
 properties that one sets.)  I'd structure things such that the  
 PayPal
 object's "setters" return a new, immutable instance of the PayPal  
 object, so
 you're code would look like:
>>
 val pp: PayPal = new
 PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>>
 I'd also update the "execute" method so that it returns another  
 immutable
 object that has current state rather than mutating the original  
 PayPal
 object.
>>
 Thanks,
>>
 David
>>
 Tim Perrett wrote:
>>
 Thanks Derek :-) I have commited any code for ages, so its about  
 time
 I did!
>>
 My plan is this - once I get this roll out of the site im doing now
 (which just needs PDT) done, I'll add the IPN functions to it. From
 the docs, it looks pretty straight forward.
>>
 You can configure a whole bunch of options like so:
>>
 /* values can be "sanbox" or "live" */
 var paypal: PayPal = new PayPal("sandbox")
 /* self expanitory */
 paypal.transactionToken = S.param("tx").openOr("")
 /* set if you need to use SSL (changes port and protocol) */
 paypal.useSSL = true
 /* run the paypal transaction - either with a PDT payload or  
 IPN
 payload */
 paypal.execute("pdt")
>>
 Anything else / different way of doing it people think I should  
 build
 in?
>>
 Tim
>>
 On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]>  
 wrote:
>>
 Tim, you rock :)
> >


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Desiderata. Was: [Lift] RBAC in Lift

[Marc Boschma]

My current understanding is that Lift is a snippet rather than page  
oriented framework. SiteMap focuses on access or not to page level.

Thinking about this overnight it sounds like we need some way to  
inform a snippet of who is trying to interact with it and what rights  
they have is needed.

Would that be done by wrapping utilising isDefinedAt on the  
PartialFunction to allow snippet code to behave differently based on  
some sort of passed in (does it actually have to be passed in?)  
credential type?

To me the solution should allow the snippet's logic to be in one  
place, if possible have no impact on a non-credential sensitive  
snippet (or very little, if we don't want to default to a snippet  
being open if not explicitly closed).

Also since snippets are recursive how do we handle a chain of  
InSecureSnippet -> SecureSnippet when we don't want InSecureSnippet to  
produce content if SecureSnippet doesn't want to produce content?

Would there need to be special provisions for StatefulSnippets if the  
credentials change from them starting?

Marc

On 12/09/2008, at 8:09 AM, Charles F. Munat wrote:

>
> Marius wrote:
>>> Also, I like the user-created pages to be accessible by URL (i.e.
>>> without a query string) with a readable URL, so:
>>>
>>> mysite.com/some_page
>>>
>>> Not:
>>>
>>> mysite.com/p123456, mysite.com?page=some_page, or mysite.com? 
>>> page=123456
>>
>>
>> What is the difference between mysite.com/some_page and  mysite.com/
>> p123456? I mean what is the exact problem you're trying to solve?
>> Perhaps a more concrete example may help us help you.
>
> A short synopsis can be found here:
>
> http://plone.org/products/plone/features/3.0/existing-features/human-readable-urls
>
> If you Google "human-readable URL," you'll get some other interesting
> hits. I first encountered the concept years ago when I was spending  
> time
> on the W3C's Web Accessibility Initiative list. I've been doing my  
> best
> to use human-readable URLs ever since.
>
> But I wasn't actually asking a question, just mentioning this as a
> desiderata. I'll figure it out when I get to that point. Meanwhile,  
> I am
> getting my hands dirty -- as you put it -- figuring out the SiteMap  
> and
> related code. Will post questions as they come up.
>
> Chas.
>
>
> >


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Netbeans & /lift/

[Marc Boschma]

Hi,

I've been playing with Netbeans + Scala plug-in, and now just starting  
to consider /lift/ as well...

 From what I can tell (googling) it is still necessary to create a  
maven /lift/ project by hand (command line) and then open that in  
Netbeans... is that correct?

Ideally it would be nice to be able to start a /lift/ project from  
within the IDE like a Scala Application or Library.

Marc


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---