The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
It took me a while to figure out. Experts that I admire and want to be like when I grow up kept saying ”Never ever use thread variables”. But why? They’re handy and needed to pass information along or to store initiated type objects. Right?

Nope.

Here’s an approach that I think is very common in the Lasso community.

We want to store some information that is used on almost every call.

In a site config file that we include on every call we do this

var(dbname = ’myDB’)
var(session_timeout = 1800)
var(sitename = ’My site’)

etc, etc

Convenient since it allows us to then call any of these settings anywhere knowing that they are setup and there.

if($session_timeout > #myvalue) => {
        do this
}

Same with the need to store a type object. The type has to be used further on in the processing so we need to store it somehow. Again it is common to look at thread variables.

On first page
var(myuser = myusertype)

On an included page
$myuser -> name = ’Billy Bong’
$myuser -> age = 32

Another include
$myuser -> name

So, what’s wrong with this approach? It has worked for many years in the Lasso community and there is no other way. Or?

Well, there are several drawbacks. For example
Thread vars are not safe from tampering.
If they don’t supply the answer you’re looking for it can be very hard to bug track where they got the wrong value.
In a fairly complex project it is way to easy to inadvertently overwrite them or use the same name again for something completely different.

But what to do instead? The need to store and pass along data is still there.

Well, I suggest the Ke approach. Named after Ke Carlton, one of the experts I look up to. Ke was the one who introduced me to the concept so I’m assuming he is the origin.

Take a look at this

define session_timeout => var(__session_timeout) or $__session_timeout := 1800

To be used like this

session_timeout

So what are the perks here?
Well, for one, it is not initiated until called for. Unlike the var(session_timeout = 1800) technique that will always create the var regardless if it is actually used on the specific call.

Let’s do a walk thru on what’s happening.

define session_timeout
Is what we do to define a method.

When we call
session_timeout
it will attempt to return the thread variable
var(__session_timeout)
If that variable does not exist it will be created but with a null value.

In comes the conditional check, the ”or” in the definition. Since the result of the newly created var(__session_timeout) is null it will fail the conditional and the code to the right of the ”or” will be triggered.
$__session_timeout := 1800
Here we’re using the short hand call for the var, the dollar sign, since it was just created and there’s no need to create it again.
The := might look daunting (yes, I’m looking at you Kim…) but what it does is a simple assign and return. That is, assign the value 1800 to the var session_timeout and return the var.

So with this approach we can call session_timeout anywhere in our code, not having to worry about if it has been initialized or not and trusting that it will always return the same value.

Same Ke technique can be used to handle type objects.

define myuser => var(__myuser) or $__myuser := myusertype

When we need a myusertype object all we do is call it like this

myuser -> name = ’Billy Bong’
(this will create the object and store the name param Billy Bong in it)

myuser -> age = 32
(same object as before now adding the age param)

myuser -> name

Simple, efficient, safe from tampering and easy to bug track.

Now, there can be picky readers that complain that we are still using thread vars. Yes, you’re right. But, we never expose those vars in our code. Instead they are kept hidden away and thus remains safe and untampered.

Time for supper, I will enjoy it as I hope you will with this Tidbit.

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Marc Pinnell-3
Interesting. Are there realistic speed or memory impacts/savings to this technique over Thread Vars?

Marc


On Mar 27, 2015, at 12:27 PM, Jolle Carlestam <[hidden email]> wrote:

> It took me a while to figure out. Experts that I admire and want to be like when I grow up kept saying ”Never ever use thread variables”. But why? They’re handy and needed to pass information along or to store initiated type objects. Right?
>
> Nope.
>
> Here’s an approach that I think is very common in the Lasso community.
>
> We want to store some information that is used on almost every call.
>
> In a site config file that we include on every call we do this
>
> var(dbname = ’myDB’)
> var(session_timeout = 1800)
> var(sitename = ’My site’)
>
> etc, etc
>
> Convenient since it allows us to then call any of these settings anywhere knowing that they are setup and there.
>
> if($session_timeout > #myvalue) => {
> do this
> }
>
> Same with the need to store a type object. The type has to be used further on in the processing so we need to store it somehow. Again it is common to look at thread variables.
>
> On first page
> var(myuser = myusertype)
>
> On an included page
> $myuser -> name = ’Billy Bong’
> $myuser -> age = 32
>
> Another include
> $myuser -> name
>
> So, what’s wrong with this approach? It has worked for many years in the Lasso community and there is no other way. Or?
>
> Well, there are several drawbacks. For example
> Thread vars are not safe from tampering.
> If they don’t supply the answer you’re looking for it can be very hard to bug track where they got the wrong value.
> In a fairly complex project it is way to easy to inadvertently overwrite them or use the same name again for something completely different.
>
> But what to do instead? The need to store and pass along data is still there.
>
> Well, I suggest the Ke approach. Named after Ke Carlton, one of the experts I look up to. Ke was the one who introduced me to the concept so I’m assuming he is the origin.
>
> Take a look at this
>
> define session_timeout => var(__session_timeout) or $__session_timeout := 1800
>
> To be used like this
>
> session_timeout
>
> So what are the perks here?
> Well, for one, it is not initiated until called for. Unlike the var(session_timeout = 1800) technique that will always create the var regardless if it is actually used on the specific call.
>
> Let’s do a walk thru on what’s happening.
>
> define session_timeout
> Is what we do to define a method.
>
> When we call
> session_timeout
> it will attempt to return the thread variable
> var(__session_timeout)
> If that variable does not exist it will be created but with a null value.
>
> In comes the conditional check, the ”or” in the definition. Since the result of the newly created var(__session_timeout) is null it will fail the conditional and the code to the right of the ”or” will be triggered.
> $__session_timeout := 1800
> Here we’re using the short hand call for the var, the dollar sign, since it was just created and there’s no need to create it again.
> The := might look daunting (yes, I’m looking at you Kim…) but what it does is a simple assign and return. That is, assign the value 1800 to the var session_timeout and return the var.
>
> So with this approach we can call session_timeout anywhere in our code, not having to worry about if it has been initialized or not and trusting that it will always return the same value.
>
> Same Ke technique can be used to handle type objects.
>
> define myuser => var(__myuser) or $__myuser := myusertype
>
> When we need a myusertype object all we do is call it like this
>
> myuser -> name = ’Billy Bong’
> (this will create the object and store the name param Billy Bong in it)
>
> myuser -> age = 32
> (same object as before now adding the age param)
>
> myuser -> name
>
> Simple, efficient, safe from tampering and easy to bug track.
>
> Now, there can be picky readers that complain that we are still using thread vars. Yes, you’re right. But, we never expose those vars in our code. Instead they are kept hidden away and thus remains safe and untampered.
>
> Time for supper, I will enjoy it as I hope you will with this Tidbit.
>
> HDB
> Jolle
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>

Marc Pinnell
1027 Design
PO Box 990872
Redding, CA 96099-0872
530.941.4706
fax: 866.232.5300
www.1027Design.com



#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

decorior
In reply to this post by Jolle Carlestam-2
What is the best way to tie this/store to a session?

We dynamically have to set the database connection through the session.

Deco


