lasso9 accessing a variable with a variable

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

lasso9 accessing a variable with a variable

Steven McIntosh
Is there a way to access a variable with a variable as the name?

I’ll have a variable as the name of the variable and will need to get the contents. Ideologically it would look something like:

var(test) = ‘something'
var(name) = ‘test’
$($name)

But, of course, this won’t work. I thought about using process, but that isn’t included in L9.

Thoughts?
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Marc Vos-3
var($name)

- -
Regards,
Marc

http://marc.vos.net/
http://nl.linkedin.com/in/mhevos



On 20 aug. 2014, at 23:14, Steven McIntosh <[hidden email]> wrote:

> Is there a way to access a variable with a variable as the name?
>
> I’ll have a variable as the name of the variable and will need to get the contents. Ideologically it would look something like:
>
> var(test) = ‘something'
> var(name) = ‘test’
> $($name)
>
> But, of course, this won’t work. I thought about using process, but that isn’t included in L9.
>
> Thoughts?
> #############################################################
> Attend the Lasso Developer Conference 2014!
> October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
> http://www.lassosoft.com/LDC-newmarket-2014
>
> #############################################################
>
> 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]>

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Steven McIntosh
Thanks Mark—I can’t believe I didn’t try it that way to begin with! I guess I always use that for assigning and not retrieving.

Thanks again,
Steve


On Aug 20, 2014, at 4:22 PM, Marc Vos <[hidden email]> wrote:

> var($name)
>
> - -
> Regards,
> Marc
>
> http://marc.vos.net/
> http://nl.linkedin.com/in/mhevos
>
>
>
> On 20 aug. 2014, at 23:14, Steven McIntosh <[hidden email]> wrote:
>
>> Is there a way to access a variable with a variable as the name?
>>
>> I’ll have a variable as the name of the variable and will need to get the contents. Ideologically it would look something like:
>>
>> var(test) = ‘something'
>> var(name) = ‘test’
>> $($name)
>>
>> But, of course, this won’t work. I thought about using process, but that isn’t included in L9.
>>
>> Thoughts?
>> #############################################################
>> Attend the Lasso Developer Conference 2014!
>> October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
>> http://www.lassosoft.com/LDC-newmarket-2014
>>
>> #############################################################
>>
>> 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]>
>
> #############################################################
> Attend the Lasso Developer Conference 2014!
> October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
> http://www.lassosoft.com/LDC-newmarket-2014
>
> #############################################################
>
> 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]>

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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
|

SV: lasso9 accessing a variable with a variable

Jolle Carlestam-2
Marks solution works as an answer to your question. But it is probably not the answer to your problem.
Dynamic variable names are never the best solution to anything.
I suggest you use a map instead.

HDB
Jolle

________________________________________
Från: [hidden email] [[hidden email]] f&#246;r Steven McIntosh [[hidden email]]
Skickat: den 20 augusti 2014 23:24
Till: [hidden email]
Ämne: Re: lasso9 accessing a variable with a variable

Thanks Mark—I can’t believe I didn’t try it that way to begin with! I guess I always use that for assigning and not retrieving.

Thanks again,
Steve


On Aug 20, 2014, at 4:22 PM, Marc Vos <[hidden email]> wrote:

> var($name)
>
> - -
> Regards,
> Marc
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Ke Carlton-3
In reply to this post by Steven McIntosh
Now that you know it's possible; it's probably a good time to suggest not
using them.

Dynamic variables inevitably cause problems in terms of logic,
pre-compilation validation and depending on how they're used can increase
security risks.

I believe they're most commonly mis-used for storing settings, session
values or worse action params. In this situation I'd recommend using a
single variable with a map container values.

Here's are useful approach which means you never have to address the
variable directly and also not need to worry about it being set or not:

define settings =>  var(__settings)->isa(::map) ? $__settings | $__settings
:= map
define setting(name::string) => settings->find(#name)
define setting=(value::any,name::string) = settings->insert(#name = #value)


Then in your code you will never have to address the variable directly and
you can do things like this:

setting('isadmin') = true

Or:

if(setting('isadmin')) => { /* do this */ }


I take a similar approach to things like user ids or other simple values
likely to be stored in a session. I'll never address the variable directly
because it may mean the code may break if it doesn't exist or is changed.

define user_id => var(__user_id) || 0
define user_id=(value::integer) => var(__user_id = #value)


Then within your code you can do:

if(user_id) ...

Or on login:


user_id = #row(::id)


Why else is this good? well because you're no longer addressing variables
you can add to or change the behaviour without having to change your entire
code base. For example if we wanted to ensure that user_id was stored in
the current session when set we could do something like this:

define user_id=(value::integer) => {
    var(__user_id = #value)
    session_addVar(current_session, '__user_id')
}

And we could make it even smarter like so:

define user_id=(value::integer) => {
    var(__user_id = #value)
    #value
    ? session_addVar(current_session, '__user_id')
    | session_removeVar(current_session, '__user_id')
}

Which would automatically remove the value from the session if set to 0.

So all of the above is probably a bit to much for the solution you're
trying to put in place today — but I'd highly recommend keeping this type
of thinking in mind for future projects as it can save you a world of hurt
and really improve productivity.

Ke

On 21 August 2014 09:24, Steven McIntosh <[hidden email]> wrote:

> Thanks Mark—I can’t believe I didn’t try it that way to begin with! I
> guess I always use that for assigning and not retrieving.
>
> Thanks again,
> Steve
>
>
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Ke Carlton-3
In reply to this post by Jolle Carlestam-2
This is a much more optimal point.

On 21 August 2014 09:40, Jolle Carlestam <[hidden email]> wrote:

> Marks solution works as an answer to your question. But it is probably not
> the answer to your problem.
> Dynamic variable names are never the best solution to anything.
> I suggest you use a map instead.
>
> HDB
> Jolle
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Marc Vos-3
In reply to this post by Jolle Carlestam-2
Did he have a problem?

I use this code for example:

                // !Process action_param values
                iterate(Client_PostParams, local('tmp'));
                        if(! #tmp->first->beginsWith('-') && $p_FIELDS->find(#tmp->first) != Null);
                                $zzVAR1 = string(#tmp->second);
                                $zzVAR1->trim;
                                var('ap_' + $p_FIELDS->find(#tmp->first) = $zzVAR1);
                        /if;
                /iterate;

                // !Test key variables and set default values
                if(! var_defined('ap_LOGID'));
                        var('ap_LOGID' = 0);
                /if;

                ....
                ....


where $p_FiELDS is an array with covert db-column names.

L8 + 9 compatible.

Any suggestions on improving this and still copy/pasteable between L8 and L9? <-- very important

- -
Regards,
Marc



On 20 aug. 2014, at 23:40, Jolle Carlestam <[hidden email]> wrote:

> Marks solution works as an answer to your question. But it is probably not the answer to your problem.
> Dynamic variable names are never the best solution to anything.
> I suggest you use a map instead.
>
> HDB
> Jolle
>
> ________________________________________
> Från: [hidden email] [[hidden email]] f&#246;r Steven McIntosh [[hidden email]]
> Skickat: den 20 augusti 2014 23:24
> Till: [hidden email]
> Ämne: Re: lasso9 accessing a variable with a variable
>
> Thanks Mark—I can’t believe I didn’t try it that way to begin with! I guess I always use that for assigning and not retrieving.
>
> Thanks again,
> Steve
>
>
> On Aug 20, 2014, at 4:22 PM, Marc Vos <[hidden email]> wrote:
>
>> var($name)
>>
>> - -
>> Regards,
>> Marc
> #############################################################
> Attend the Lasso Developer Conference 2014!
> October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
> http://www.lassosoft.com/LDC-newmarket-2014
>
> #############################################################
>
> 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]>

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Ke Carlton-3
I'll bite.

Sure, it's good you're using prefixes to name space your variables —
however chances are you're violating DRY principles and copying and pasting
this everywhere (admittedly this could be an incorrect assumption).

If I was to just rewrite that snippet for both L8 and L9 I would do so like
so:

local(
   'data' = map
);

iterate(client_postparams,local('tmp'));
$p_FIELDS >> #tmp->name
? #data->insert(
#tmp->name = string(#tmp->value)->trim &
);
/iterate;

#data !>> 'LOGID' ? #data->insert('LOGID' = 0);

// Do something else with the #data

However, it's more likely I'd rework it further like so:

local('data') = these_params('get','me','these','thanks');

Although that's also not quite true; as if this was a form updating a table
it would be abstracted further as a type (Lasso 8 or 9).

myform('thetable',array('these','fields','thanks'));

No variables involved, meaning nothing is going to interfere with / break
anything else — in your example if anything sets a var with the same name
that will interfere with the process. Variables bleed outside of their
scope, which effectively means any process using them can be affected by
any other process setting / using them. On a large system this is a
nightmare to manage and debug.

Also, in the myform / these_params examples there's no code repeated which
means I only need to manage / maintain one chunk of code as opposed to
multiple chunks of code splashed through out the system which effectively
do the same thing.

Ke

On 21 August 2014 11:05, Marc Vos <[hidden email]> wrote:

> Did he have a problem?
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Marc Vos-3

On 21 aug. 2014, at 02:56, Ke Carlton <[hidden email]> wrote:

> I'll bite.

:-)

>
> Sure, it's good you're using prefixes to name space your variables —
> however chances are you're violating DRY principles and copying and pasting
> this everywhere (admittedly this could be an incorrect assumption).
>
> If I was to just rewrite that snippet for both L8 and L9 I would do so like
> so:
>
> local(
>   'data' = map
> );
>
> iterate(client_postparams,local('tmp'));
> $p_FIELDS >> #tmp->name
> ? #data->insert(
> #tmp->name = string(#tmp->value)->trim &
> );
> /iterate;
>
> #data !>> 'LOGID' ? #data->insert('LOGID' = 0);

I've thought about using a map, but I personally find it less readable (#data->find('LOGID')  vs $ap_LOGID) and that is why I choose to use vars. I like your shorter code. I'll copy/paste it everywhere ;-)

>
> // Do something else with the #data
>
> However, it's more likely I'd rework it further like so:
>
> local('data') = these_params('get','me','these','thanks');
>
> Although that's also not quite true; as if this was a form updating a table
> it would be abstracted further as a type (Lasso 8 or 9).
>
> myform('thetable',array('these','fields','thanks'));
>
> No variables involved, meaning nothing is going to interfere with / break
> anything else — in your example if anything sets a var with the same name
> that will interfere with the process. Variables bleed outside of their
> scope, which effectively means any process using them can be affected by
> any other process setting / using them. On a large system this is a
> nightmare to manage and debug.

This is exactly my purpose. When I read the table, I have a similar loop to create ap_ vars from the field names with the data from the table.
At the end, the form uses the ap_ vars to display the data. Which means that for the form it doesn't matter where they were created (from).

- -
Regards,
Marc

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Jolle Carlestam-2
In reply to this post by Ke Carlton-3

> 21 aug 2014 kl. 02:56 skrev Ke Carlton <[hidden email]>:
>
> No variables involved, meaning nothing is going to interfere with / break
> anything else — in your example if anything sets a var with the same name
> that will interfere with the process. Variables bleed outside of their
> scope, which effectively means any process using them can be affected by
> any other process setting / using them. On a large system this is a
> nightmare to manage and debug.
>
> Also, in the myform / these_params examples there's no code repeated which
> means I only need to manage / maintain one chunk of code as opposed to
> multiple chunks of code splashed through out the system which effectively
> do the same thing.

Hear, hear!

Or rather; Read, read!

But most importantly; Understand and adopt!


HDB
Jolle

Sent from a thin, flat, touchy device from an undetermined place in space.

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Jolle Carlestam-2
In reply to this post by Marc Vos-3

> 21 aug 2014 kl. 08:10 skrev Marc Vos <[hidden email]>:
>
> I've thought about using a map, but I personally find it less readable (#data->find('LOGID')  vs $ap_LOGID) and that is why I choose to use vars.

Then hide it in a type. Enables you to call it like this:

mydata('LOGID')

If you find that too long then by all means, shorten it.
md('LOGID')

My type is three chars long, wrp('LOGID').


HDB
Jolle

Sent from a thin, flat, touchy device from an undetermined place in space.

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Marc Vos-3


On 21 aug. 2014, at 08:17, Jolle Carlestam <[hidden email]> wrote:

>
>> 21 aug 2014 kl. 08:10 skrev Marc Vos <[hidden email]>:
>>
>> I've thought about using a map, but I personally find it less readable (#data->find('LOGID')  vs $ap_LOGID) and that is why I choose to use vars.
>
> Then hide it in a type. Enables you to call it like this:
>
> mydata('LOGID')
>
> If you find that too long then by all means, shorten it.
> md('LOGID')
>
> My type is three chars long, wrp('LOGID').

There's probably a part of my brain inaccessible today because I tried to understand why I should use a type, but I still don't see the advantage.

- -
Regards,
Marc

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Ke Carlton-3
On 21 August 2014 20:06, Marc Vos <[hidden email]> wrote:

>
> There's probably a part of my brain inaccessible today because I tried to
> understand why I should use a type, but I still don't see the advantage.
>
> Regards,
> Marc


Please excuse long response; my quick response felt like it needed
justification.

What you're probably not seeing is that typically the type will be doing
more than just behaving like a map.

Depending on the behaviour it may update a row / number of rows, validate
the form or any number of other things.

It can mean you go from dozens (hundreds?) of lines of code to a few lines
while accomplishing the same thing.

Going back to the form example, I'm guessing the rest of your code looks
something like this or maybe with arrays for the inline values / actions:

         // !Process action_param values
        iterate(Client_PostParams, local('tmp'));
                if(! #tmp->first->beginsWith('-') &&
$p_FIELDS->find(#tmp->first) != Null);
                        $zzVAR1 = string(#tmp->second);
                        $zzVAR1->trim;
                        var('ap_' + $p_FIELDS->find(#tmp->first) = $zzVAR1);
                /if;
        /iterate;

        // !Test key variables and set default values
        if(! var_defined('ap_LOGID'));
                var('ap_LOGID' = 0);
        /if;


        if($ap_someid);
        inline(-database = 'example',-table = 'whatever',-kevalue =
$ap_someid, '

firstname' = $ap_firstname, 'lastname' = $ap_lastname,-update);

        // more stuff
        /inline'
        else;
        inline(-database = 'example',-table = 'whatever',

'firstname' = $ap_firstname, 'lastname' = $ap_lastname,-add);

          // more stuff

        /inline'

        /if;

        // Then your HTML

Whereas the same approach using a generic form type would look like this,
only one line:

local('survey') = form('thistable', $p_fields)


Everything else is handled by the form. If you want to provide some
defaults, you can add that:

local('survey') = form('thistable', $p_fields, map('logid' = 0))


You wouldn't really even need the $p_fields variable (kept for example) you
could just supply the params as they wouldn't be used anywhere else.

Now instead of copying and pasting dozens+ of lines everywhere; you're
repeating and tweaking just one.

If you want to access the form data further on in the process:

#survey('firstname')


However it can also be more productive to do this:

local('survey') = survey_form


We've created a survey_form type which inherits from the generic form type
— this means it shares all the behaviour without any extra coding. It also
means we can make minor changes and only need to change the bits that are
different. For example we may decides to specify the fields within the type
or default values. In Lasso 9 this would look like this.

define survey_form => type {

parent form

data  table = 'survey',
        fields = array('firstname','lastname','email')

public oncreate => ..oncreate

}


In Lasso 8 it would look something like this:

define_type('survey_form','form',-namespace = );
local(
'table' = 'survey',
'fields' =  array('firstname','lastname','email'),
'variables' = map,
);
/define_type;


Because the form type handles the saving of the data we don't need to
re-code any of that — it just works.

In terms of outputting the form, we can do so numerous ways. Here's one
example:

#survery->asstring('/path/to/the/template/to/use')


However the form example is only really scratching the surface. Once you
start taking this approach (OOP) elsewhere you can start to do thing like
this:

// load objects off session values
local(user) = user(#session_user_id)

// create custom methods
#user->isadmin

// update or create a row
#user->save(
   'something' = 'this'
   'else' = 'that'
)

// delete a user
#user->delete

// Grab a value

#user(::firstname)

#user('firstname')

#user->find('firstname')



The only thing unique about the user type above is the ->isadmin method all
the other functionality would be provided by something like ActiveRow:
https://github.com/zeroloop/ds/wiki/Active-Row

define user => type {
   parent activerow

   public oncreate(id::integer) => .oncreate(::database.users,#id)

   public isadmin => .find('isadmin') == 'yes'
}



It means less code, fewer opportunities for mistakes, the ability to change
behaviour globally without changing performing a find + replace on dozens /
hundreds of files. It also means if there is a problem you only need to fix
it in one place and you know where to look.

Ultimately, if you're happy doing what you're doing there's no reason to
change — I definitely wasn't happy programming in that manner.

Best regards,

Ke
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Jolle Carlestam-2
In reply to this post by Jolle Carlestam-2
21 aug 2014 kl. 08:17 skrev Jolle Carlestam <[hidden email]>:

> Then hide it in a type

This is what happens when you read your list mails while sitting on a chair with a big hole in the seat, producing manure. I missed that Ke had written excellent answer with code examples and all.

For the record, I am using his approach everywhere that I can and I find the code fast, convenient and very manageable.

One thing for example, it saves me from is the habit of creating a lot of settings, variables or temp data storages on every call, regardless if they’re needed or not.

For example.

The classic approach to have some general data prepped would be to have a page full with variable creations that is included in every call.

sertings.inc

var(’m_database’ = ’my_data_base’);
var(’m_user_table’ = ’my_user’);

Thus this is using process cycles on every page visit regardless if any of the variables is ever called.


Here’s the better (Ke) approach, code written for Lasso 9 but same technique can be used in Lasso 8.

Page put in LassoStartup or wherever that creates the definitions at start.

define m_database => var(__m_database) || $__m_database := 'my_data_base'
define m_user_table => var(__user_table) || $__user_table := ’my_user'

If m_user_table is not called on the page then fine, nothing happens. No process cycles are wasted.
On the first call to m_user_table the variable __user_table is created and populated with the proper data. And the content is returned to the caller
For all subsequent calls to m_user_table the content is returned.

Very efficient, very convenient.

And note, the result need not be a simple string. Same approach works with complicated methods or types as well.

define m_databaseobject => var(__m_databaseobject) || $__m_databaseobject := my_complicated_database_type(m_database, m_user_table)

Called like this
m_databaseobject

The above code would equal the old approach:
var(’m_databaseobject’ = my_complicated_database_type($m_database, $m_user_table))

$m_databaseobject

HDB
Jolle

ps, due to issues with my mail, some of my replies did not reach the list, I am resending them now and might appear as I’m out of kilter.
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Jolle Carlestam-2
In reply to this post by Jolle Carlestam-2
21 aug 2014 kl. 08:55 skrev Jolle Carlestam <[hidden email]>:

> Very efficient, very convenient.


One more. Also with a nod to Shelane who was asking about this in another thread. Here’s my take on how to deal with grabbing web_request -> params.


define wrps =>  var(__wrp)->isa(::staticarray) ?
        $__wrp |
        $__wrp := (with p in web_request -> params
                let name = #p->first -> asstring
                let value = #p->second -> asstring
                select pair(#name = #value)) -> asstaticarray

define wrp(name::string) => {
                local(
                        wrp = wrps -> find(#name),
                        wrpsize = #wrp -> size
                )
                if(#wrpsize == 1) => {
                        return #wrp -> get(1) -> second
                else(#wrpsize > 1)
                        return (with p in #wrp select #p -> second) -> asstaticarray
                else
                        return void
                }

}


Usage:
wrp('param')
’<br />'
wrp('params')
’<br />'
wrp('noparam') -> type

Called with
http://myplace.tld/testing.lasso?param=hehe&params=1&params=2

->
hehe
staticarray(1, 2)
void


Credits where credits are due. Note that the whole approach and a lot of the code is stolen fro... (strike that) inspired by Ke.
The with p in web_request -> params section is from a tip by Kyle. The rest is me…

HDB
Jolle

ps, due to issues with my mail, some of my replies did not reach the list, I am resending them now and might appear as I’m out of kilter.
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Marc Vos-3
In reply to this post by Ke Carlton-3
Well, thanks for the examples!

I now know why I do not see the advantage - I find I have to code it all anyway and the type wouldn't be used anywhere else but in the maintenance application it is meant for. Adding and removing on-screen columns and form-fields would mean to every time also update some type which I find more work than updating the '3GL-like' coding style I have now.

One reason for me to choose for the 3GL-style is because that's where I come from and because I code the same solutions on different platforms in different languages. Comparing code between RPG or Lasso or PHP, or even copying code, makes it a lot easier for me if code looks similar.

Currently the user-type, as you show, would make sense - that's one which is coming back in each application.

But the seed is planted.

- -
Regards,
Marc


On 22 aug. 2014, at 02:55, Ke Carlton <[hidden email]> wrote:

> On 21 August 2014 20:06, Marc Vos <[hidden email]> wrote:
>
>>
>> There's probably a part of my brain inaccessible today because I tried to
>> understand why I should use a type, but I still don't see the advantage.
>>
>> Regards,
>> Marc
>
>
> Please excuse long response; my quick response felt like it needed
> justification.
>
> What you're probably not seeing is that typically the type will be doing
> more than just behaving like a map.
>
> Depending on the behaviour it may update a row / number of rows, validate
> the form or any number of other things.
>
> It can mean you go from dozens (hundreds?) of lines of code to a few lines
> while accomplishing the same thing.
>
> Going back to the form example, I'm guessing the rest of your code looks
> something like this or maybe with arrays for the inline values / actions:
>
>         // !Process action_param values
>        iterate(Client_PostParams, local('tmp'));
>                if(! #tmp->first->beginsWith('-') &&
> $p_FIELDS->find(#tmp->first) != Null);
>                        $zzVAR1 = string(#tmp->second);
>                        $zzVAR1->trim;
>                        var('ap_' + $p_FIELDS->find(#tmp->first) = $zzVAR1);
>                /if;
>        /iterate;
>
>        // !Test key variables and set default values
>        if(! var_defined('ap_LOGID'));
>                var('ap_LOGID' = 0);
>        /if;
>
>
>        if($ap_someid);
>        inline(-database = 'example',-table = 'whatever',-kevalue =
> $ap_someid, '
>
> firstname' = $ap_firstname, 'lastname' = $ap_lastname,-update);
>
>        // more stuff
>        /inline'
>        else;
>        inline(-database = 'example',-table = 'whatever',
>
> 'firstname' = $ap_firstname, 'lastname' = $ap_lastname,-add);
>
>          // more stuff
>
>        /inline'
>
>        /if;
>
>        // Then your HTML
>
> Whereas the same approach using a generic form type would look like this,
> only one line:
>
> local('survey') = form('thistable', $p_fields)
>
>
> Everything else is handled by the form. If you want to provide some
> defaults, you can add that:
>
> local('survey') = form('thistable', $p_fields, map('logid' = 0))
>
>
> You wouldn't really even need the $p_fields variable (kept for example) you
> could just supply the params as they wouldn't be used anywhere else.
>
> Now instead of copying and pasting dozens+ of lines everywhere; you're
> repeating and tweaking just one.
>
> If you want to access the form data further on in the process:
>
> #survey('firstname')
>
>
> However it can also be more productive to do this:
>
> local('survey') = survey_form
>
>
> We've created a survey_form type which inherits from the generic form type
> — this means it shares all the behaviour without any extra coding. It also
> means we can make minor changes and only need to change the bits that are
> different. For example we may decides to specify the fields within the type
> or default values. In Lasso 9 this would look like this.
>
> define survey_form => type {
>
> parent form
>
> data  table = 'survey',
>        fields = array('firstname','lastname','email')
>
> public oncreate => ..oncreate
>
> }
>
>
> In Lasso 8 it would look something like this:
>
> define_type('survey_form','form',-namespace = );
> local(
> 'table' = 'survey',
> 'fields' =  array('firstname','lastname','email'),
> 'variables' = map,
> );
> /define_type;
>
>
> Because the form type handles the saving of the data we don't need to
> re-code any of that — it just works.
>
> In terms of outputting the form, we can do so numerous ways. Here's one
> example:
>
> #survery->asstring('/path/to/the/template/to/use')
>
>
> However the form example is only really scratching the surface. Once you
> start taking this approach (OOP) elsewhere you can start to do thing like
> this:
>
> // load objects off session values
> local(user) = user(#session_user_id)
>
> // create custom methods
> #user->isadmin
>
> // update or create a row
> #user->save(
>   'something' = 'this'
>   'else' = 'that'
> )
>
> // delete a user
> #user->delete
>
> // Grab a value
>
> #user(::firstname)
>
> #user('firstname')
>
> #user->find('firstname')
>
>
>
> The only thing unique about the user type above is the ->isadmin method all
> the other functionality would be provided by something like ActiveRow:
> https://github.com/zeroloop/ds/wiki/Active-Row
>
> define user => type {
>   parent activerow
>
>   public oncreate(id::integer) => .oncreate(::database.users,#id)
>
>   public isadmin => .find('isadmin') == 'yes'
> }
>
>
>
> It means less code, fewer opportunities for mistakes, the ability to change
> behaviour globally without changing performing a find + replace on dozens /
> hundreds of files. It also means if there is a problem you only need to fix
> it in one place and you know where to look.
>
> Ultimately, if you're happy doing what you're doing there's no reason to
> change — I definitely wasn't happy programming in that manner.
>
> Best regards,
>
> Ke
> #############################################################
> Attend the Lasso Developer Conference 2014!
> October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
> http://www.lassosoft.com/LDC-newmarket-2014
>
> #############################################################
>
> 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]>

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Steven McIntosh
In reply to this post by Steven McIntosh
Just for the record, I don’t use this in actual programming—I needed a “debug page” that I could go to at any time and see a list of all of the contents of the session variables.

I keep a table of all of the session variables that I use on a project, so I can do a quick debug page that goes through all of the variables I need to view the status of and displays them on one page.


#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

French, Shelane
In reply to this post by Jolle Carlestam-2
Thank Jolle,

I love this expanded version...

I have one suggestion:


define wrp(name::string, last::boolean=false) => {
        local(
                wrp = wrps -> find(#name),
                wrpsize = #wrp -> size
        )
        if(#wrpsize == 1) => {
                return #wrp -> get(1) -> second
        else(#wrpsize > 1 && #last)
                return #wrp -> get(#wrpsize) -> second
        else(#wrpsize > 1)
                return (with p in #wrp select #p -> second) -> asstaticarray
        else
                return void
        }
}

This would allow someone to get the last (can do something similar for
first) param value as a string. I sometimes do (in 8) action_param('nav',
action_param('nav', -count))





On 8/22/14, 12:52 AM, "Jolle Carlestam" <[hidden email]> wrote:

21 aug 2014 kl. 08:55 skrev Jolle Carlestam <[hidden email]>:

> Very efficient, very convenient.


One more. Also with a nod to Shelane who was asking about this in another
thread. Here’s my take on how to deal with grabbing web_request -> params.


define wrps =>  var(__wrp)->isa(::staticarray) ?
        $__wrp |
        $__wrp := (with p in web_request -> params
                let name = #p->first -> asstring
                let value = #p->second -> asstring
                select pair(#name = #value)) -> asstaticarray

define wrp(name::string) => {
                local(
                        wrp = wrps -> find(#name),
                        wrpsize = #wrp -> size
                )
                if(#wrpsize == 1) => {
                        return #wrp -> get(1) -> second
                else(#wrpsize > 1)
                        return (with p in #wrp select #p -> second) -> asstaticarray
                else
                        return void
                }

}


Usage:
wrp('param')
’<br />'
wrp('params')
’<br />'
wrp('noparam') -> type

Called with
http://myplace.tld/testing.lasso?param=hehe&params=1&params=2

->
hehe
staticarray(1, 2)
void


Credits where credits are due. Note that the whole approach and a lot of
the code is stolen fro... (strike that) inspired by Ke.
The with p in web_request -> params section is from a tip by Kyle. The
rest is me…

HDB
Jolle

ps, due to issues with my mail, some of my replies did not reach the list,
I am resending them now and might appear as I’m out of kilter.
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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

#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

Jolle Carlestam-2
22 aug 2014 kl. 17:20 skrev French, Shelane <[hidden email]>:

> Thank Jolle,
>
> I love this expanded version...
>
> I have one suggestion:
>
>
> define wrp(name::string, last::boolean=false) => {
> local(
> wrp = wrps -> find(#name),
> wrpsize = #wrp -> size
> )
> if(#wrpsize == 1) => {
> return #wrp -> get(1) -> second
> else(#wrpsize > 1 && #last)
> return #wrp -> get(#wrpsize) -> second
> else(#wrpsize > 1)
> return (with p in #wrp select #p -> second) -> asstaticarray
> else
> return void
> }
> }
>
> This would allow someone to get the last (can do something similar for
> first) param value as a string. I sometimes do (in 8) action_param('nav',
> action_param('nav', -count))

Feel free to use and expand or tweak all you need. Especially if you publicly state you love what I do. :-)

Personally I would hesitate to implement the expanded version. I use wrp a lot and want to keep it as lean as ever is possible. For the rare occasions I would want a specific count in the provided array I would do that in the call to wrp instead.

wrp(’multiples’) -> last

It is code that is about as short as wrp(’multiples’, true) and at least as easy to read and understand.

And, yes, there are some handy shortcuts when calling array items.

#myarray -> first
#myarray -> second
#myarray -> last // handier than #myarray -> get(#myarray -> size)


HDB
Jolle
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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: lasso9 accessing a variable with a variable

French, Shelane
Go ahead and keep yours lean.

wrp(’multiples’) -> last only works if you know you have multiples. ->last won't come out well with a string. I know it's an extra condition, but one I'm willing to make.

Going to the point you told me during our conversation, I definitely see where 9 has the advantage over 8 with this.



Sent with Good (www.good.com)


-----Original Message-----
From: Jolle Carlestam [[hidden email]<mailto:[hidden email]>]
Sent: Friday, August 22, 2014 09:23 AM Pacific Standard Time
To: [hidden email]
Subject: Re: lasso9 accessing a variable with a variable


22 aug 2014 kl. 17:20 skrev French, Shelane <[hidden email]>:

> Thank Jolle,
>
> I love this expanded version...
>
> I have one suggestion:
>
>
> define wrp(name::string, last::boolean=false) => {
>       local(
>               wrp             = wrps -> find(#name),
>               wrpsize         = #wrp -> size
>       )
>       if(#wrpsize == 1) => {
>               return #wrp -> get(1) -> second
>       else(#wrpsize > 1 && #last)
>               return #wrp -> get(#wrpsize) -> second
>       else(#wrpsize > 1)
>               return (with p in #wrp select #p -> second) -> asstaticarray
>       else
>               return void
>       }
> }
>
> This would allow someone to get the last (can do something similar for
> first) param value as a string. I sometimes do (in 8) action_param('nav',
> action_param('nav', -count))

Feel free to use and expand or tweak all you need. Especially if you publicly state you love what I do. :-)

Personally I would hesitate to implement the expanded version. I use wrp a lot and want to keep it as lean as ever is possible. For the rare occasions I would want a specific count in the provided array I would do that in the call to wrp instead.

wrp(’multiples’) -> last

It is code that is about as short as wrp(’multiples’, true) and at least as easy to read and understand.

And, yes, there are some handy shortcuts when calling array items.

#myarray -> first
#myarray -> second
#myarray -> last // handier than #myarray -> get(#myarray -> size)


HDB
Jolle
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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]>
#############################################################
Attend the Lasso Developer Conference 2014!
October 1-3, 2014 at Treefrog HQ, Newmarket, Ontario, Canada
http://www.lassosoft.com/LDC-newmarket-2014

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

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]>
12