File include in Miva?

File include in Miva?



On Thu, 3 Mar 2005 17:04:02 -0500, Andrew Noce
<[email protected]> wrote:
> Hmmmm...
>
> So what is the scope of variables and functions for scripts executed
> with MvDo?

If you MvDO a file, only code outside of functions is run, unless that
code calls a function, the functions are ignored.

If you MvDO a function, it's pretty much the opposite. Code outside
the function is completely ignored, as are other functions that aren't
called.

> You are saying they are global to the parent script, and therefore the
> MVDo is an equivalent to the include?

Yes, it is, but with the limits stated above.

> Sorry for the academic questions, I'm quite a bit rusty and keep getting
> my VBSCRIPT which I use daily mixed up with my MvScript, which I never
> use.
>
> But it's an interesting subject, anyway. Let me take it a step
> further... For those of you with extensive programming knowledge, what
> is it that keeps you working with MivaScript as opposed to moving to

This where my income is. Demand for miva development far outstrips
supply - at least that's how it looks to me.

> some other more sophisticated language? Is it the Merchant market alone,
> or the nostalgia for the language, or do you really feel it is as
> sophisticated as perl, asp, .net, php, ruby, etc.?

For me, it's the Merchant market. For pure coding fun, and for tools
that help make building miva code easier, I use Ruby.

> Miva excels in it's simplicity but I would imagine outside the Merchant
> market it would hold little other value for experienced programmers.

I'd say that's been true for years. I'm hoping (expecting?) that
with the next release, it'll jump up a class or two in the ranks of
web languages.

--
Bill Guindon (aka aGorilla)

File include in Miva?



From: Bill Guindon

>> Miva excels in it's simplicity but I would imagine outside the Merchant
>> market it would hold little other value for experienced programmers.

> I'd say that's been true for years. I'm hoping (expecting?) that
> with the next release, it'll jump up a class or two in the ranks of
> web languages.

I would actually tell the exact opposite: Miva Script is not only extremely
easy to learn, but in spite of its simplicity it is also unusually
efficient. For long years, I used Miva Script exclusively in non-Merchant
market. I could write (and still do sometimes) applications driving huge
dynamically driven websites within hours, where a designer doing the same
work in plain HTML or using another scripting language usually needed days
and weeks.

Honestly told, I would much more prefer if Miva developers concentrated on
improving the performance and stability of the engine, rather than adding
too many new features. From all the new features we saw in the last 2-3
years, at least 50% of them were completely redundant, just adding
unnecessary complexity to the language and slowing down the engine, without
bringing anything that would not be possible before. I know I am
old-fashioned, but I personally love minimalist low level programming in
language that I know perfectly, than programming with an overbloated
language, where you have barely chance to learn, try, or even just look at
5% of the instructions in all your life. I yet have to encounter a task that
would not be possible with Miva Script (well, maybe sometimes a small trick
or help from an external tool is needed, but that's still a very good trade
off)

Ivo
http://mivo.truxoft.com

File include in Miva?



MvINCLUDE is not a fancy function. It is used by the compiler -- at =
compile
time it adds the mvinclude file to your script. You must reference the
actual file location on your hard disk for this to work.

Example:
<MvINCLUDE FILE =3D"c:Devfile.mv"> (un-compiled file)

Also, do not use spaces in the MvINCLUDE. The compiler does not handle
spaces in the source file name (at least from my experience).

If you use MvINCLUDE, all the functions referenced will be local to the
script, thereby eliminated the need to MvDO (as has already been said).

HTH,

