[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [mv] version 4 approx. release date ?
Quoting Christopher Thompson (ct@arborinternet.com):
>
> A better question is when will 4.01 be released. ;-)
>
> I would guess that even though 4.00 will be pretty stable knowing Mike, it
> will still be a beta of sorts as it sounds like there have been some
> pretty big changes.
>
MiniVend 4 won't be out of beta for quite some time. It will be
out alpha within a day or two. I hope everyone knows what alpha
means... 8-)
As for changes, make sure you stay away from anything that has
been labeled deprecated in the past. And here is the latest WHATSNEW
for 4.0alpha:
W H A T ' S N E W
Everything. Well, not completely -- many MiniVend 3.x catalogs can
run with few changes, but there will be changes.
MiniVend 4.0 is a major rewrite that restructures many things.
Major new features are almost too many to mention, read the documentation
for the most complete description. Some highlights:
* All lists are the same. The basic code for all lists is common, meaning
that the days of [sql-param ...] and [item-param ...] being different
are over.
* All lists can have any prefix. This means that you can do:
[loop prefix=item list="99-102 00-0011a"]
[item-code] [item-field price]
[/loop]
or
[loop prefix=color list="[item-accessories options, color"]
[color-code] [color-data colors name]
[/loop]
* All databases can do basic SQL queries, even MiniVend ones. These
three will/should work much the same on any MiniVend database type:
[query sql="delete from inventory where code = '[item-code]'"]
[/query]
[query sql="insert into inventory ('[item-code]', '[value new_number]'"]
[/query]
[query sql="update inventory set qty = '[value new_number]'
where code = '[item-code]']
[/query]
[query sql="select * from products"]
[/query]
All lists can have a [more-list], can be limited by mv_matchlimit, etc.
* You can save queries to a variable space and then call them in code:
[query sql="select * from products" hashref=prod_table][/query]
[perl]
$products = $Query->{prod_table};
$mona_code = '00-0001';
foreach $ref (@$products) {
$artist = $ref->{artist}, last
if $ref->{code} eq $mona_code;
}
return "The Mona Lisa's artist is: " . $artist;
[/perl]
* All databases and session-variable setting/reading parameters have a
powerful cascading filter capability.
[data table=products
col=artist
key=00-341] returns: VAN GOGH, Vincent
[data table=products
col=artist
key=00-341
filter="name namecase"
] returns: Vincent Van Gogh
[data table=products
col=artist_formatted
key=00-341
filter="name namecase"
value"VAN GOGH, Vincent"
] stores: Vincent Van Gogh
The same thing works for [value ...], [cgi ...], etc. As well as
for certain SQL query situations.
* Many new configuration prodedure capabilities:
- #ifdef and #ifndef on Variable values
- Set directives with code, do equivalent of #ifdef
- attach subroutines to configuration settings with Tie::Watch
- Require directive ensures that GlobalSub and global UserTag entries
are present when moving a catalog
* A new ASP-style syntax is supported:
<HTML MV=mvasp><BODY>This is HTML</BODY>
<%
$Document->write('This is code');
%>
HTML again.
<%
$Document->write('Code again.');
%>
* A new Perl object set is consistent in all areas.
[perl]
$Document->write("Your name is $Values->{name}");
[/perl]
and
[calc]
$Document->write("Your name is $Values->{name}");
[/calc]
are the same, as is:
ActionMap your_name <<EOR
sub {
$Document->write("Your name is $Values->{name}");
return;
}
EOR
Objects supported are:
$CGI->{key} Hash reference to raw submitted values
$CGI_array->{key} Hash reference to array submitted values
%Db Hash of available database tables
$DbSearch->method({}) Do searches in your code
$Document->write() Writes to page
$Carts->{cartname} Direct reference to shopping carts
$Config->{key} Direct reference to $Vend::Cfg
$Scratch->{key} Direct reference to scratch area
$Session->{key} Direct reference to session area
%SQL Hash of available DBI database handles
$Tag->tagname(@args) Call a tag as a routine (UserTag too!)
$Tag->tagname({ %args }) Call with hash-style naming too!
$TextSearch->method({}) Do searches in your code
$Values->{key} Direct reference to user form values
&Log($msg) Log to the error log
HTML $msg Synonym for $Document->write($msg)
* The search engine has been extensively reworked.
-- Word matching should be much more predictable
--
* Tag parameters quoted with parameter=`code` are the equivalent of
parameter="[calc]code[/calc]". They can be subroutine calls, too.
* Tag parameters can be quoted with | to strip whitespace:
[page href=|
[value name="whatever"]
|]
is equivalent to
[page href="[value name="whatever"]"]
* Filters can be created with Filter directive
and/or [input-filter name=var op="uc"][/input-filter]
uc UPPER CASE
lc lower case
digits only digits
word only A-Z a-z _ 0-9
urlencode space becomes %20
entities < becomes <
strip strip leading/trailing whitespace
no_white strip all whitespace
gate set to blank unless scratch variable
with same name is non-blank
n (where n is an integer) length limit
remove delete existing filter (if any)
* Filter directive allows filtering of certain CGI variables
for input conditioning; this is not session dependent and
automatically operates on any iteration of the variable...
Filter phone digits 10
That removes all non-digit values from the variable "phone",
then limits length to 10. Any session-based filters are applied
after this one.
* [input-filter name=foo] CODE [/input-filter]
Sets a routine passed to the equivalent of a "[calc]" tag.
The value to be filtered is placed in the variable "$mv_filter_value",
and the name is set to "$mv_filter_name". It is possible to
do something like:
[input-filter name=country tables=country]
my $val = $mv_filter_value;
my $prospect = &tag_data('country', 'name', $val);
return $prospect || $val;
[/input-filter]
That will return the name of a country if it is found as a key
in the database (assuming the simple demo country definitions).
The tables=country directive is necessary to prepare the database
for access this early in the process.
* Small improvements in the parser, notably optimization when
positional parameters are used.
* ECML is supported via the Vend::ECML module. To map the
checkout form values from MiniVend UserDB names, with an [ecml ...]
tag:
[ecml state]
is equivalent to:
<INPUT TYPE=text
VALUE="[value state]"
NAME=Ecom_ShipTo_Postal_StateProv
SIZE=2>
* The [price] tag now supports pricing with attributes (size/color etc.).
If you do
[price code=99-102 size=XL color=RED]
[price code=99-102 size=L color=RED]
[price code=99-102 size=L color=BLUE]
in the demo, this will demonstrate it.
* The idiom:
#include directory/*
now is supported (and used in the demo minivend.cfg file). This
includes all files in that directory (but not subdirectories)
and allows you to include the whole directory. It should make
maintaining multiple servers a bit easier.
* Items can now be ordered "on-the-fly" in the standard
distribution by adding mv_order_fly.
* Added form-remap based on catalog script-name (too early for
other methods). In minivend.cfg:
FormRemap /cgi-bin/simple code mv_order_item
FormRemap /cgi-bin/simple item mv_order_fly
* Made some minor changes in the demo:
- updated flypage to show attribute-based price tag
- fixed query/check_orders using st=db
- removed some syntax errors
- added [email to=addr from=addr subject=subj] message [/email]
UserTag which is better then the form_mail GlobalSub. It will
allow $Tag->email() to be used, among other things.
- Static build should work out of the box if you
have DBM and define:
StaticDBM static
* Makecat now strips quotes from Apache parameters read from
httpd.conf file.
* Added Tagref.pm module which can document the implementation
of even UserTags. Add this to minivend.cfg to print one
to a MiniVend page:
UserTag tag-reference Routine <<EOR
sub {
require Vend::Tagref;
open (TAGREF, ">mv_tagref.pod");
my $reference = Vend::Tagref::tag_reference();
print TAGREF $reference;
close TAGREF;
my $out = `pod2html mv_tagref.pod`;
if(! $out) {
$Vend::StatusLine = "Content-Type: text/plain\r\n";
$out = $reference;
}
return $out;
}
EOR
* Removed all dependencies on ProductsFiles containing
'products'.
* Added Legacy directive to minivend.cfg to support older
catalogs that don't define "products" database.
* Many bug fixes, of course. Notably [and ...] and [or ..]
were broken in some cases.
REMOVAL
Many things were removed as redundant, deprecated, or just plain
crufty:
* All frame features removed, frames are managed by the user in HTML.
* Tags removed:
buttonbar Replace with Variable.
random Replace with [ad random=1] or custom code
rotate Replace with [ad ...]
help No replacement
body Replace with templates
finish_order No replacement
last_page No replacement
item-link No replacement, just use [page [item-code]]
loop-link No replacement, just use [page [loop-code]]
sql-link No replacement, just use [page [sql-code]]
accessories Replace with normal data functions
* Compatibility routines for many popular tags like [random], [rotate], etc.
are provided in the compat/ directory. To use, include the files in minivend.cfg:
#include compat/*
* Directives removed:
ActionMap
AdminDatabase
AdminPage
AsciiBackend
BackendOrder
ButtonBars
CheckoutFrame
CheckoutPage
DataDir
Delimiter
DescriptionTrim
FieldDelimiter
FrameFlyPage
FrameLinkDir
FrameOrderPage
FrameSearchPage
ItemLinkDir
ItemLinkValue
MsqlDB
MsqlProducts
Mv_AlinkColor
Mv_Background
Mv_BgColor
Mv_LinkColor
Mv_TextColor
Mv_VlinkColor
NewReport
NewTags
OldShipping
OrderFrame
PageCache
PriceDatabase
Random
ReceiptPage
RecordDelimiter
ReportIgnore
Rotate
SearchFrame
SearchOverMsg
SecureOrderMsg
SpecialFile
SubArgs
Tracking
* Minor operations removed:
- auto-substitution of mp= on [loop search=profile],
[search-region arg=profile]
- [tag scan]...
Many of these are related to one of:
* Removal of frames logic
* Removed tags
* Obsolete methods
* Old routines for 2.0x compatibility
