I want to (attempt to) prevent the browser from caching certain pages as
there is a problem if the user backs up to them. I can do this with HTTP
headers, of course.
Question: Is this functionality built-in to Lift? I could find nothing
on the wiki. If not, how does one set the HTTP headers on
Awesome!
Derek
PS - I just got two of the same email from you at 4:25 and 4:38. Did you hit
send twice or is something going on with the list?
On Tue, Dec 9, 2008 at 4:38 PM, David Pollak
<[EMAIL PROTECTED]>wrote:
> I looks like a defect to me. I'll work on fixing it Thursday.
>
> On Tue, Dec
OK, I definitely see some problems here. Unfortunately I'm pretty tied up
for the rest of the evening, but if you don't mind waiting I promise to
write up a detailed response tomorrow. Let me just point out some things I
see:
1. You're calling merge (Model.merge(s)) on an object that you just
I looks like a defect to me. I'll work on fixing it Thursday.
On Tue, Dec 9, 2008 at 2:04 PM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote:
> This is both a comment and a question. I'd like to be able to have a Menu
> with a Loc pointing at "/help/". By using the strPairToLink method on the
> Loc
Derek Chen-Becker wrote:
> Hmmm. It doesn't seem like this should be causing issues. Probably the
> most common mistake made with merge is that merge returns an entirely
> new object, so you discard the original.
Ah! That's good to know. I think that after I used Model.merge(row) I
expected ro
I looks like a defect to me. I'll work on fixing it Thursday.
On Tue, Dec 9, 2008 at 2:04 PM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote:
> This is both a comment and a question. I'd like to be able to have a Menu
> with a Loc pointing at "/help/". By using the strPairToLink method on the
> Loc
This is both a comment and a question. I'd like to be able to have a Menu
with a Loc pointing at "/help/". By using the strPairToLink method on the
Loc object, I can use it as both an entry into the help system. This allows
me to effectively bring up "/help/index" due to Lift converting trailing
sl
On Tue, Dec 9, 2008 at 12:12 PM, Jorge Ortiz <[EMAIL PROTECTED]> wrote:
> Hm... I can think of situations where such mutations are useful after
> Boot (app/prependSnippet comes to mind). Maybe they can be made immutable
> (.toList) as necessary?
>
I think these should be session-specific and
Hmmm. It doesn't seem like this should be causing issues. Probably the most
common mistake made with merge is that merge returns an entirely new object,
so you discard the original. Also, if you want the change to be immediately
visible and to check constraints, etc, you need to immediately flush.
I'm not really very clear on how all this works, but I've had a terrible
time with merging objects.
I built a multi-page survey with forty-some questions on it. One of the
questions asks users to fill out a table in which each row is an object
-- call it a Row. I don't know in advance whether
I started to add a few RulesSeq ... looks pretty neat so far not to
mention that LiftRules is reducing its size. And these var can
actually be publicly exposed as val-s.
On Dec 9, 10:30 pm, Marius <[EMAIL PROTECTED]> wrote:
> I agree with append/prepend naming. As far as ListBuffer goes I'm not
>
I agree with append/prepend naming. As far as ListBuffer goes I'm not
sure ... I mean you are correct about it, but these "rules" will be
done once in boot and I'm not sure who actually adds more then a few
items .. in practice.
At the end of the day I don;t mind using ListBuffer or List ...as I
I would use a ListBuffer as the underlying representation. I would call the
methods "append" and "prepend" (LiftRules.snippet.append,
LiftRules.dispatch.append, etc.). I would also make them immutable
as-needed. ListBuffer caches toList so that it's very efficient if you don't
append/prepend in bet
I think you misunderstand the lifecycle of a stateful snippet. A stateful
snippet has specific techniques to keep it resident (using this.link,
this.redirect, etc) so you have to be careful about how you use it or you
lose the instance. The HTTP session would be the most appropriate place for
a JPA
I'm not sure if this is the case ... if we want context dependent
Snippets then probably using loc snippets is the right place
How about something like:
abstract class RulesSeq[T] {
var rules : List[T] = Nil
private def safe_?(f : => Any) {
doneBoot match {
case false => f
c
ListBuffer has constant time append and prepend methods, as well as constant
time toList. (Except after using toList, the next append/prepend will take
some work.)
--j
On Tue, Dec 9, 2008 at 2:09 PM, Marius <[EMAIL PROTECTED]> wrote:
>
> Sounds good. I'll look into it
>
>
> On Dec 9, 10:01 pm, "
Hm... I can think of situations where such mutations are useful after
Boot (app/prependSnippet comes to mind). Maybe they can be made immutable
(.toList) as necessary?
--j
On Tue, Dec 9, 2008 at 2:01 PM, David Pollak
<[EMAIL PROTECTED]>wrote:
> And we should freeze the lists after Boot is fi
Sounds good. I'll look into it
On Dec 9, 10:01 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> And we should freeze the lists after Boot is finished. The permutation
> methods should throw exceptions post-boot
>
> On Dec 9, 2008 11:39 AM, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
>
> Seems like
And we should freeze the lists after Boot is finished. The permutation
methods should throw exceptions post-boot
On Dec 9, 2008 11:39 AM, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
Seems like prime opportunity for an abstraction...
Why not make them (*gasp*) mutable data structures with prepend/a
Seems like prime opportunity for an abstraction...
Why not make them (*gasp*) mutable data structures with prepend/append
methods?
--j
On Tue, Dec 9, 2008 at 1:35 PM, Marius <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> Unfortunatelly only some vars that are essentially Lists of something
> are privat
Hi.
Unfortunatelly only some vars that are essentially Lists of something
are private and prepend/append functions are exposed.
I proposed to do this for ALL List variables.
Br's,
Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
Matt,
This is great. I am looking forward to your Netbeans screencast.
Thanks.
Dan
On Dec 8, 1:00 am, "Matt Harrington" <[EMAIL PROTECTED]> wrote:
> I made a little screencast about creating a sample
> "lift-archetype-basic" application. I hadn't made a screencast
> before, and it was actua
Hi Derek,
I think I found the solution to the problem I am thinking of.
Its called JPA Extended Persistence Context. Its suggested that a
extended persistence context be created which starts at some time and
ends at some time and is stored in HttpSession. From the bits I read
they said its no goo
Hi Derek,
I think I found the solution to the problem I am thinking of.
Its called JPA Extended Persistence Context. Its suggested that a
extended persistence context be created which starts at some time and
ends at some time and is stored in HttpSession. From the bits I read
they said its no goo
24 matches
Mail list logo
