[Lift] Re: Response Optimizations too aggressive

2010-03-07 Thread aw

On Mar 4, 9:50 am, David Pollak  wrote:
> On Thu, Mar 4, 2010 at 9:27 AM, aw  wrote:
> > On Mar 4, 6:56 am, Naftoli Gugenheim  wrote:
> > > How about
> > > LiftRules.stripComments.default.set( () => !Req.isIE)
> > > etc.?
>
> This is where Lift's FactoryMaker shines.  You can modify the behavior of
> stripComments on a request-by-request basis.  You can have a snippet called
> from your default template that tests the request and does:
>
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
>
> But, as you point out, that means that CometActors will not get the right
> settings... so you can set the rule on a session-by-session basis:
>
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)

I don't see the difference.  I presume that you meant to say:

LiftRules.stripComments.session.set(S.request.map(!_.isIE) openOr
false)

?  Alas, neither version works.  I get a syntax error:

[ERROR] ...\snippet\Hack.scala:31: error: value set is not a member of
net.liftweb.util.Maker[Boolean]
[INFO] LiftRules.stripComments.request.set(S.request.map(!_.isIE)
openOr false)
[INFO] ^
[ERROR] one error found

Seeing that request is really a RequestVar, I figure the mod is simple
(lose the .set), but:

[ERROR] ...\snippet\Hack.scala:31: error: value apply is not a member
of net.liftweb.util.Maker[Boolean]
[INFO] LiftRules.stripComments.request(S.request.map(!_.isIE)
openOr false)
[INFO] ^
[ERROR] one error found

Now I am puzzled because I actually do see a valid apply method for
Maker[Boolean] (see line 66 of Maker.scala).

So, what am I missing?  I think I really want:

LiftRules.stripComments.session(S.request.map(!_.isIE) openOr
false)

I feel close, but no compile...

-- 
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: Response Optimizations too aggressive

2010-03-05 Thread Timothy Perrett
This really needs to go on the wiki! gold!

Cheers, Tim

On 4 Mar 2010, at 17:50, David Pollak wrote:

> 
> 
> On Thu, Mar 4, 2010 at 9:27 AM, aw  wrote:
> On Mar 4, 6:56 am, Naftoli Gugenheim  wrote:
> > How about
> > LiftRules.stripComments.default.set( () => !Req.isIE)
> > etc.?
> 
> This is where Lift's FactoryMaker shines.  You can modify the behavior of 
> stripComments on a request-by-request basis.  You can have a snippet called 
> from your default template that tests the request and does:
> 
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
> 
> But, as you point out, that means that CometActors will not get the right 
> settings... so you can set the rule on a session-by-session basis:
> 
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
> 
> If that's not enough, you could also do the following in Boot.scala:
> 
> object shouldStripComments extends SessionVar(S.request.map(!_.isIE) openOr 
> false)
> 
> S.addAround(List(new LoanWrapper {
>   def apply[T](f: => T): T = 
> LiftRules.stripComments.doWith(shouldStripComments.is)(f)
> }))
>  
> The above code wraps each request with access to the shouldStripComments 
> Session Variable.
> 
> The above vomit of different options is more for the benefit of those that 
> are confused by FactoryMaker and why it seems so complex... it's because it 
> offers a ton of different flexibility.
> 
> Thanks,
> 
> David
> 
> 
> Well, this doesn't quite work because I need a Req class instance, not
> just the static object.
> Also, to me, this determination is really at the Session level rather
> than the Request level as I don't expect it to change.  But of course
> I don't have a Session.isIE field...  What about Comet responses?  I
> have no Request in that scenario, but is it using the same code to
> produce the xhtml?
> 
> I see that the Factory trait has a session-specific Maker and a
> request-specific Maker, but it is unclear to me how I can get that
> context.  I require more guidance.
> 
> --
> 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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
> 
> -- 
> 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.



Re: [Lift] Re: Response Optimizations too aggressive

2010-03-04 Thread David Pollak
On Thu, Mar 4, 2010 at 9:27 AM, aw  wrote:

> On Mar 4, 6:56 am, Naftoli Gugenheim  wrote:
> > How about
> > LiftRules.stripComments.default.set( () => !Req.isIE)
> > etc.?
>

This is where Lift's FactoryMaker shines.  You can modify the behavior of
stripComments on a request-by-request basis.  You can have a snippet called
from your default template that tests the request and does:

LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)

But, as you point out, that means that CometActors will not get the right
settings... so you can set the rule on a session-by-session basis:

LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)

If that's not enough, you could also do the following in Boot.scala:

object shouldStripComments extends SessionVar(S.request.map(!_.isIE) openOr
false)

S.addAround(List(new LoanWrapper {
  def apply[T](f: => T): T =
LiftRules.stripComments.doWith(shouldStripComments.is)(f)
}))

The above code wraps each request with access to the shouldStripComments
Session Variable.

The above vomit of different options is more for the benefit of those that
are confused by FactoryMaker and why it seems so complex... it's because it
offers a ton of different flexibility.

Thanks,

David


> Well, this doesn't quite work because I need a Req class instance, not
> just the static object.
> Also, to me, this determination is really at the Session level rather
> than the Request level as I don't expect it to change.  But of course
> I don't have a Session.isIE field...  What about Comet responses?  I
> have no Request in that scenario, but is it using the same code to
> produce the xhtml?
>
> I see that the Factory trait has a session-specific Maker and a
> request-specific Maker, but it is unclear to me how I can get that
> context.  I require more guidance.
>
> --
> 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, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

-- 
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: Response Optimizations too aggressive

