Re: [Lift] Sending malformed HTML in custom dispatch
You can use a standard xml-style response, but use Unparsed to embed unparsed (and possibly malformatted) XML as a string. -Ross On Dec 26, 2009, at 12:53 AM, tommycli wrote: I'm using custom dispatch (to handle both XML media files). Often, I will want to send a page that contains user-inputted (X)HTML. This will often be malformed HTML that is nevertheless rendered fine by a modern browser. How would I send this through? I tried PlainTextResponse, but it sends the wrong mime type and shows up as well... plaintext. And XHtmlResponse requires valid XHTML. Is there any response that sends a String and claims that it's (x) html? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
While I admit that there is not yet enough documentation material or at least probably not in a single place I disagree with some complaints. The Lift book for example describes in quite detail that request processing lifecycle, disspath functions, rendering pipeline, LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction and many others etc. Sure new things came up in the mean time and we're trying to document them as time permits in many cases. About the Lift structure being too messy, what do you actually mean? AFAIK historically, people (a many newbies) asserted the contrary that they really liked the Lift concepts, the ease of use and understand how it works. For naming conventions there was a project opened and even discussed on this public list about renaming API's but AFAIK there was not a whole lot of feedback on this list so unless I'm wrong, the decision was to do ad-hoc renaming as we work on various things. This may mean deprecation of old names so there will be a smooth transition to better names. So I believe it is much more constructive for ALL of us to ask concrete questions, described concrete problems and let's see how we can fix it. Many things though may be subjective and leading to endless discussions without substance. Br's, Marius On Dec 26, 2:51 am, Erkki Lindpere vill...@gmail.com wrote: I think the best things I think you could do to help newbies is document in a well-structured way: * all the conventions over configuration rules * what classes to use for the basic stuff (what is S for and how it should be used, all the things you can do with LiftRules, etc.) * more advanced uses of bind(...) in snippets * better docs for the Lift tags. On Dec 25, 9:09 pm, Timothy Perrett timo...@getintheloop.eu wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Sending malformed HTML in custom dispatch
You can implement your own response by extending LiftResponse, such
as:
case class RiskyHtmlResponse(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/html;
charset=utf-8) :: headers, Nil, code)
}
}
Br's,
Marius
On Dec 26, 7:53 am, tommycli tommy...@ucla.edu wrote:
I'm using custom dispatch (to handle both XML media files). Often, I
will want to send a page that contains user-inputted (X)HTML. This
will often be malformed HTML that is nevertheless rendered fine by a
modern browser.
How would I send this through? I tried PlainTextResponse, but it sends
the wrong mime type and shows up as well... plaintext. And
XHtmlResponse requires valid XHTML.
Is there any response that sends a String and claims that it's (x)
html?
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Mapper validation workflow thoughts
I would actaully use:
var inputString: Box[String] = Empty .
However I'm not sure if toForm should be implemented like that. I'd
rather let the refinements to decide when to render the inputString or
the actual value. But it's an implementation detail mostly
I think that we should apply this concept in both Mapper and Record.
So from my perspective I think you should open a defect.
Br's,
Marius
On Dec 25, 3:57 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Currently the workflow of field validation in Mapper often goes as follows
(not using ajax):
User loads a page containing say fields generated by toForm on the field or
the mapper
User presses save, submitting his data
The data goes into the fields
Validators are called and one fails so instead of saving and redirecting
the same page is loaded
The inputs contain the values in the MappedFields, some of which need to
be modified so the mapper can be saved. Messages are displayed indicating the
problem with whichever field.
There is one serious limitation of this sequence which is that it uses
validators that operate on data in the field and act as a gatekeeper
preventing them from going from the mapper into the database. They do not
deal with values that can't get into the mapper in the first place! So if you
enter a date and it parses incorrectly you don't get to edit it but a blank
field and message telling you what you did wrong but not showing your input
for reference.
It's not really the job of a validator. The MappedFields already decide
whether a string input can be parsed in--they just leave no tracks.
This is also relevant when
def f(x: String) = {field.setFromAny(x); field.is.toString==x}
is false.
I'm interested in hearing whatever suggestions and thoughts people have, but
here's my suggestion.
My opinion is that MappedField or one of the common base traits should have a
member to remember the input string.
Or maybe better yet something along these lines:
trait FormField {
type T
def is: T
var inputString: Option[String] = None
def parseIn(s: String) = inputString = Some(s) // subclasses should
override and call super
def formXml(name, String, value: String): NodeSeq
def toForm: NodeSeq = S.fmapFunc((s:List[String])=parseIn(s))(name =
formXml(name, inputString.getOrElse(value))}
(Vague sketch)
In other words, the concept of an html form provider could be moved to its
own trait, which could provide logic for trapping parse errors, and
MappedField could inherit from that trait.
Thoughts?
Thanks.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Hello, It would be great to see some more bind examples in more complex scenarios and how different snippets can work together. How to build fragments and replace fragments for ajax. I think the people that do a lot with lift have some patterns for this. Are there any Idioms out. This is my problem area. with best regards On 26 Dez., 15:30, Marius marius.dan...@gmail.com wrote: While I admit that there is not yet enough documentation material or at least probably not in a single place I disagree with some complaints. The Lift book for example describes in quite detail that request processing lifecycle, disspath functions, rendering pipeline, LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction and many others etc. Sure new things came up in the mean time and we're trying to document them as time permits in many cases. About the Lift structure being too messy, what do you actually mean? AFAIK historically, people (a many newbies) asserted the contrary that they really liked the Lift concepts, the ease of use and understand how it works. For naming conventions there was a project opened and even discussed on this public list about renaming API's but AFAIK there was not a whole lot of feedback on this list so unless I'm wrong, the decision was to do ad-hoc renaming as we work on various things. This may mean deprecation of old names so there will be a smooth transition to better names. So I believe it is much more constructive for ALL of us to ask concrete questions, described concrete problems and let's see how we can fix it. Many things though may be subjective and leading to endless discussions without substance. Br's, Marius On Dec 26, 2:51 am, Erkki Lindpere vill...@gmail.com wrote: I think the best things I think you could do to help newbies is document in a well-structured way: * all the conventions over configuration rules * what classes to use for the basic stuff (what is S for and how it should be used, all the things you can do with LiftRules, etc.) * more advanced uses of bind(...) in snippets * better docs for the Lift tags. On Dec 25, 9:09 pm, Timothy Perrett timo...@getintheloop.eu wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Lift is awesome (with reservations)
Great stuff. Could you please describe more complex scenarios ? I mean let's start from some step-by-step use-case/workflow definitions that you're looking for and we'll try to provide different approaches, and potentially put them on the wiki for future reference. Br's, Marius On Dec 26, 6:27 pm, greekscala hellectro...@gmail.com wrote: Hello, It would be great to see some more bind examples in more complex scenarios and how different snippets can work together. How to build fragments and replace fragments for ajax. I think the people that do a lot with lift have some patterns for this. Are there any Idioms out. This is my problem area. with best regards On 26 Dez., 15:30, Marius marius.dan...@gmail.com wrote: While I admit that there is not yet enough documentation material or at least probably not in a single place I disagree with some complaints. The Lift book for example describes in quite detail that request processing lifecycle, disspath functions, rendering pipeline, LiftRules, S, SHtml, LiftResponse-s, binds, JavaScript abstraction and many others etc. Sure new things came up in the mean time and we're trying to document them as time permits in many cases. About the Lift structure being too messy, what do you actually mean? AFAIK historically, people (a many newbies) asserted the contrary that they really liked the Lift concepts, the ease of use and understand how it works. For naming conventions there was a project opened and even discussed on this public list about renaming API's but AFAIK there was not a whole lot of feedback on this list so unless I'm wrong, the decision was to do ad-hoc renaming as we work on various things. This may mean deprecation of old names so there will be a smooth transition to better names. So I believe it is much more constructive for ALL of us to ask concrete questions, described concrete problems and let's see how we can fix it. Many things though may be subjective and leading to endless discussions without substance. Br's, Marius On Dec 26, 2:51 am, Erkki Lindpere vill...@gmail.com wrote: I think the best things I think you could do to help newbies is document in a well-structured way: * all the conventions over configuration rules * what classes to use for the basic stuff (what is S for and how it should be used, all the things you can do with LiftRules, etc.) * more advanced uses of bind(...) in snippets * better docs for the Lift tags. On Dec 25, 9:09 pm, Timothy Perrett timo...@getintheloop.eu wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: [Lift] Re: Lift is awesome (with reservations)
On Saturday 26 December 2009 15:30:34 Marius wrote: So I believe it is much more constructive for ALL of us to ask concrete questions, described concrete problems and let's see how we can fix it. Many things though may be subjective and leading to endless discussions without substance. OK, then, concrete cases it is. I will try to transform the problems I mentioned before into concrete scenarios. Hopefully, this will shed some more light on what I mean. - I want a user system where each user registers with an user name and a password, nothing else (not First Name, Last Name, E-mail etc; there shouldn't be any entries for them in the DB either). For this, I would prefer to use pre-existing utility classes in the Lift framework so that I don't have to start from scratch (by extending LongKeyedMetaMapper etc), because, oh I don't know, I don't want to code the whole user session management and password exchange process by hand (even though it might not be too difficult; it's reinventing the wheel nonetheless). How do I proceed? - I'd like to use ProtoUser, but need to change the labels for some of the fields in the registration form because I want to localize the site. Please remember that ProtoUser uses S.??, which makes it impossible to add translations and/or change the default wordings from the outside. How do I proceed with the least amount of hacks (like by writing field.displayName.replace(First Name, S.?(...)) + overriding the correct functions with slightly changed versions of their original code)? - I'd like to take a mapped object that I have, and CRUDify it (hint, hint). In my mapped object (e.g. an user), I have some fields that should always appear (e.g. basic contact information), some that should appear only to administrators (e.g. email addresses), and some that should be read-only to normal users and editable by administrators and specific users but not appear to unregistered users (e.g. user profile images). Columns that should be invisible should not be rendered in the CRUDify list with contents like permission denied; their rendered columns should rather not appear at all. How do I proceed with the least amount of hacks? - I'd like to use CRUDify again, but I need to use external templates (inside of HTML files) for the list, edit, etc... pages, since I need to change these templates after the application was compiled (or for some similar reason, like that view/model code should be separate). How do I proceed? - Same situation like the above (need to control the CRUDify templates from the outside), but I want to use a different HTML snippet depending on which field is being rendered (I don't want to use an uniform table for the view, but maybe one where some fields are stacked over another, or arranged in a different constellation). Like this: = lift:surround with=default at=content lift:crudifyList!--...or some other snippet name...-- table tr th list:header forField=nameemheader:value//em/list:header /th!--snip, more headers...-- /tr list:row!--repeats for every row-- tr row:entry forField=nametdentry:value//td/row:entry td row:entry forField=userimageentry:value//row:entrybr/ row:entry forField=imageDescriptionementry:value//em/row:entry /td /tr /list:row /table /lift:crudifyList /lift:surround = The ems etc above are of course template-specific view code that mustn't be in the logic code. How do I do this with the least amount of hacks? These are of course scenarios that are fabricated but I've experienced similar ones that I've had problems with before; I don't know if there's some kind of solution to them that I've just missed (after some through looking, I gave up on most of them and just wrote everything form scratch by copy-pasting Lift source code). It all boils down to there being very specialized starter classes like ProtoUser and CRUDify, that cannot be used for anything but very small test sites in practice since they aren't extensible. Br's, Marius PS. It may be that a lot of the quirks of Lift are explained in the Lift book, and I think that that's a good start. That doesn't make them any more intuitive, however. You can make any man (almost) into a rocket scientist by using education, but that doesn't make rockets any easier to understand. David Flemström signature.asc Description: This is a digitally signed message part.
[Lift] source of working demo of Lift+JPA on google app engine
Hi, I am a new Lifter just came from Grails world (with 6 months experiences with Grails + GAE playing a couple of toy apps). Because Grails (even the latest release of v1.2) does not really support GAE, or precisely only semi support, as said at google site, I look for a new framework has better GAE support and came to Lift after read some stuff by David and James Strachan (creator of Groovy language). I bought the lift book from Apress and try to make the JPA demo work on GAE but with no luck. I could not find any source of a working demo on Lift+JPA on GAE (I do find a working demo of Lift+JDO on GAE by ymnk: github.com/ymnk/lift-gae-jdo, by the way). Could someone point me to the source of a working demo of Lift + JPA on GAE? thanks a lot, Qingshan -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] guid - function mapping not occuring for ajax generator rendered by CometActor
Hi guys,
I've recently migrated some code which leverages ajax and comet quite
heavily, from 1.1-M4 to 1.1-M8 and have found that the function
binding for a rendered ajax element, bound to a template which is
itself the target of another ajax element, rendered via a CometActor
(a mouthful I know) - no longer works. Rendering the same ajax element
via a template works, and previously worked via a CometActor in 1.1-
M4. The javascript callback code (and it's associated GUID) is
generated, and the ajax_request successfully hits jetty, but I'm
assuming something related to the guid-function mapping is not
occurring, as the function isn't invoked.
I've distilled the problem to an example below:
Template:
lift:surround with=default at=content
lift:TS.stuff /
lift:comet type=MyActor /
div id=whatever /
/lift:surround
Snippet:
class TS {
def stuff(in: NodeSeq): NodeSeq = a(()= { SetHtml(whatever,
lift:TS.stuff2st:something//lift:TS.stuff2) }, Text(this works
(via snippet)))
def stuff2(in: NodeSeq): NodeSeq = bind(st, in, something - a
(() = {println(clicked); Noop}, Text(click me)))
}
CometActor:
class MyActor extends CometActor {
//def render = SetHtml(whatever, lift:TS.stuff2st:something//
lift:TS.stuff2) // works
def render = a(()= { SetHtml(whatever,
lift:TS.stuff2st:something//lift:TS.stuff2) }, Text(this
doesn't (via comet actor)))
}
Can you give an indication of whether this change since M4 is
intentional or if it will be working in future?
Cheers,
Chris
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Lift with MS Access database
Hi All, I'm learning Lift, and get to do a small project in Lift. The requirement is to connect to MS Access database. I got an error at the Schemifier.schemify() call. I have setup DSN in window and was able to connect to the database from NetBeans. the error in the log INFO: ERROR - Failed to Boot scala.MatchError: ACCESS at net.liftweb.mapper.SuperConnection.calcDriver(DB.scala:682) at net.liftweb.mapper.Schemifier$$anonfun$schemify$1.apply (Schemifier.scala:56) at net.liftweb.mapper.Schemifier$$anonfun$schemify$1.apply (Schemifier.scala:54) at net.liftweb.mapper.DB$.use(DB.scala:305) at net.liftweb.mapper.Schemifier$.schemify(Schemifier.scala: 53) at net.liftweb.mapper.Schemifier$.schemify(Schemifier.scala: 36) at bootstrap.liftweb.Boot.boot(Boot.scala:24) Any help is appreciated. Gang -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