Ben

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Ivo Truxa
> Sent: Thursday, March 03, 2005 2:43 PM
> To: 'miva-users'
> Subject: RE: [meu] File include in Miva?
>=20
> From: Bill Guindon [mailto:[email protected]]
>=20
> > Ok, I'll change my comment to "It would be great if the had an
> > 'include', and the actually documented it".
>=20
> As many other new functions and features, it _is_ documented in the
> Release
> Notes :) In Miva v4, reading the Notes is obligatory if you want to =
use
> all
> its features. I believe Miva hired a new person who works on new
> documentation, though anyway.
>=20
>=20
> >> There is no need for even with MvDO. Just declare the functions =
once in
> each
> >> file (just like in many other programming languages) and then you =
can
> call
> >> them directly as much as you want. I have common libraries and use =
this
> >> technique all over all my Miva Script files.
>=20
>=20
> > You mean copy/paste the functions? Or wrap the MvDO with local
> functions?
>=20
> Of course not, you then do not need any libraries :) As I wrote, =
simply
> just
> declare the functions:
>=20
> <MvFUNCTION...><MvDO..><MvFUNCRETURN...></MvFUNCTION>
> <MvFUNCTION...><MvDO..><MvFUNCRETURN...></MvFUNCTION>
> ...
> <MvFUNCTION...><MvDO..><MvFUNCRETURN...></MvFUNCTION>
>=20
> > I can see that wrapping them makes them appear local, but
> > it's a bit tedious.
>=20
> No really. Takes just couple of lines at the top of each file. Fast =
and
> easily done. Real includes would save the file access in run time, but =
on
> the other hand they would then bloat the file size unnecessarily - if =
you
> have libraries with big number of functions, where you usually use =
just a
> limited part of them, including them in the above way may prove more
> efficient.
>=20
> Ivo
> http://mivo.truxoft.com
>=20
>=20
>=20
>=20

File include in Miva?



I hardly do any work for the Merchant market, yet I use Mivascript
exclusively for development (well, along with a bit of javascript).
It's fast, easy, and powerful. I used to script in C/C++, perl, php,
and even asp, but when I first found mivascript (htmlscript) I realized,
even without really knowing the language, I could do somethign in two
hours that might have taken all day otherwise.

The only thing that keeps it from being a more widely used language is
that the initiation fee is more than the local tennis club when it comes
to licensing fees for the compiler and such. When PHP and other
languages are completely free, there are few developers who will switch
over to mivascript when it's more expensive and not as widely supported.

Then again, that's good for developers who are making a living doing
mivascript- not as much competition :) The language will continue to
grow as Miva Merchant grows (and there's some really good stuff just
around the corner).

Scot


Andrew Noce wrote:
> Hmmmm...
>
> So what is the scope of variables and functions for scripts executed
> with MvDo?
> You are saying they are global to the parent script, and therefore the
> MVDo is an equivalent to the include?
>
> Sorry for the academic questions, I'm quite a bit rusty and keep getting
> my VBSCRIPT which I use daily mixed up with my MvScript, which I never
> use.
>
> But it's an interesting subject, anyway. Let me take it a step
> further... For those of you with extensive programming knowledge, what
> is it that keeps you working with MivaScript as opposed to moving to
> some other more sophisticated language? Is it the Merchant market alone,
> or the nostalgia for the language, or do you really feel it is as
> sophisticated as perl, asp, .net, php, ruby, etc.?
>
> Miva excels in it's simplicity but I would imagine outside the Merchant
> market it would hold little other value for experienced programmers.
>
>
> Andrew Noce
>
>
>
>
>>-----Original Message-----
>>From: Ivo Truxa [mailto:[email protected]]
>>Sent: Thursday, March 03, 2005 4:30 PM
>>To: 'miva-users'
>>Subject: RE: [meu] File include in Miva?
>>
>>
>>From: Andrew Noce [mailto:[email protected]]
>>
>>
>>>But, Ivo, what would you do if a global function changes?
>>
>>Absolutely nothing :)
>>
>>(unless you change the name or the number of arguments, in
>>which case you have to rewrite the script using the function anyway :)
>>
>>Ivo
>>http://mivo.truxoft.com
>>
>>
>>
>>>Now you need to go into several separate scripts and update
>>
>>them each,
>>
>>>instead of making the change to one file.
>>
>>
>>
>>

File include in Miva?



Well,=20

I see, and remember now, how Miva functions/MvDO, MvInclude work.

This is an interesting conversation. Ever since I began working with
ASP, I have been wanting to do a comparison between Mv and ASP.
It looks like MvInclude is actually more convenient then ASP
server.execute() because it allows dynamic includes which scope
variables locally, like ASP include function, but allows dynamic file
name, not possible with ASP include.

Interesting... On another occasion I will attempt to compare this model
to the much more excellent .NET VB methods.



Andrew Noce=20

=20



