S.uri in AJAX

[Andreas Joseph Krogh]

Hi all.

 

I'm kind of annoyed that S.uri returns /lift/ajax/F1210181871645985ET2-30/ in AJAX-requests.

Do we really want this? Is this needed anywhere by the framework it self?

 

I would expect to get the original value from the first (page)request.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

[Antonio Salazar Cardozo]

I find this to be expected, but I understand why it might not be. Regardless, all

interactions in AJAX requests that are interested in the original request should

already be addressing `S.originalRequest`, whose purpose is explicitly called

out in the docs as having, amongst other things, ‘the original path’.

We can add an S.originalUri, I guess? But there are plenty of other methods we'd

need to duplicate in that case. It feels like requiring that one use S.originalRequest

in these cases makes sense.

Thanks,

Antonio

[Andreas Joseph Krogh]

På lørdag 03. februar 2018 kl. 17:30:46, skrev Antonio Salazar Cardozo <savedf...@gmail.com>:

I find this to be expected, but I understand why it might not be. Regardless, all

interactions in AJAX requests that are interested in the original request should

already be addressing `S.originalRequest`, whose purpose is explicitly called

out in the docs as having, amongst other things, ‘the original path’.

 

We can add an S.originalUri, I guess? But there are plenty of other methods we'd

need to duplicate in that case. It feels like requiring that one use S.originalRequest

in these cases makes sense.

Thanks,

Antonio

 

To ask in another way; What is the purpose of returning anything but the original request's values when calling stuff like S.uri?

 

The goal must be that calling S.locale, S.uri etc. should return the same value whether called in a regular request, AJAX or Comet, right? If no, why?

[Andreas Joseph Krogh]

På søndag 04. februar 2018 kl. 10:42:01, skrev Andreas Joseph Krogh <and...@visena.com>:

På lørdag 03. februar 2018 kl. 17:30:46, skrev Antonio Salazar Cardozo <savedf...@gmail.com>:

I find this to be expected, but I understand why it might not be. Regardless, all

interactions in AJAX requests that are interested in the original request should

already be addressing `S.originalRequest`, whose purpose is explicitly called

out in the docs as having, amongst other things, ‘the original path’.

 

We can add an S.originalUri, I guess? But there are plenty of other methods we'd

need to duplicate in that case. It feels like requiring that one use S.originalRequest

in these cases makes sense.

Thanks,

Antonio

 

To ask in another way; What is the purpose of returning anything but the original request's values when calling stuff like S.uri?

 

The goal must be that calling S.locale, S.uri etc. should return the same value whether called in a regular request, AJAX or Comet, right? If no, why?

 

Just to follow up; I have lots of code which is used on different contexts (AJAX, Comet, regular requests) and that code doesn't, and shouldn't, know (and have to test for) what context it's used in. Lift should provide a uniform, and safe/predictable, way of accessing these values (in S) so it works regardless of context.

[Joe Barnes]

Andreas,

Do you get the context-free information you need with S.originalRequest? Changing the existing behavior of S.uri etc would a thoroughly breaking change. I don't see how we could do better than waiting until Lift 4.0 if we decided we wanted to make this change.

Regardless of breaking stuff... Just going on my gut here... I suspect that applications would benefit from the behavior you want, but may be of detriment to Lift modules if not Lift itself as you already asked about. The context-dependent information/behavior available today is a vital detail at times for modules since they need to know more about the internals, whereas an application tends to need to be shielded against those details.

Joe

/**

 * Joe Barnes

 * Owner/Principal Consultant, joescii, llc

 * 256.541.0377

 * j...@joescii.com

 */

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Joseph Krogh]

På mandag 05. februar 2018 kl. 16:42:50, skrev Joe Barnes <j...@joescii.com>:

Andreas,

 

Do you get the context-free information you need with S.originalRequest? Changing the existing behavior of S.uri etc would a thoroughly breaking change. I don't see how we could do better than waiting until Lift 4.0 if we decided we wanted to make this change.

 

