Re: [mv] Chaining together OrderProfiles?

[cfm@maine.com]

******    message to minivend-users from cfm@maine.com     ******

On Fri, Aug 25, 2000 at 11:05:05AM -0400, Mike Heins wrote:
> ******    message to minivend-users from Mike Heins <mikeh@minivend.com>     ******
> 
> Quoting cfm@maine.com (cfm@maine.com):
> > Has anyone ever done any work to chain together OrderProfiles?
> > 
> > Rather than calling profile:
> >  a for part a
> >  b for part b
> >  c for part c (where c is just sum of a and b)
> > 
> > I'd rather call profile:
> >  a for part a
> >  b for part b
> >  a+b for part c (where c is just sum of a and b)
> > 
> 

I'm satisfied with failing on the first bump.

suppose it's something like
  valid_date_profile
  valid_payment_profile
  valid_account_profile

and it dies on valid_date_profile
then user corrects it
and it dies on valid_payment_profile
and user corrects it
and his account_profile was ok so it goes.

Anything else makes it really hard to just add them together independantly
and arbitrarily.  That's **my** primary goal for code management purposes.

I'd not thought about the final issue.  This particular implementation still
goes to final page for one last look.  I'd think the simplest would be
"last one rules" wrt any "set"; that would seem the "expected" behaviour.


> You can do that with route profiles, but not the main mv_order_profile.
> Feature request noted -- I think this will be good to add, but the
> logic is sort of hard to define. If it is simply that all must pass,
> and the *last* one must set &final, that might be done with this change
> in the submit action:
> 
>     if( $CGI::values{mv_order_profile} ) {
> 	my @prof = grep $_, split /[\s\0,]+/, $CGI::values{mv_order_profile};
> 	for (@prof) {
> 	      ($status,$final,$missing) =
> 		  check_order($CGI::values{mv_order_profile});
> 	      last unless $status;
> 	}
>     }
>     else {
> 	$status = $final = 1;
>     }
> 
> But you can see the problems with this -- the $missing thing is not
> cumulative, etc. More code could solve it of course, but obviously care
> must be taken; messing with this too much could screw up any number of
> catalogs. 8-)
> 
> -- 
> Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
> phone +1.513.523.8220 fax 7501 <heins@akopia.com>
> 
> In character, in manners, in style, in all things, the supreme excellence
> is simplicity. -- Longfellow
> -
> To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
> email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
> Archive of past messages: http://www.minivend.com/minivend/minivend-list

-- 

Christopher F. Miller, Publisher                             cfm@maine.com
MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
1.207.657.5078                                       http://www.maine.com/
Database publishing, e-commerce, office/internet integration, Debian linux.
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list