REQUEST, URL, FORM, OH MY!

[Mark Drew]

A feature suggestion for lucee would be to be able to put all the scopes and things already into the Request scope. It’s an odd scope I guess as from my point of view it should contain things like the URL, FORM, HEADERS, COOKIES in it so you can see what is in it instead of relying on random functions.

What do people think in having (pre-populated):

Request.FORM -> FORM
Request.URL -> URL
Request.HEADER -> getHTTPRequestData()
Request.COOKIE -> COOKIES

It seems (maybe just to me) but that is the correct place for these things?

MD

[Adam Cameron]

Yup, do it!

-- 

Adam

MD

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/7DCC2177-E782-4DAA-86B7-5D7F4361A3BC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Drew]

Err… you mean , should I raise a feature request in the JIRA after proper community conversation and consultation ?

MD

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKfFCUAAo94duTQh3frn-uCK6NXZzxoFHmx85h4VwoZEqg%40mail.gmail.com.

[Ryan Guill]

im for that, and also unioning the form and url scope variables directly into the request scope.  that way you could access them easier for the 99% use case of the two not overlapping, but still get at the variables in the proper place if you need to make the distinction. 

I'd also like to see it shortened to req, but thats personal preference.

[Adam Cameron]

No, f*** it... I'm me, not Micha!

I DEMAND YOU DO IT. AND I DEMAND YOU DO IT NOW!!!!!

(my £500)

-- 

Adam

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/686E74B6-D095-4A7F-88BB-BBFE3AFE8A10%40gmail.com.

[Dave Merrill]

Makes sense to me on a gut level, but you can already do that in Application.cfc, if that's your preference, and clear the original scopes too.

[Mark Drew]

Yarp. It is totally do able but I am thinking of explaining Lucee to  newbee and having a properly filled request scope makes sense to me. 

MD 

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1fc845c7-2499-43e2-89c0-4a245e6b81c1%40googlegroups.com.

[Mark Drew]

For £500 I WILL DO IT! 

MD 

[Adam Cameron]

What are we talking about now?

[Carl Von Stetten]

What is the impact on all the frameworks out there that already combine the FORM and URL stuff into an "rc" variable (FW/1, ColdBox, etc.)?  And would adding HEADER and COOKIE add a bunch of cruft to the request scope that many folks will never (or almost never) use?

-Carl V.

[Jonas Hauß]

+1

[Dominic Watson]

I've always treated the request scope as a scope for variables that are request specific, but *not* provided by external input. Much as PRC is designed for use in ColdBox (and others).

I think it makes perfect sense that way and wouldn't be a fan of changing it.

On 9 February 2015 at 17:15, Jonas Hauß <hauss...@gmail.com> wrote:

+1

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3fbba43b-0aa5-4ccb-aee7-a44cbceeade7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Adam Cameron]

That's *kinda* "let's pretend it's something other than what it's name suggests... you know... *because*". Which is the same rationale I've heard from *everyone* who has an opinion on it.

I think the request scope has been a white elephant since CF5, and it makes sense to "reclaim" it to be something more along the lines that the HTTP spec suggests it might be intended for.

-- 

Adam

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxnZpwaqReSiQRDA1kVSWDRZLwL5%3DFakNGyAf5RbK%3DtUxQ%40mail.gmail.com.

[Patrick Heppler]

+1 for unioning form and url. I already use this in my OnRequestStart()

structAppend(request, url, false);

structAppend(request, form, true);

[Dominic Watson]

No it's not. At all. REQUEST - a scope for storing variables that are specific to, and should stick around for the life of, the REQUEST. That is its intention that I have understood since my very first day with CFML. Having a distinction for the various forms of request *input* is useful. Mixing them into one for your application trivial via Struct append, request.append(), etc.

I'm not dead against having the other scopes mixed in to the request (certainly for it as a feature flag), but I feel that the language would lose some precision by enforcing it and to no great benefit.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFwR%2BKdhmad-%2BU3XiKvyv%2BbqxRAJKmKaNcC%3DQ6Di%3D50zobLS_Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Drew]

OK then can we have a HEADERS scope then rather than explicitly trying to get them with getHTTPRequestData() and for consistency can we then have getHTTPQueryData() and getHTTPPostData() ?

MD

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAEYvUxmhaVg6obxabrRw04AbpSjF-VCe1hAnPhfvV5mzBfEkww%40mail.gmail.com.

[Dominic Watson]

> OK then can we have a HEADERS scope then rather than explicitly trying to get them with getHTTPRequestData() and for consistency can we then
have getHTTPQueryData() and getHTTPPostData() ?

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/E4997BA1-F2C0-4E36-AC08-DCBF471F28DA%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Dominic Watson]

Further to the REQUEST / URL / FORM discussion, I have often thought that the URL and FORM scopes should be read only as is the case with CGI. i.e. you can't change the past. The same could also be said for the ARGUMENTS scope.

Thinking about it further, scopes themselves could then be divided into two categories, reference and storage:

Reference: URL, FORM, CGI, ARGUMENTS

Storage: SERVER, APPLICATION, SESSION, COOKIE, CLIENT, REQUEST, VARIABLES, LOCAL, THREAD...

Of course, this would break a lot of code and not something that could be implemented lightly (should anyone actually agree).

[Cameron Childress]

On Mon, Feb 9, 2015 at 10:15 AM, Mark Drew wrote:

It seems (maybe just to me) but that is the correct place for these things?

I kinda like having the flexibility to do what I want to the URL and FORM scope. Too many codebases already use request scope for something meaningful. I am all for breaking backwards compatibility when it makes sense but this feels like changing things just to be changing them. Besides if you want to stuff them all into the request scope you can already so that if you want wish very few lines of code.

Most frameworks have combined URL and FORM scopes since way back in FB days, but there are valid reasons for having them separate sometimes too.

There are so many other more worthy candidates for change.

-Cameron

 

--

Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[mike...@gmail.com]

I disagree. The scopes are organized more effectively now, separating external input and purposes clearly. I explicitly use the Request scope for variables that need to exist for the life of the request as a result of the application. Making two ways to access the request scope as a standard of the language seems unnecessary and potentially confusing, while it provides no direct convenience, performance, or other gain as far as I can see from your description.

Mike

On Monday, February 9, 2015 at 9:15:23 AM UTC-6, Mark Drew wrote:

[mike...@gmail.com]

Small edit... I meant to say "Making two ways to access the other scopes...."

Sorry for any confusion.