Regardless of breaking stuff... Just going on my gut here... I suspect that applications would benefit from the behavior you want, but may be of detriment to Lift modules if not Lift itself as you already asked about. The context-dependent information/behavior available today is a vital detail at times for modules since they need to know more about the internals, whereas an application tends to need to be shielded against those details.

 

I fail to come up with a use-casee where returning

/lift/ajax/F571393189510ZI7TAD/
/lift/comet/85998224469/F571393172519AJUGOO/F571393189510ZI7TAD
 

from S.uri, rather than the original-request's URI, is useful. Can you?

Any lift-modules depending on existing behavior?

[Joe Barnes]

I do not know of a use case or of any Lift modules depending on it. You very well could be right that there isn't any code which happily depends on the current behavior.

To restate my position: If S.originalRequest gets what you need (I'm not sure if it does or not), then changing S.uri etc is probably riskier than its worth especially before Lift 4.x. The reason I brought up modules is that in my experience I tend to use the lower-level API calls available to Lift (such as knowing the exact ajax or comet request although that exact thing I've not yet needed) that I otherwise never need during application development. I certainly don't mean to suggest you are wrong in your assessment, but I want to make sure we're considering more than just application development use cases.

Joe

/**

 * Joe Barnes

 * Owner/Principal Consultant, joescii, llc

 * 256.541.0377

 * j...@joescii.com

 */

--

[Matt Farmer]

FWIW, I use req.uri in lift-newrelic to report comet requests differently to newrelic: https://github.com/farmdawgnation/lift-newrelic/blob/master/src/main/scala/me/frmr/newrelic/NewRelicBootstrap.scala

This demonstrates a use case where one may, outside of the comet implementation itself, want to determine if the request being processed is a comet request or some other kind of request for reporting purposes.

<Mail Attachment.png>

 

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Andreas Joseph Krogh]

På onsdag 07. februar 2018 kl. 06:02:32, skrev Matt Farmer <ma...@frmr.me>:

FWIW, I use req.uri in lift-newrelic to report comet requests differently to newrelic: https://github.com/farmdawgnation/lift-newrelic/blob/master/src/main/scala/me/frmr/newrelic/NewRelicBootstrap.scala

 

This demonstrates a use case where one may, outside of the comet implementation itself, want to determine if the request being processed is a comet request or some other kind of request for reporting purposes.

 

Righ. Maybe we want some S.page object which holds values specific to the "page", ie. the same scope as RequestVars? This way we may say S.page.uri, or is the use-case too narrow?

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[Matt Farmer]

Sorry, that strikes me as more confusing than the current situation.

--

[Andreas Joseph Krogh]

På onsdag 07. februar 2018 kl. 14:07:38, skrev Matt Farmer <ma...@frmr.me>:

Sorry, that strikes me as more confusing than the current situation.

 

What I'm missing is some uniform way of getting "what is the URI of the current page" regardless if it's a reqular request, AJAX or Comet. I often reuse components and they don't know in what context they're used (they shouldn't) and as of current there's no way to get the "current page's URI" in a uniform way. I think S.uri should provide this, and if you actually want the "low-level" URI of AJAX/Comet that should be a separate call.

[Matt Farmer]

Does S.originalRequest not get you that? I think Antonio and Joe both asked that - did I miss the answer?

--

[Antonio Salazar Cardozo]

Yes, S.originalRequest should do this.

That said, I do think some thinking should be done on what gets exposed where. Right

now S.uri refers to the current request, but much of Lift's code is written to make AJAX vs

comet vs original page transparent to code. The S singleton often mixes high-level and

low-level concerns, which I think is why we get into some of this hot water.

The best solution may be a couple of helpers that are designed for primary use if you're

looking for page info vs request info. I don't know that we'd want to further clutter S with

this, but rather have some objects that look into S to get their data and expose a consistent

API concerned with their particular use case.

This would also provide a clean upgrade path, since it wouldn't require any hacking around

S, etc.

Thanks,

Antonio

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.