Render Screen inside of other Screen

[Jim Cockerham]

I know that I can do this with toolkit, but I though that Miva now has the ability to render one screen inside another? Anyone have any info on this?

[Brennan]

Re: Render Screen inside of other Screen

The 5.21 engine is due out early next year and it has a mvt:do function built into it, which will allow for a whole slew of new features such as page template render.

We'll be posting a bunch of documentation and examples, specifically replacements for toolkit functions once it is released.

[Kent Multer]

Re: Render Screen inside of other Screen

Have you folks considered putting the whole Miva Script compiler into Store Morph? It seems like you're heading in that direction, "un-crippling" the SMT language a few tags at a time.

[Rick Wilson]

Re: Render Screen inside of other Screen

Kent,

While we're certainly adding more and more, maybe you forget the pain of uncompiled 4.x? Or maybe you liked it. I'll never let us go back to that.

We routinely had people who were certain we "broke" their stores. We'd suggest they edited the source code or had some bad custom programming. They'd swear they never touched anything. We'd dig in. Low and behold we'd find exactly what we thought, bad coding/edited source. They'd say "oh I didn't think you meant that".

Those days will never return, but we are trying to add as much as we can without causing that to happen again.

[Dan - Glendale Designs]

Re: Render Screen inside of other Screen

Why is there a recent modified date on admin.mv? What have you learned? :)

[Kent Multer]

Re: Render Screen inside of other Screen

Actually, yes, I do generally prefer interpreted languages over compiled ones. I remember the "pain of uncompiled;" and when I compare it to the pain of compiled, I really wonder if it was worth all the thousands of man-hours that were expended in switching ... but that's a separate issue. Having Miva Script as a template language doesn't allows users to modify the MM source code. And one compiler is easier to maintain than two, so there's a workload issue for your team. Last year you gave us mvt:assign and mvt:while. Now we have mvt:do ... seems like there's a pattern here ...

[Rick Wilson]

Re: Render Screen inside of other Screen

Internally there's no question of which path we should've taken. We wouldn't be in business today if we'd stayed interpreted.

[Bruce - PhosphorMedia]

Re: Render Screen inside of other Screen

There is always a "danger" in opening up a system. SMT, Toolkelt, heck even page templates let just about anyone wreak their store...often times without even noticing it (i.e., 20% of customers don't see something...and if they can't see it, they might not think to mention it). However, IMO, the correct response is to mitigate the danger...not wall it off. I do think some "how-to" posts and pages should come with a "Skill Level" or "Impact Level" warning.

[Kent Multer]

Re: Render Screen inside of other Screen

Ditto on all Bruce's points. I'll predict that, within 5 years, MM page templates will have a setting to select "Expert mode," which allows you to write Miva Script instead of SMT. It'll have a confirmation pop-up to prevent people from selecting it accidentally.

Rick, if you'll excuse me going off-topic for a moment (hey, it's Friday), I'm curious as to why you feel so strongly about this. There are plenty of shopping carts and other Web apps written with interpreted languages. -- and I assume that some of them are making money for their developers :^) .

Thanks --

[alphabet]

Re: Render Screen inside of other Screen

I recall that there was no clear answer as to running third party modules that had access to the DB and remaining PCI compliant.

Would an <mvt:do> tag effect PCI compliance?

[Rick Wilson]

Re: Render Screen inside of other Screen

Rick, if you'll excuse me going off-topic for a moment (hey, it's Friday), I'm curious as to why you feel so strongly about this. There are plenty of shopping carts and other Web apps written with interpreted languages. -- and I assume that some of them are making money for their developers :^) .

I'm actually not so sure about that, at least not at our size or bigger in the SMB to Mid Market space.

Magento loses a TON of money for eBay. Shopify bleeds money, BigCommerce bleeds money (at least is what I've heard via the grapevine in all 3 cases). And while in Magento you have access to source, even those 3 run in some form of compiled mode.

I've heard Volusion makes good money, but their platform was so bad they've all but abandoned it for Mozu (there new "Enterprise platform" that costs 6 figures a year) and again it's pure SaaS, not an interpreted code base.

Everyone else in our space is our size or smaller and none of them are succeeding in a way that I would describe as long term viable.

So is it possible to build a lifestyle business on non compiled PHP or another interpreted language in the ecommerce space? Maybe, for now. I don't think that will always be the case though.

[Kent Multer]

Re: Render Screen inside of other Screen

Hmmm, there are lots of reasons why companies lose money. How would a non-compiled language be the cause of that?

And I did mention "shopping carts and other Web apps" -- there's a lot on the Web besides e-commerce, and most of it seems to be written in PHP, Python, Ruby, ColdFusion, ASP -- I think these are all interpreted? Though I must admit I don't know what the really big players like Google and Amazon use; I suppose they may still be writing a lot of C code.

Thanks --

[Rick Wilson]

Re: Render Screen inside of other Screen

Kent,

I was specifically answering this question:

There are plenty of shopping carts and other Web apps written with interpreted languages. -- and I assume that some of them are making money for their developers :^) .

But you're correct, I limited my answer to Shopping Cart providers.

If you had asked why I was against Interpreted languages by itself, I would've told you it's the user experience is unacceptable.

In the late 90's it was marginally acceptable because the technical level of the customer was far higher, but in this day and age it's simply unacceptable.

What happens is you get unqualified developers who make very poor choices (both programmatically and business wise) and they alter a product like Miva (if it's available via an Interpreted language). The merchant (customer) then has a sub par experience and Miva as a rule would get blamed, not the poor decision making by the intermediary.

We used to take an obscene amount of flack from these types of situations back in the late 90's and in a world like today where the customer (rightly so) just "expects it to work", we would fail miserably. Especially at the scale we're aiming at (which ties into my previous answer about businesses in our space).

Now I should qualify, it's not the interpreted language that's actually the problem, it's the access to it by others that is the problem. Others would have the ability to tarnish the providers reputation.

[lesliekirk]

Re: Render Screen inside of other Screen

The 5.21 engine is due out early next year and it has a mvt:do function built into it, which will allow for a whole slew of new features such as page template render.

We'll be posting a bunch of documentation and examples, specifically replacements for toolkit functions once it is released.

Just to follow up on this original comment - is there a link for these functions that can be added to this post?

[Brennan]

Re: Render Screen inside of other Screen

http://www.miva.com/videos/articles/...-documentation

and

http://www.miva.com/videos/articles/...ement-examples