> On Mar 27, 2015, at 1:27 PM, Jolle Carlestam <[hidden email]> wrote:
>
> It took me a while to figure out. Experts that I admire and want to be like when I grow up kept saying ”Never ever use thread variables”. But why? They’re handy and needed to pass information along or to store initiated type objects. Right?
>
> Nope.
>
> Here’s an approach that I think is very common in the Lasso community.
>
> We want to store some information that is used on almost every call.
>
> In a site config file that we include on every call we do this
>
> var(dbname = ’myDB’)
> var(session_timeout = 1800)
> var(sitename = ’My site’)
>
> etc, etc
>
> Convenient since it allows us to then call any of these settings anywhere knowing that they are setup and there.
>
> if($session_timeout > #myvalue) => {
> do this
> }
>
> Same with the need to store a type object. The type has to be used further on in the processing so we need to store it somehow. Again it is common to look at thread variables.
>
> On first page
> var(myuser = myusertype)
>
> On an included page
> $myuser -> name = ’Billy Bong’
> $myuser -> age = 32
>
> Another include
> $myuser -> name
>
> So, what’s wrong with this approach? It has worked for many years in the Lasso community and there is no other way. Or?
>
> Well, there are several drawbacks. For example
> Thread vars are not safe from tampering.
> If they don’t supply the answer you’re looking for it can be very hard to bug track where they got the wrong value.
> In a fairly complex project it is way to easy to inadvertently overwrite them or use the same name again for something completely different.
>
> But what to do instead? The need to store and pass along data is still there.
>
> Well, I suggest the Ke approach. Named after Ke Carlton, one of the experts I look up to. Ke was the one who introduced me to the concept so I’m assuming he is the origin.
>
> Take a look at this
>
> define session_timeout => var(__session_timeout) or $__session_timeout := 1800
>
> To be used like this
>
> session_timeout
>
> So what are the perks here?
> Well, for one, it is not initiated until called for. Unlike the var(session_timeout = 1800) technique that will always create the var regardless if it is actually used on the specific call.
>
> Let’s do a walk thru on what’s happening.
>
> define session_timeout
> Is what we do to define a method.
>
> When we call
> session_timeout
> it will attempt to return the thread variable
> var(__session_timeout)
> If that variable does not exist it will be created but with a null value.
>
> In comes the conditional check, the ”or” in the definition. Since the result of the newly created var(__session_timeout) is null it will fail the conditional and the code to the right of the ”or” will be triggered.
> $__session_timeout := 1800
> Here we’re using the short hand call for the var, the dollar sign, since it was just created and there’s no need to create it again.
> The := might look daunting (yes, I’m looking at you Kim…) but what it does is a simple assign and return. That is, assign the value 1800 to the var session_timeout and return the var.
>
> So with this approach we can call session_timeout anywhere in our code, not having to worry about if it has been initialized or not and trusting that it will always return the same value.
>
> Same Ke technique can be used to handle type objects.
>
> define myuser => var(__myuser) or $__myuser := myusertype
>
> When we need a myusertype object all we do is call it like this
>
> myuser -> name = ’Billy Bong’
> (this will create the object and store the name param Billy Bong in it)
>
> myuser -> age = 32
> (same object as before now adding the age param)
>
> myuser -> name
>
> Simple, efficient, safe from tampering and easy to bug track.
>
> Now, there can be picky readers that complain that we are still using thread vars. Yes, you’re right. But, we never expose those vars in our code. Instead they are kept hidden away and thus remains safe and untampered.
>
> Time for supper, I will enjoy it as I hope you will with this Tidbit.
>
> HDB
> Jolle
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
In reply to this post by Marc Pinnell-3
27 mar 2015 kl. 20:35 skrev Marc Pinnell <[hidden email]>:

> Interesting. Are there realistic speed or memory impacts/savings to this technique over Thread Vars?

It would not be slower. And if you do a lot of
var(this = ’that’)
on a config page then probably faster.

I have not used thread vars in the old way for at least a year and a half /two years now and can see no negative sides with the Ke approach.
Would possibly be that it does not play well with Lassos built in session manager. The again. I don’t like the session manager and run my own instead.

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
In reply to this post by decorior
27 mar 2015 kl. 20:36 skrev deco rior <[hidden email]>:

> What is the best way to tie this/store to a session?

I am no fan of the Lasso provided session handler. Instead I run my own and like it a lot more.
It is published for open access here:
https://gist.github.com/jolle-c/02b247b2468073608e17

> We dynamically have to set the database connection through the session.
Why? Is the database different for each visitor? Would that not be a site wide setting?

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

decorior
Hi, Jolle:

yes I use yours :-)

>>
>>
> Why? Is the database different for each visitor? Would that not be a site wide setting?

Yes the database reference is essentially tied to the user session. It is not site wide.

>
> HDB
> Jolle
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
In reply to this post by Jolle Carlestam-2
27 mar 2015 kl. 23:18 skrev Jolle Carlestam <[hidden email]>:

> It would not be slower. And if you do a lot of
> var(this = ’that’)
> on a config page then probably faster.

If you want to look into a variation of the theme, take a look at my replacement for web_request -> param(’myparam’)
https://gist.github.com/jolle-c/d72c8af689cb7e79ccc1

If you call web_request -> param(’myparam’) more than once on a page then using my replacement is definitely faster.

Usage is dead simple.

wrp(’myparam’)

wrp(’mycheckboxparam’, -all) Will return all checkbox type params as a staticarray. Even when no params were found. Thus ensuring that you can trust the result to be an array without having to check for it first.

If you want to grab only from postparams
wrpp(’mypostparam’)

Or for that matter if you’re only interested in queryparams (get params).

wrpq(’mygetparam’)

It is proven to be faster when executing code. But, as a side perk, it is also faster and friendlier to type.
wrp(’myparam’) vs web_request -> param(’myparam’)
I rest my case… :-)

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

decorior
In reply to this post by Jolle Carlestam-2
We use Ke's for parameters

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

French, Shelane
In reply to this post by Jolle Carlestam-2
I also wrote that tag in Lasso 8 which will make the transition to Lasso 9
easier when that day comes.
:-)

