help with miva script codes <MvDO>

[clee06]

Hi everyone,

I am new to miva script, and currently trying to learn the basics of it. In the <MvDO> tag below, I don't understand why the the FILE attribute is "g.Module_Library_Utilities"? Can someone please explain it to me.

<MvDO FILE = "{ g.Module_Library_Utilities }" NAME = "l.ok" VALUE = "{ Error( 'MER-MUT-00001', l.error ) }">


From what I have learned from my tutorial, the <MvDO> FILE attribute should be "the path and name of the compiled file"... and the example mivascript.com use was:

<MvDO FILE="myemail.mvc" NAME="g.ok" VALUE="{ SendEmail( to, from, cc, subject, headers, message) }">

So ultimately, what is g.Module_Library_Utilities? how come it does not have the .mvc extension, and could it be a variable instead of a compiled file?

[clee06]

help with miva script codes &lt;MvDO&gt;

Hi everyone, <br>
<br>
I am new to miva script, and currently trying to learn the basics of it. In the &lt;MvDO&gt; tag below, I don't understand why the the FILE attribute is "g.Module_Library_Utilities"? Can someone please explain it to me.<br>
<br>
&lt;MvDO FILE = "{ g.Module_Library_Utilities }" NAME = "l.ok" VALUE = "{ Error( 'MER-MUT-00001', l.error ) }"&gt;<br>
<br>
<br>
From what I have learned from my tutorial, the &lt;MvDO&gt; FILE attribute should be "the path and name of the compiled file"... and the example mivascript.com use was:<br>
<br>
&lt;MvDO FILE="myemail.mvc" NAME="g.ok" VALUE="{ SendEmail( to, from, cc, subject, headers, message) }"&gt; <br>
<br>
So ultimately, what is g.Module_Library_Utilities? how come it does not have the .mvc extension, and could it be a variable instead of a compiled file?

[Bruce - PhosphorMedia]

Re: help with miva script codes &lt;MvDO&gt;

g.Module_Library_Utilities is a global variable that exists in scripts run through the Mechant admin. It equates to something like:

/mm5/5.00/lib/util.mvc

See: http://www.mivascript.com/item/mivas...tags/MvDO.html

[RayYates]

Re: help with miva script codes &lt;MvDO&gt;

Notice the curly brackets around the global variable g.Module_Library_Utilities. Anything between { } is an expression and "myemail.mvc" is a literal string. Merchant initializes a bunch of these global variables that contain the path to it's various components. A partial list is show below.

FILE = "{ g.Module_Library_Utilities }"
FILE="myemail.mvc"

The reason for using the global g.Module_Library_Utilities instead of the literal string for the path "/mm5/5.00/lib/util.mvc" is that all installations of Merchant are not the same. They can change the path in one place and don't have to change every module that uses utility functions.

As you discovered, MvDO lets you call functions that exists within ANY ".mvc" file, but there is also another syntax that is more convent in some cases. Many functions return 0 or 1 (fail or succeed) You can use this syntax inside am MvIF expression or an MvAssign expression.

[g.Module_Library_Utilities].MyFunctionName()

g.merchantpath

g.merchant_api_version

g.merchant_local_timezone

g.merchant_product_type

g.merchant_production_version

g.merchant_update_version

g.merchant_version

g.module_admin

g.module_clientside

g.module_feature_aff

g.module_feature_aff_db

g.module_feature_agr_ad

g.module_feature_agr_db

g.module_feature_att

g.module_feature_att_db

g.module_feature_cus

g.module_feature_cus_db

g.module_feature_cus_rt

g.module_feature_imp_ad

g.module_feature_imp_db

g.module_feature_imp_json

g.module_feature_imp_ut

g.module_feature_inv

g.module_feature_inv_ad

g.module_feature_inv_db

g.module_feature_inv_rt

g.module_feature_pgr_ad

g.module_feature_pgr_db

g.module_feature_prv_ad

g.module_feature_rpd

g.module_feature_rpd_ad

g.module_feature_rpd_db

g.module_feature_rpt_ad

g.module_feature_rpt_db

g.module_feature_rpt_json

g.module_feature_rpt_ut

g.module_feature_sbm_ad

g.module_feature_sbm_db

g.module_feature_sbm_ut

g.module_feature_shp_ad

g.module_feature_shp_db

g.module_feature_shp_json

g.module_feature_shp_ut

g.module_feature_sta_ad

g.module_feature_sta_db

g.module_feature_tui_ad

g.module_feature_tui_db

g.module_feature_tui_mgr

g.module_feature_tui_ut

g.module_feature_upg_ad

g.module_feature_upg_db

g.module_feature_upg_ut

g.module_feature_usl_ad

g.module_feature_usl_db

g.module_feature_usl_rt

g.module_json

g.module_library_billing

g.module_library_billing_db

g.module_library_crypto

g.module_library_db

g.module_library_dbapi

g.module_library_help

g.module_library_native_dbapi

