[server] using STACKS within ON-REV

Pierre Sahores psahores at free.fr
Mon Aug 1 14:20:05 EDT 2011


Hi Friends,

Is there some special precautions to take in about global variables management and share between lc flat scripts and the stacks libs referenced on top of the lc script ?

My habit is to declare all my global vars on top of both the lc scripts (witch works fine) :

> global var1,var2,etc...
> 
> function onef params
> ...
> end onef
> 
> function twof
> ...
> end twof
> 
> command onec
> ...
> end onec
> 

and in the stack script (lib)

witch don't seems to be seen by the lc script after i include 

> start using stack <path to stack>


while the stack is clearly well seen by the script (functions no using vars are well executed by the lc script)

Where am i wrong and what means that the globals are not dynamically viewable in between the lc scripts and stack-lib.livecode library ?

Thanks for any help.

I hope not to have to declare each global used by the stack lib below each function / command declaration alike this

> function onef
> 	global var1
> 	...
> end onef


Kind regards,

Pierre


Le 1 août 2011 à 19:30, J. Landman Gay a écrit :

> On 8/1/11 10:40 AM, Robert Mann wrote:
> 
>> This is the very simple test I made :: made a simple "teststack.livecode" in
>> the IDE : it contains 3 cards and 3 fields, and a few test functions.
>> Dropped it in a test folder on my on-rev account, and added an index.lc file
>> at the same level.
>> 
>> problems ::
>> 
>> 1) go stack DOES NOT work
>> 
>> 2) start using stack, seems to swallow all handlers from stackTest into the
>> HOME stack, so that they loose all the context of their original stack.
>> 
>> 3) fields on cards can be accessed IF THE name of the stack is precised each
>> time.
>> 
>> So that requires to write handlers in a different way,  a standard stack
>> will break very easily on the server if an implicit ref. to a field is used.
>> 
>> Any comment? Do I get it right? does "go stack work for some?
> 
> These things have always been true of all server-related syntax, including the old CGI method. "Go" is a GUI command, and includes an instruction to redraw a card. The server has no GUI, so a redraw throws an error. Instead of "go", just reference the card remotely.
> 
> Long object names have also always always been required for all server work. The rule of thumb is to always use long object names, never try to navigate within a stack, and always use remote references:
> 
>  go card 1 -- fails
>  go stack "testStack" -- fails
>  get the text of field 1 of card 1 of stack "testStack" -- works
> 
> The "start using" command has also always been required. It is the only way to implement a library script on a server.
> 
> I don't think there is a Home stack on a server; there are only libraries that sit behind the web page in the hierarchy.
> 
> From my old CGI tutorial <http://www.hyperactivesw.com/cgitutorial/scripts1.html#trouble>:
> 
> <quote>
> Some native Revolution commands that don't work (and may hang your script) are:
> 
>    go - requires a GUI window redraw
>    toplevel - GUI-based
>    modeless (or any other stack modes) - GUI-based
>    create stack (or any file creation) - CGI permissions restriction
>    save stack (errors with "can't open stack backup file") - permissions restriction
>    beep - GUI-based
> </quote>
> 
> I haven't worked with the new server yet, but since the current directory on the server is outside the CGI-bin folder, creating new stacks and files would be possible, unlike the old CGI method in the tutorial.
> 
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.woooooooords.com
www.sahores-conseil.com








More information about the Use-livecode mailing list