> -----Original Message-----
> From: Scot Ranney [mailto:[email protected]]=20
> Sent: Thursday, March 03, 2005 8:48 PM
> To: Andrew Noce
> Cc: miva-users
> Subject: Re: [meu] File include in Miva?
>=20
>=20
> I hardly do any work for the Merchant market, yet I use Mivascript=20
> exclusively for development (well, along with a bit of javascript).=20
> It's fast, easy, and powerful. I used to script in C/C++, perl, php,=20
> and even asp, but when I first found mivascript (htmlscript)=20
> I realized,=20
> even without really knowing the language, I could do somethign in two=20
> hours that might have taken all day otherwise.
>=20
> The only thing that keeps it from being a more widely used=20
> language is=20
> that the initiation fee is more than the local tennis club=20
> when it comes=20
> to licensing fees for the compiler and such. When PHP and other=20
> languages are completely free, there are few developers who=20
> will switch=20
> over to mivascript when it's more expensive and not as widely=20
> supported.
>=20
> Then again, that's good for developers who are making a living doing=20
> mivascript- not as much competition :) The language will continue to=20
> grow as Miva Merchant grows (and there's some really good stuff just=20
> around the corner).
>=20
> Scot
>=20
>=20
> Andrew Noce wrote:
> > Hmmmm...
> >=20
> > So what is the scope of variables and functions for scripts=20
> executed=20
> > with MvDo? You are saying they are global to the parent script, and=20
> > therefore the MVDo is an equivalent to the include?
> >=20
> > Sorry for the academic questions, I'm quite a bit rusty and keep=20
> > getting my VBSCRIPT which I use daily mixed up with my=20
> MvScript, which=20
> > I never use.
> >=20
> > But it's an interesting subject, anyway. Let me take it a step=20
> > further... For those of you with extensive programming=20
> knowledge, what=20
> > is it that keeps you working with MivaScript as opposed to=20
> moving to=20
> > some other more sophisticated language? Is it the Merchant market=20
> > alone, or the nostalgia for the language, or do you really=20
> feel it is=20
> > as sophisticated as perl, asp, .net, php, ruby, etc.?
> >=20
> > Miva excels in it's simplicity but I would imagine outside the=20
> > Merchant market it would hold little other value for experienced=20
> > programmers.
> >=20
> >=20
> > Andrew Noce
> >=20
> >=20
> >=20
> >=20
> >>-----Original Message-----
> >>From: Ivo Truxa [mailto:[email protected]]
> >>Sent: Thursday, March 03, 2005 4:30 PM
> >>To: 'miva-users'
> >>Subject: RE: [meu] File include in Miva?
> >>
> >>
> >>From: Andrew Noce [mailto:[email protected]]
> >>
> >>
> >>>But, Ivo, what would you do if a global function changes?
> >>
> >>Absolutely nothing :)
> >>
> >>(unless you change the name or the number of arguments, in
> >>which case you have to rewrite the script using the=20
> function anyway :)
> >>
> >>Ivo
> >>http://mivo.truxoft.com
> >>
> >>
> >>
> >>>Now you need to go into several separate scripts and update
> >>
> >>them each,
> >>
> >>>instead of making the change to one file.
> >>
> >>
> >>
> >>

File include in Miva?



On Thu, 3 Mar 2005 17:40:04 -0600, Ben Walsh <[email protected]> wrote:
> MvINCLUDE is not a fancy function. It is used by the compiler -- at compile
> time it adds the mvinclude file to your script. You must reference the
> actual file location on your hard disk for this to work.
>
> Example:
> <MvINCLUDE FILE ="c:Devfile.mv"> (un-compiled file)
>
> Also, do not use spaces in the MvINCLUDE. The compiler does not handle
> spaces in the source file name (at least from my experience).
>
> If you use MvINCLUDE, all the functions referenced will be local to the
> script, thereby eliminated the need to MvDO (as has already been said).

Well, adding the full path did get rid of the compiler error, but it's
still acting quite strange.
I'm not getting any output, and when I try to call a function from one
file to the other I get a compiler error.

