Livecode & prestashop

[JJS]

Just like foor Joomla there is an API.

And there also is for prestashop which you could use to communicate with 
database and plugins i guess:

http://doc.prestashop.com/display/PS16/Developer+tutorials


Op 22-4-2019 om 20:31 schreef Richard Gaskin via use-livecode:
> jbv wrote:
>
> > Is there any connexion between LC and e-commerce frameworks
> > like Prestashop ? I thought I've seen a thread about something
> > like that a couple of years ago on this very list but can't
> > retrieve it, and searching the archives is not an easy task...
> > Long story short, a friend of mine is working on a website
> > with prestashop, and needs a specific module. I was wondering
> > if I could build it with LC, export it as html5 and use it as
> > a prestashop plug-in...
> > Any advice ?
>
> I know of at least one developer using the current version of LC's 
> HTML export to deliver a product.  But it's a fairly specialized case 
> in terms of business needs, so while it seems to be a good fit there I 
> would hesitate to suggest it as a general alternative to native web 
> development.
>
> It still *may* be a good fit for what you have in mind, but of course 
> that would depend on the specifics of what you're envisioning.
>
> LC's HTML export relies on a JavaScript library created by translating 
> most of the LC engine's C++ code base via Emscripten, and then using 
> the HTML canvas object similarly to how it uses a window content 
> region on the desktop.
>
> The result is that it requires what is effectively the entire LC 
> engine (in JS form) to be downloaded before the page can be rendered.
>
> And it means that we have an interpreted language being interpreted 
> within an interpreted language, resulting in performance that may not 
> be bad but in many cases doesn't match what we're accustomed to on the 
> desktop.
>
> Moreover, being somewhat self-contained within this JS version of the 
> engine and the canvas object, many things we take for granted in web 
> development require re-thinking, where they can be done at all.
>
> For example, in an HTML page we just use an <a> tag to link to another 
> page.  But LC has no native understanding of HTML tags, and requires 
> scripting to handle those.
>
> In other cases, there are capabilities in the desktop that for good 
> reason don't exist within the confines of a browser, such as arbitrary 
> file access, registry manipulation, and more.
>
> And responsive design for a great experience on screens of all sizes 
> is much easier in many layouts with CSS rather than LC.  For example, 
> the features provided in CSS3's Grid and FlexBox are pretty easy to 
> learn and use, but would require hundreds of lines of LC code to 
> attempt to emulate.
>
> Bottom line:
>
> If the module you're imagining has substantial features that would be 
> costly to implement in native HTML/CSS/JS,
>
> - and -
>
> ...the audience is already dedicated enough to what you're delivering 
> that a wait time of between 20 and 60 seconds to load the JS lib LC 
> engine (depending on network factors, CPU, etc.) would not be 
> prohibitive,
>
> ...then LC's HTML export may be a good fit.
>
> For other cases I tend to favor native web development. It's gotten so 
> much easier with CSS3 that it's sometimes even fun.
>
> When WebAssembler becomes universally adopted, and as network speeds 
> continue to increase along with CPU, things may tilt the other 
> direction.  But even then, those changes will mean native web apps 
> will run even faster too, so the Emscripten method may at best become 
> viable for a broader range of applications but for most is likely to 
> remain a second choice to native web development.
>