2010-03-04 Thread aw
On Mar 4, 6:56 am, Naftoli Gugenheim  wrote:
> How about
> LiftRules.stripComments.default.set( () => !Req.isIE)
> etc.?

Well, this doesn't quite work because I need a Req class instance, not
just the static object.
Also, to me, this determination is really at the Session level rather
than the Request level as I don't expect it to change.  But of course
I don't have a Session.isIE field...  What about Comet responses?  I
have no Request in that scenario, but is it using the same code to
produce the xhtml?

I see that the Factory trait has a session-specific Maker and a
request-specific Maker, but it is unclear to me how I can get that
context.  I require more guidance.

-- 
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: Response Optimizations too aggressive

2010-03-04 Thread Naftoli Gugenheim
How about
LiftRules.stripComments.default.set( () => !Req.isIE)
etc.?

-
aw wrote:

OK, I have disabled the stripping of comments:

LiftRules.stripComments.default.set( () => false )

It seems to work for me.


On Mar 4, 12:36 am, Jeppe Nejsum Madsen  wrote:
> aw  writes:
> >     
>
> Ross already described how to disable this, but this seems like a
> genuine useful feature (to not remove some comments). Iircc, there are
> other scenarios (such as AdWords) where you would like to keep the
> some comments.
>
> Not sure how to handle this in a general way though.
>
> In this case You can also handle it server side: Req.isIE6
>
> /Jeppe

Obviously, it would be great to make the stripComments variable
session specific where I could leverage something like isIE.  I do see
that FactoryMaker seems to have a session and request specific vending
concept, so this looks promising.  I think the code that actually does
the comment stripping is in LiftMerge, so I'm thinking that that would
need to be enriched too.  Ideally, I would like to see comments that
are not IE specific to be stripped.  (I am unfamiliar with AdWords and
how they use comments.)

Sound like a ticket?

Thanks everybody for the quick help!

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



Re: [Lift] Re: Response Optimizations too aggressive

2010-03-04 Thread Timothy Perrett
Personally, I don't like this API. nearly everyone has problems with it as its 
totally not obvious. Perhaps i'll add some more comments to the definition. 

Cheers, Tim

On 4 Mar 2010, at 08:50, aw wrote:

> OK, I have disabled the stripping of comments:
> 
>LiftRules.stripComments.default.set( () => false )
> 
> It seems to work for me.
> 
> 
> On Mar 4, 12:36 am, Jeppe Nejsum Madsen  wrote:
>> aw  writes:
>>> 
>> 
>> Ross already described how to disable this, but this seems like a
>> genuine useful feature (to not remove some comments). Iircc, there are
>> other scenarios (such as AdWords) where you would like to keep the
>> some comments.
>> 
>> Not sure how to handle this in a general way though.
>> 
>> In this case You can also handle it server side: Req.isIE6
>> 
>> /Jeppe
> 
> Obviously, it would be great to make the stripComments variable
> session specific where I could leverage something like isIE.  I do see
> that FactoryMaker seems to have a session and request specific vending
> concept, so this looks promising.  I think the code that actually does
> the comment stripping is in LiftMerge, so I'm thinking that that would
> need to be enriched too.  Ideally, I would like to see comments that
> are not IE specific to be stripped.  (I am unfamiliar with AdWords and
> how they use comments.)
> 
> Sound like a ticket?
> 
> Thanks everybody for the quick help!
> 
> -- 
> 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: Response Optimizations too aggressive

2010-03-04 Thread aw
OK, I have disabled the stripping of comments:

LiftRules.stripComments.default.set( () => false )

It seems to work for me.


On Mar 4, 12:36 am, Jeppe Nejsum Madsen  wrote:
> aw  writes:
> >     
>
> Ross already described how to disable this, but this seems like a
> genuine useful feature (to not remove some comments). Iircc, there are
> other scenarios (such as AdWords) where you would like to keep the
> some comments.
>
> Not sure how to handle this in a general way though.
>
> In this case You can also handle it server side: Req.isIE6
>
> /Jeppe

Obviously, it would be great to make the stripComments variable
session specific where I could leverage something like isIE.  I do see
that FactoryMaker seems to have a session and request specific vending
concept, so this looks promising.  I think the code that actually does
the comment stripping is in LiftMerge, so I'm thinking that that would
need to be enriched too.  Ideally, I would like to see comments that
are not IE specific to be stripped.  (I am unfamiliar with AdWords and
how they use comments.)

Sound like a ticket?

Thanks everybody for the quick help!

-- 
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: Response Optimizations too aggressive

2010-03-04 Thread Jeppe Nejsum Madsen
On Thu, Mar 4, 2010 at 8:47 AM, aw  wrote:
>
> On Mar 3, 10:56 pm, Ross Mellgren  wrote:
>> There's a FactoryMaker in LiftRules that looks like it may do what you want 
>> -- try:
>>
>> LiftRules.stripComments.default = () => false
>>
>> -Ross
>
> This looks promising.  Alas:  error: reassignment to val
>
> (I'm not familiar with FactoryMaker.)  I see that
> LiftRules.stripComments is a val, not a var...  It's unclear to me how
> to override this.


Ahh, think you have to do:

LiftRules.stripComments.default.set(() => false)

/Jeppe

-- 
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: Response Optimizations too aggressive

2010-03-03 Thread aw

On Mar 3, 10:56 pm, Ross Mellgren  wrote:
> There's a FactoryMaker in LiftRules that looks like it may do what you want 
> -- try:
>
> LiftRules.stripComments.default = () => false
>
> -Ross

This looks promising.  Alas:  error: reassignment to val

(I'm not familiar with FactoryMaker.)  I see that
LiftRules.stripComments is a val, not a var...  It's unclear to me how
to override this.

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