g.module_library_utilities

g.module_merchant

g.module_path

g.module_root

g.module_root_versionless

g.module_store_module_currency

g.module_store_module_tax

g.module_store_module_ui

g.module_upgrade

g.module_version

g.native_dbapi

g.store_table_prefix

[clee06]

Re: help with miva script codes &lt;MvDO&gt;

Thanks for the explanation. I completely ignored the curly brackets around the global variable.

I understand that functions can be past from file to file, but global variables can also be past from file to file?

Is there a way for me to view the functionality of each global variable from that list? I would like to see what kind of value the variables stored and what they do.

[clee06]

Re: help with miva script codes &lt;MvDO&gt;

So global variables can also be past from file to file?

Also, how does the <MvDo> tag knows that g.Module_Library_Utilities is /mm5/5.00/lib/util.mvc?

[RayYates]

Re: help with miva script codes &lt;MvDO&gt;

If you have the Toolbelt module you can add this to a page template. It will display all global variables.

<mvt:item name="ry_toolbelt" param="eval|varlist('g', '', l.all_settings)" />

The newest version on Miva also includes a utility module called Token List. You can use it to display the variables available on any page.

As for Global variables, they are available to all modules and functions as log as the script is executing. When merchant.mvc is called the first thing it does is initialize a bunch of global variables and open a series of database connections. All of these are then available for you to use in your modules, functions and pages.

As soon as the .mvc file exits, all variables are discarded, they are not persistent from page to page, and have to be re-initialized every time merchant.mvc is called.

g.Module_Library_Utilities is simply a path to a specific MivaScript program. There are Hundreds of these files each with Thousands of functions. Get the Limited Source Kit file here

http://www.mivamerchant.com/support/downloads

Each time a new LSK is issued I generate my own html documentation. Follow the instruction found on this page http://www.pcinet.com/docs/MM5_LSK_F...st_PR8_u4.html and you will find the LSK files more user friendly.

[Bruce - PhosphorMedia]

Re: help with miva script codes &lt;MvDO&gt;

When you are running a script IN the admin, or as a module running in store, those variables are available because the Base Code of Merchant creates them before doing anything else.

[RayYates]

Re: help with miva script codes &lt;MvDO&gt;

yea... what he said... :-)

[clee06]

Re: help with miva script codes &lt;MvDO&gt;

thanks, it make sense now.

One last idiotic question, and its a bit off topic.. why is the same name variable used repeatedly, like this? Does it effect the output of the other expressions? the l.oak name is used numerous time throughout the the custom module that i'm learning.

<mvassign name="l.aok" value="{ create_cspshapes() }">
<mvassign name="l.aok" value="{ create_csptypes() }">
<mvassign name="l.aok" value="{ create_cspcat() }">
<mvassign name="l.aok" value="{ create_cspship() }">

[RayYates]

Re: help with miva script codes &lt;MvDO&gt;

Many Functions return 1 if the function succeeds (true) and a zero or null string if it fails (false)

If the function is not accessing the file system, the chances of failure may be so low that the programmer is ignoring it (stuffing it into an unused variable); in this case l.aok

Some programmers use l.trash, some use l.ok. I typically use l.void

If you wanted to trap errors for the entire block of code you could do this.

<MvIF EXPR="{ create_cspshapes() }">
    <MvIF EXPR="{ create_csptypes()  }">
        <MvIF EXPR="{ create_cspcat() }">
            <MvIF EXPR="{ create_cspship() }">
                <MvASSIGN NAME = "l.ok" VALUE="{ 1 }">
            </MvIF>
        </MvIF>
    </MvIF>
</MvIF>


<MvIF EXPR="{ NOT l.ok }">
    <MvCOMMENT> An error occured in there somewhere... </MvCOMMENT>
    <MvFUNCTIONRETURN VALUE="{ 0 }">
</MvIF>


no error, so continue

You can use mvEval to call functions but if it returns a value you will end up printing it to the screen; which may not be desirable.

<MvEVAL EXPR="{ create_cspshapes() }">

[wcw]

Re: help with miva script codes &lt;MvDO&gt;

You might want to change
<MvASSIGN NAME = "l.ok" VALUE="{ 1 }">
to
<MvASSIGN NAME = "l.ok" VALUE="1">

[Bruce - PhosphorMedia]

Re: help with miva script codes &lt;MvDO&gt;

To expand on what Ray said, the one of the main purposes of using the construct:

<mvassign name="l.someVar" value="{ ThisFuction() }">

Is to allow ThisFuction() to run without creating any explicit output. As Ray also suggested, use variables such as l.trash, l.ignore when you don't care what the result of the function is, but use something like "l.hereIsTheResult" when you do care. Just makes code easier to read 3 months (or in my case, 3 hours) from now.

[clee06]

Re: help with miva script codes &lt;MvDO&gt;

gotcha! thanks again everyone for the clarification.

[RayYates]

Re: help with miva script codes &lt;MvDO&gt;

:-)