On 3/27/15, 3:38 PM, "Jolle Carlestam" <[hidden email]> wrote:

>27 mar 2015 kl. 23:18 skrev Jolle Carlestam <[hidden email]>:
>
>> It would not be slower. And if you do a lot of
>> var(this = ¹that¹)
>> on a config page then probably faster.
>
>If you want to look into a variation of the theme, take a look at my
>replacement for web_request -> param(¹myparam¹)
>https://gist.github.com/jolle-c/d72c8af689cb7e79ccc1
>
>If you call web_request -> param(¹myparam¹) more than once on a page then
>using my replacement is definitely faster.
>
>Usage is dead simple.
>
>wrp(¹myparam¹)
>
>wrp(¹mycheckboxparam¹, -all) Will return all checkbox type params as a
>staticarray. Even when no params were found. Thus ensuring that you can
>trust the result to be an array without having to check for it first.
>
>If you want to grab only from postparams
>wrpp(¹mypostparam¹)
>
>Or for that matter if you¹re only interested in queryparams (get params).
>
>wrpq(¹mygetparam¹)
>
>It is proven to be faster when executing code. But, as a side perk, it is
>also faster and friendlier to type.
>wrp(¹myparam¹) vs web_request -> param(¹myparam¹)
>I rest my caseŠ :-)
>
>HDB
>Jolle
>
>#############################################################
>
>This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
>Official list archives available at http://www.lassotalk.com
>To unsubscribe, E-mail to: <[hidden email]>
>Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
In reply to this post by decorior
27 mar 2015 kl. 23:36 skrev deco rior <[hidden email]>:

> yes I use yours :-)

Well, waddayanow

I poked around to see how I actually do use my session handler. And from what I can tell I never set values from it to anything. I just call them when needed.

I have lots and lots of these
jc_session -> data('a_key’)

And even more of these
jc_session -> permission((:’edit_invoice’, ’view_invoice’)) // will return true if the user has at least one of the permissions

But it looks like I’ve never felt the need to store that in a local or similar.

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

decorior
Yep, that is how we use it too :-)

We pass it right to a DS type and go from there...

One question I heard that Lasso 9 Sessions are now backwards compatible with 8? Is that true?

If not does anyone have a tag to read a Lasso 8 session from MYSQL?

Deco



> On Mar 27, 2015, at 5:03 PM, Jolle Carlestam <[hidden email]> wrote:
>
> 27 mar 2015 kl. 23:36 skrev deco rior <[hidden email]>:
>
>> yes I use yours :-)
>
> Well, waddayanow
>
> I poked around to see how I actually do use my session handler. And from what I can tell I never set values from it to anything. I just call them when needed.
>
> I have lots and lots of these
> jc_session -> data('a_key’)
>
> And even more of these
> jc_session -> permission((:’edit_invoice’, ’view_invoice’)) // will return true if the user has at least one of the permissions
>
> But it looks like I’ve never felt the need to store that in a local or similar.
>
> HDB
> Jolle
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

Jolle Carlestam-2
In reply to this post by French, Shelane
27 mar 2015 kl. 23:41 skrev French, Shelane <[hidden email]>:

> I also wrote that tag in Lasso 8 which will make the transition to Lasso 9
> easier when that day comes.
> :-)

What a joy to read!

I have a humble request to you, Deco and possibly others using my open sourced code. Could you possibly star the ones that you’ve downloaded and are using in github?
It would boost my ego and prompt me to publish more code. And it would boost the presence of Lasso showing the world that there are actually people using it.

HDB
Jolle

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: The better alternative to thread variables - Yet another issue of the highly irregular Non Weekly Lasso Tidbit

decorior
Hi, Shelane:

We are writing a tag that allows a lasso 8 session to be passed in and then converts it to Jolle's session

Is this worth posting?

Deco

> On Mar 27, 2015, at 5:09 PM, Jolle Carlestam <[hidden email]> wrote:
>
> 27 mar 2015 kl. 23:41 skrev French, Shelane <[hidden email]>:
>
>> I also wrote that tag in Lasso 8 which will make the transition to Lasso 9
>> easier when that day comes.
>> :-)
>
> What a joy to read!
>
> I have a humble request to you, Deco and possibly others using my open sourced code. Could you possibly star the ones that you’ve downloaded and are using in github?
> It would boost my ego and prompt me to publish more code. And it would boost the presence of Lasso showing the world that there are actually people using it.
>
> HDB
> Jolle
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>