mvc --version reports 1.14 (dunno if there's anything newer).

--
Bill Guindon (aka aGorilla)

File include in Miva?



After all the trouble trying to get MvINCLUDE to work back when it came
out, I think many of us gave up on it because it seemed to be so buggy
and/or touchy.

Scot

Bill Guindon wrote:
> On Thu, 3 Mar 2005 17:40:04 -0600, Ben Walsh <[email protected]> wrote:
>
>>MvINCLUDE is not a fancy function. It is used by the compiler -- at compile
>>time it adds the mvinclude file to your script. You must reference the
>>actual file location on your hard disk for this to work.
>>
>>Example:
>><MvINCLUDE FILE ="c:Devfile.mv"> (un-compiled file)
>>
>>Also, do not use spaces in the MvINCLUDE. The compiler does not handle
>>spaces in the source file name (at least from my experience).
>>
>>If you use MvINCLUDE, all the functions referenced will be local to the
>>script, thereby eliminated the need to MvDO (as has already been said).
>
>
> Well, adding the full path did get rid of the compiler error, but it's
> still acting quite strange.
> I'm not getting any output, and when I try to call a function from one
> file to the other I get a compiler error.
>
> mvc --version reports 1.14 (dunno if there's anything newer).
>

--
------------

"To The States, or any one of them, or any city of The States,
Resist much, obey little;
Once unquestioning obedience, once fully enslaved;
Once fully enslaved, no nation, state, city, of this earth,
ever afterward resumes its liberty."

~Walt Whitman

File include in Miva?



Using a pre-processor is the way to go :) We use ppwizard, which is
excellent, free, and open source.

Regards,

Adam

File include in Miva?



Andrew said:
"For those of you with extensive programming knowledge, what
is it that keeps you working with MivaScript as opposed to moving
to
some other more sophisticated language? Is it the Merchant market
alone,
or the nostalgia for the language, or do you really feel it is as
sophisticated as perl, asp, .net, php, ruby, etc.?"

I love Miva script, and assume I will continue to do so for a
long time to come, and there are lots of reasons to love it. As
Scot and Ivo already mentioned speed of development is a big
thing to love, and Ivo also mentioned a lot of other feelings
about Miva script that I share, so I won't repeat all that.

I will instead mention one of Miva scripts strongest values to
me, which is something many programmers often sneer at Miva
script for, and that is it's database abilities. I find a real
big value in a language that has it's own stable database tools
that are flexible, fast, and able to be completely sand boxed
inside the user account, and yet are also amazingly portable.

But you speak of moving to another language, and moving implies
an either/or boolean limitation that seems a bit silly. Why not
use multiple languages, taking advantage of the power of each
when they are each most useful?

We use Miva script, but we don't limit ourselves to Miva script.
We also use C, PHP, Perl, JavaScript, Flash, and our own
proprietary Serade programming language for most programming and
will use other languages when there is enough money involved or a
gun is to our heads.

It really is an issue of "Best tool for the job" because each of
those different languages do have their strengths.

When the need is there we use C, because nothing beats C for hard
core power and efficiency of performance. Sometimes there really
is nothing else that can get the job done properly other than a
good tightly coded c program.=20

And we use PHP for various projects for example when you need to
do something on the web to manipulate images, or if you need to
do web based stuff that communicates with MySQL. Or sometimes
just because a client wants something built that they can later
pick any of a thousand teenagers in town to hack around with and
tweak for $10-20/hr :)

And nothing beats Perl for stuff that will execute from the UNIX
shell. If you need it done quick and need to be able to use
something that can work and play well with the guts of a UNIX
server Perl is the tool.

JavaScript of course is THE thing to you use if you want
something on a web page to execute on the client side. And
JavaScript is actually a much more powerful language than most
people give it credit for because they are used to seeing it used
in certain ways and don't realize what else it can do.=20

Flash is also a very useful client side tool, and it blurs the
edges between graphic design and programming in numerous ways.
And actually you can get things like Flash to work and play well
with Server side languages like Miva script in many ways.

And then there is Serade. Serade is totally different than all
other languages we use for two reasons, the first being that
since it's ours we can change it any way we want to meet the
needs we have for it. and the second is that it isn't a "normal
programming language" because it is primarily focused on being
used for writing programs that write programs written in other
languages. i.e. we write Serade programs that write Miva scripts,
and PHP scripts, etc.=20

And finally we come to the programming languages we don't use. I
will refrain from mentioning my feelings about .net, JSP, ASP,
and the ilk. Other than of course the specific mention of my lack
of mentioning them which in itself probably says a lot. And there
are I am certain many languages we've never looked into using
that if we did look into them we might find something very
useful, but our current selection of tools is large enough that
we've yet to feel the need to stray too far away.

- Jeff Huber
President 4TheBest eCommerce Solutions
http://4TheBest.com
[email protected]
Office: 760-742-1469
Cell: 760-445-8454
=20