Using includes in a stack script

[shawnblc]

Can you use includes on a stack script? I can't find any documentation on this - only for server.

[Klaus]

Hi Shawn,

yes, but with this syntax:
...
start using stack "your_library_Stack_here
...
Or:
...
insert script of XYZ into Front/Back
...
Look up theses terms in the dictionary.


Best

Klaus

[dunbarx]

Hi.

The docs say only on server.

Can you tell me why you would want to?

Craig Newman

[dunbarx]

Klaus is suggesting a way to include scripts into the message path, creating a library that can be accessed everywhere. These are taken from stacks or scripts already within LC.

But the "include" command addresses an external file, presumably containing text that can be parsed into a valid script, and brings that into the fold. Is that still what you wanted?

Craig

[shawnblc]

Klaus is suggesting a way to include scripts into the message path, creating a library that can be accessed everywhere. These are taken from stacks or scripts already within LC.

But the "include" command addresses an external file, presumably containing text that can be parsed into a valid script, and brings that into the fold. Is that still what you wanted?

Craig

Yes. Say if I have a stack that is password protected, but want to include code in it that could be changed I could have one stack that has what can be changed and have an include to include it.

For instance ... database parameters could be updated in a file and included in my password protected stack.

[dunbarx]

Shawnbic

Do you want to "include" script changes or data changes? Both? It matters how you go about this. If you have a backscript or library stack in use, these can be used to manage changes in your locked stack script. But this requires careful management. Or do you simply want to store all scripts in an accessible stack, leaving the stack script of the locked stack alone?

Craig

[shawnblc]

Shawnbic

Do you want to "include" script changes or data changes? Both? It matters how you go about this. If you have a backscript or library stack in use, these can be used to manage changes in your locked stack script. But this requires careful management. Or do you simply want to store all scripts in an accessible stack, leaving the stack script of the locked stack alone?

Craig

Not sure I understand your questions right (still a newbie), but let me try and explain what I'm trying to do.

I have a locked stack. In that stack I have my database parameters. If I want to share this stack I want this information to be able to be changed by others, but not see my information. So if I had another stack that I could include this information, they could fill it out and replace my information or maybe use some type of variables???? If I pass my stack off to someone else I want them to be able to 1) of course create their own database (which is no problem), and 2) enter their information.

put "database_url" into tDatabaseAddress
put "database_table" into tDatabaseName
put "database_user" into tDatabaseUser
put "database_password" into tDatabasePassword

[Simon]

Hi shawnblc,
Just jumping in here.
For user controled info wouldn't you use fields?
put field "database_url" into tDatabaseAddress
put field "database_table" into tDatabaseName
put field "database_user" into tDatabaseUser
put field "database_password" into tDatabasePassword

Simon

[shawnblc]

Hi shawnblc,
Just jumping in here.
For user controled info wouldn't you use fields?
put field "database_url" into tDatabaseAddress
put field "database_table" into tDatabaseName
put field "database_user" into tDatabaseUser
put field "database_password" into tDatabasePassword

Simon

I guess I could go that route. Makes sense to me. I'll give it a whirl. It'd be just as easy to do that. Thanks for the suggestion. Guess I kind of hand that one way stuck in my head trying to learn something new

[dunbarx]

Simon is usually very insightful.

Going further, if you stick to a single stack, you can hide your information in many ways, with or without encryption, in custom properties or on cards that require a password to access. So you can allow access to parts of your stack, but hide or lock others.

That said, a substack or another stack entirely is still not out of the question as a good way forward. The stacks can communicate in any way you want, the open stack exporting to the locked one as needed.

Craig

[shawnblc]

@Simon - your idea definitely works for what I was trying to relay in my post.

@dunbarx - I'll try your idea too, sounds like it's yet another way to achieve what I was trying to relay in my post.

So if I understand dunbarx correct. I can hide information in a substack and it's hidden unless I call that substack? So if I used on mouseUP go to stack substack then obviously it would no longer be hidden. Is this what you mean?

[Simon]

Hey shawnblc,
Glad I understood what you wanted... sometimes I don't get these thing right.

Simon

[dunbarx]

So if I understand dunbarx correct. I can hide information in a substack and it's hidden unless I call that substack? So if I used on mouseUP go to stack substack then obviously it would no longer be hidden. Is this what you mean?

Something like that. You can go to the "locked" stack in many ways, and you can always require a password to do so. For example, if you had a secret code, stored perhaps in a custom property of the stack, you could, perhaps in a button named "Go to Secret Stack"

Code: Select all

on mouseUp
   ask "Enter password"
   if it is not the superPassword of this stack then
      answer "Access denied"
      exit to top
   else
      go stack "yourLockedStack"
   end if
end mouseUp

So many ways to do this. I still think it would be more compact if you can keep it all in one stack, though, with your special data hidden in either a custom property, a hidden field(s), a card that requires a password to open, or whatever, as was suggested earlier. I like to use one stack instead of many wherever possible.

Craig

[shawnblc]

Craig, thanks for the clarification. Excellent suggestions.