I noticed that Assembla sends a lot of spam (seems I get an e-mail for
everything anyone does in there, including new users registering)
These alerts can be turned off under Stream - Change alert settings
if anyone has trouble finding it.
--
You received this message because you are subscribed
issue not a framework level
issue.
Tim
On 6 Feb 2010, at 21:55, Erkki Lindpere wrote:
The NotFoundResponse (and others) puts the custom message into the
request body. That works as well, but to be really lean (mainly for
bragging rights :)) I'd like to remove any unnecessary elements
in the container we should probably not add support for it. I
can't believe they deprecated it for the reason they did, but there it is.
-Ross
On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote:
Actually, the reason phrase is not a normal HTTP header, but part of
the status line:
http
be
determined, to allow customizations for well-known providers.
Erkki L
On Feb 6, 9:54 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Erkki Lindpere vill...@gmail.com writes:
Thanks!
I'm now trying to customize the attribute-exchange and noticed that it
is embedded in a longish method. I
It seems Lift does not support custom HTTP Reason Phrases in
responses. I would like to send error messages in the Reason Phrase
(along with a vaguely applicable HTTP status code) in a RESTful API
I'm providing. My understanding of the HTTP spec is that the reason
phrase is meant to be human
On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote:
It seems Lift does not support custom HTTP Reason Phrases in
responses. I would like to send error messages in the Reason Phrase
(along with a vaguely applicable HTTP status code) in a RESTful API
I'm providing. My understanding of the HTTP
to
openid_identifier. If this causes code breakage, folks can change it back
to the old value.
Thanks for the suggestion.
On Sat, Jan 30, 2010 at 7:58 AM, Erkki Lindpere vill...@gmail.com wrote:
Hi,
I suggest that Lift-OpenID should have openid_identifier as the
default post param name instead
Hi,
I suggest that Lift-OpenID should have openid_identifier as the
default post param name instead of openIdUrl. openid_identifier is
the one recommended in the OpenID spec. with the idea that user agents
may someday special support for that. I think this change would be
justified considering
Just reporting my experience for anyone who wants to live on the
bleeding edge... for a limited use case (I only use lift-webkit, and
probably only a small subset of that), the 280_port seems to be
working well enough with a recent Scala 2.8 snapshot (once I applied
the fix to a Scala class that
Ok, I'll collect some specific issues I have with the API over a bit
longer period of usage and post them as an issue in GitHub? Or here?
Erkki L
On Dec 28, 4:40 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
* there are several classes that have lots of methods in them that
don't all
L
On Dec 29, 7:58 pm, Erkki Lindpere vill...@gmail.com wrote:
Ok, I'll collect some specific issues I have with the API over a bit
longer period of usage and post them as an issue in GitHub? Or here?
Erkki L
On Dec 28, 4:40 am, Naftoli Gugenheim naftoli...@gmail.com wrote
, Erkki Lindpere vill...@gmail.com wrote:
Ok, I'll collect some specific issues I have with the API over a bit
longer period of usage and post them as an issue in GitHub? Or here?
Erkki L
On Dec 28, 4:40 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
* there are several classes
changes. I don't know if it can be configured or used
or what-have-you for reviewing the current state of code.
-Ross
On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote:
Another option would be to use a specialized code review tool, though
someone would have to host it. There's one thing
I mostly agree with what David said and I'll add this:
* I think _? and _! in methods come from Ruby, but they don't fit the
naming conventions in Java/Scala (I think Scala should mostly follow
Java conventions with some exceptions). This is a really minor point
though.
* object User extends
Eh... sorry, ignore the point about Box in the previous message. I
looked it up while posting but forgot to delete that paragraph. I do
understand where it may be useful in some cases.
On Dec 26, 2:19 am, Erkki Lindpere vill...@gmail.com wrote:
I mostly agree with what David said and I'll add
Well, I'm not sure if I completely get it yet or if I can summarize
well enough, but:
I should look at Lift through more functional programming goggles,
some things in it don't make a lot of sense when looked through OO
goggles.
From looking through some of the docs, examples and sources, I have
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
It took me a long time to get lift. For about a year I looked at
examples from time to time and tried out some basic stuff, but it just
didn't click. I found the structure to be too messy. I still do
actually. It seems that the documentation is also not well structured
enough for getting started
I couldn't figure out why my snippet was not being called, then
renamed my class (it was named Msg) and it started working. Is Lift
possibly resolving lift:msg.blabla to another class called Msg?
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to
This has probably come up previously, but I couldn't find anything
even though I think a couple of days ago I read about something
similar:
I want to do a snippet that behaves similarly to JSTL-s forEach tag.
Not exactly the same, but the idea is that it gets some list of model
objects, then goes
on?
-Ross
On Dec 23, 2009, at 1:26 PM, Erkki Lindpere wrote:
This has probably come up previously, but I couldn't find anything
even though I think a couple of days ago I read about something
similar:
I want to do a snippet that behaves similarly to JSTL-s forEach tag.
Not exactly
what=modelobject /
/lift:MySnippet.forEach
lift:MySnippet.justOne eager_eval=true
lift:embed what=modelobject /
/lift:MySnippet.justOne
-Ross
On Dec 23, 2009, at 1:51 PM, Erkki Lindpere wrote:
Well, I'd prefer to keep different concerns separated. Iterating over
that list
22 matches
Mail list logo
