Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> Human readable conversion would be easier if multi-line strings were
> supported (without the manual splitting currently needed). This would
> allow a single put statement between LC blocks of code and no need to
> fuss about quote characters.

Like bash's heredoc:

http://quality.livecode.com/show_bug.cgi?id=17471

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Brian Milby via use-livecode]

Human readable conversion would be easier if multi-line strings were
supported (without the manual splitting currently needed). This would allow
a single put statement between LC blocks of code and no need to fuss about
quote characters.

Then you would only need to worry about handler definitions. The rest would
just get wrapped in a default handler. Have not looked at included though,
so not sure how that plays in yet.

When I was reading earlier replies I was thinking of using an array instead
of properties for the HTML blocks. Not sure if there is much difference in
the two though.

For debugging, I’m guessing that you (Mark) are saying that a mapping of
converted line to source line would be maintained so that when errors are
flagged the dev could be presented the correct line in source. I’m guessing
that this would also work for stepping through code.
On Sat, Dec 9, 2017 at 7:29 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2017-12-09 13:40, Alex Tweedly via use-livecode wrote:
> > Would it not be easier to transform the text blocks in to a (series
> > of) "put" statement(s) ?
> > Being "put"ted  is exactly what is going to happen to the text in the
> > non-code blocks, so why not just do that.
>
> Are you sure they would be put'd? ;)
>
> The use-case I was inferring was one of 'emulation of LC server inside
> the IDE'. Richard wasn't all that specific about the tooling he has for
> LiveCode CGIs, but I have assumed that the tooling *does* abstract
> output - after all, 'non-targeted put' in the IDE puts things in the
> message box - which is great for looking at, but not so great if it is
> going to be fed into something like a browser for display.
>
> Since we are talking about emulation (in this case basically 'compiling'
> a LC server script to a LiveCode Script to be able to run it outside of
> LC Server), the actual intermediate script which runs the same as the
> original doesn't have to be readable by humans. After all - when
> debugging you don't look at the machine code generated by a compiler but
> at the original source instead. The error positions and such can be
> easily mapped by using a sideline array which maps line/row indexes in
> the intermediate script back to the original - i.e. the intermediate
> script is just an implementation detail.
>
> Of course, the thing here is that mechanism which allows an emulation
> also allows a conversion (i.e. forever leaving the LC Server style
> behind) - the difference is just how the inline text / and
> server-specific commands (e.g. put output, put unicode, put header etc.)
> are translated. In that case, I agree that pre-processing the text
> blocks and churning them out as a sequence of 'envPut ' would
> make much more sense (envPut here because, as discussed above, 'put' is
> not *necessarily* suitable).
>
> Another option would be to turn 'put' into a 'put ... after ...' and
> then return the string (this would then be very much 'merge'-like).
> Again, the variability here is just how *that* specific command is
> converted - which could easily be made an option of the compiler script
> which does the conversion.
>
> Anyway, would what I suggested (in terms of a LCServer->LCScript
> compiler written in LCS) be a useful thing?
>
> For those concerned about performance (although performance in an
> emulator is perhaps less of a concern than production), then there is no
> real need to be. The compiling process can be done ahead of time, and
> the cost is only once-per-server-script file - the compiled version is
> an LiveCode Script so would have the same performance characteristics as
> the original. Even if you wanted to use such a thing in a dynamic case
> (e.g. merge like), then chances are each template file would be being
> used more than once, so you actually gain performance after the initial
> compile.
>
> In this case, a C++ solution would offer no real advantage - in fact a
> huge disadvantage in terms of development time, maintenance and
> adaptability.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Mark Waddingham via use-livecode]

On 2017-12-09 13:40, Alex Tweedly via use-livecode wrote:

Would it not be easier to transform the text blocks in to a (series
of) "put" statement(s) ?
Being "put"ted  is exactly what is going to happen to the text in the
non-code blocks, so why not just do that.


Are you sure they would be put'd? ;)

The use-case I was inferring was one of 'emulation of LC server inside 
the IDE'. Richard wasn't all that specific about the tooling he has for 
LiveCode CGIs, but I have assumed that the tooling *does* abstract 
output - after all, 'non-targeted put' in the IDE puts things in the 
message box - which is great for looking at, but not so great if it is 
going to be fed into something like a browser for display.


Since we are talking about emulation (in this case basically 'compiling' 
a LC server script to a LiveCode Script to be able to run it outside of 
LC Server), the actual intermediate script which runs the same as the 
original doesn't have to be readable by humans. After all - when 
debugging you don't look at the machine code generated by a compiler but 
at the original source instead. The error positions and such can be 
easily mapped by using a sideline array which maps line/row indexes in 
the intermediate script back to the original - i.e. the intermediate 
script is just an implementation detail.


Of course, the thing here is that mechanism which allows an emulation 
also allows a conversion (i.e. forever leaving the LC Server style 
behind) - the difference is just how the inline text / and 
server-specific commands (e.g. put output, put unicode, put header etc.) 
are translated. In that case, I agree that pre-processing the text 
blocks and churning them out as a sequence of 'envPut ' would 
make much more sense (envPut here because, as discussed above, 'put' is 
not *necessarily* suitable).


Another option would be to turn 'put' into a 'put ... after ...' and 
then return the string (this would then be very much 'merge'-like). 
Again, the variability here is just how *that* specific command is 
converted - which could easily be made an option of the compiler script 
which does the conversion.


Anyway, would what I suggested (in terms of a LCServer->LCScript 
compiler written in LCS) be a useful thing?


For those concerned about performance (although performance in an 
emulator is perhaps less of a concern than production), then there is no 
real need to be. The compiling process can be done ahead of time, and 
the cost is only once-per-server-script file - the compiled version is 
an LiveCode Script so would have the same performance characteristics as 
the original. Even if you wanted to use such a thing in a dynamic case 
(e.g. merge like), then chances are each template file would be being 
used more than once, so you actually gain performance after the initial 
compile.


In this case, a C++ solution would offer no real advantage - in fact a 
huge disadvantage in terms of development time, maintenance and 
adaptability.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Alex Tweedly via use-livecode]

On 08/12/2017 17:28, Mark Waddingham via use-livecode wrote:


On 2017-12-07 19:52, Richard Gaskin via use-livecode wrote:

Would it be possible/practical to extend the merge function to at
least allow things like control structures with non-LC stuff in
between them?
A LC Server script is an alternating sequence of code and text blocks. 
Once you have that alternating sequence, you could replace the text 
blocks with a call to a handler with a parameter which is a custom 
prop of the stack containing the text content.
Would it not be easier to transform the text blocks in to a (series of) 
"put" statement(s) ?
Being "put"ted  is exactly what is going to happen to the text in the 
non-code blocks, so why not just do that.


Also, that means that the LC Server script can be turned into a 
script-only stack - which would feel more natural to me. And,  it would 
continue to be visible in-line, therefore retaining (more or less) the 
same self-documenting characteristic as the original script.


It's much more legible (to me) to replace

   
  Some data that happens to be HTML
   
  Some other data that happens to be HTML
   

with

    if a = b then
 put "  Some data that happens to be HTML " & CR
   else
     put "  Some other data that happens to be HTML & CR
   end if

rather than

  if a = b then
     someHandler myPropertyName1
   else
 someHandler myPropertyName2
   end if

OK, OK, you need to handle quotes within the HTML - but it should be 
easy enough.


-- Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Mark Waddingham via use-livecode]

On 2017-12-07 19:52, Richard Gaskin via use-livecode wrote:

Would it be possible/practical to extend the merge function to at
least allow things like control structures with non-LC stuff in
between them?

E.g., from my earlier post:

EXAMPLE B

The implicit merge LC Server uses is more complete than the
explicitly-called merge function.  For example, the merge function
doesn't handle conditionals cross non-code parts, e.g.:

   
  Some data that happens to be HTML
   
  Some other data that happens to be HTML
   

That'll work in LC Server, but AFAIK is incompatible with LC Script on
the desktop.


Possible - yes. Worthwhile implementing in C++ in the engine - probably 
not...


The reason I say that is because it would be relatively straight-forward 
(assuming appropriate knowledge) to write an LCS script which transforms 
a server script into an LC stack which 'does the same thing' and then 
you have something far more adaptable.


A LC Server script is an alternating sequence of code and text blocks. 
Once you have that alternating sequence, you could replace the text 
blocks with a call to a handler with a parameter which is a custom prop 
of the stack containing the text content. Then the code would need to be 
transformed so that all inline commands where in a single handler, all 
variable decls at top-level were script locals, and all handler 
definitions in the code blocks next to the main handler.


The only slight tricky bit is the creation of root-scope variables if 
not using explicitVars. I'd need to give that some thought but doing it 
with a transformation written in script would mean you could (for the 
most part) emulate the LC server environment in the IDE - even replacing 
server specific commands (e.g. put output) with calls to handlers which 
emulate them.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Mark Waddingham via use-livecode]

On 2017-12-08 17:17, Rick Harrison via use-livecode wrote:

Hi Richard,

I think you may have stated your question for us in the wrong way.

Instead of asking us is we co-mingle our code with HTML you
should have asked us if we had any interest in doing things
differently by using LC Script from the desktop to work with
web pages.

I think we have found ourselves forced into mingling our code
with the newer LC Server. That doesn’t mean that we prefer it,
or that we wouldn’t be interested in looking at some tools which
use a different method with your older CGI method.

If you want to share your tools with us I am sure the community
would like to take a look at them.


I was going to point out a similar thing :)

It sounds like Richard has built up a useful flow/toolkit for doing 
LC-based server apps - the fact it doesn't use LC Server is immaterial. 
After all, its what it enables people to do which is important, not the 
manner or means of implementation.


Okay, so for existing projects which use LC Server there would be a 
porting cost - but that would be worth it if the benefits outweigh the 
time taken to port across. However, there are more projects which are to 
be written in the future than exist now - so for new 'green field' 
projects, the choice as to underlying technology is still to be made.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Rick Harrison via use-livecode]

Hi Richard,

I think you may have stated your question for us in the wrong way.

Instead of asking us is we co-mingle our code with HTML you
should have asked us if we had any interest in doing things
differently by using LC Script from the desktop to work with
web pages.

I think we have found ourselves forced into mingling our code
with the newer LC Server. That doesn’t mean that we prefer it,
or that we wouldn’t be interested in looking at some tools which
use a different method with your older CGI method.

If you want to share your tools with us I am sure the community
would like to take a look at them.

Cheers,

Rick


> I appreciate the interest, but it doesn't seem using these tools would be
> possible for most folks.
> 
> Being able to run client and server code in the IDE would require using
> methods that are compatible with LC Script on the desktop.  Since we have
> no way of parsing/executing LC Server code in the desktop, and too many
> people rely on the code-embedded-in-HTML way, my tools are of no use to
> them.
> 
> For the first dozen years of this engine, CGIs used the same engine as
> everything else.  Since LC Server premiered, most devs now have a workflow
> that is incompatible with the desktop engine.
> 
> I've been using standalones for CGIs for many years, and while I know a
> few others who do this, there aren't many.
> 
> I recently came across a project which uses LC Server but only to launch
> script libraries, so effectively it's 99% compatible with LC Script, using
> only a couple lines of LC Server to launch the libraries.  This got me
> wondering how many others do things like that, as opposed to relying on
> features specific to LC Server throughout their app which have no means of
> executing in the IDE.
> 
> At this point, it seems most people are using LC Server in ways that are
> not compatible with the desktop engine.  I have nothing that can help with
> that.
> 
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Simon Smith via use-livecode]

Despite my earlier comments - it is still something that I would be
interested in.

While my preferences has always been to mix html / code together - if there
is a better way to do things, then I would definitely be interested in
finding out / learning more.






Carpe diem

*Simon Smith*
m. +27 83 306 7862

On Thu, Dec 7, 2017 at 6:25 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Bob Hall wrote:
>
> > I’m very interested in your tools and suspect there is great value in
> > what you’ve created.
>
> I appreciate the interest, but it doesn't seem using these tools would be
> possible for most folks.
>
> Being able to run client and server code in the IDE would require using
> methods that are compatible with LC Script on the desktop.  Since we have
> no way of parsing/executing LC Server code in the desktop, and too many
> people rely on the code-embedded-in-HTML way, my tools are of no use to
> them.
>
> For the first dozen years of this engine, CGIs used the same engine as
> everything else.  Since LC Server premiered, most devs now have a workflow
> that is incompatible with the desktop engine.
>
> I've been using standalones for CGIs for many years, and while I know a
> few others who do this, there aren't many.
>
> I recently came across a project which uses LC Server but only to launch
> script libraries, so effectively it's 99% compatible with LC Script, using
> only a couple lines of LC Server to launch the libraries.  This got me
> wondering how many others do things like that, as opposed to relying on
> features specific to LC Server throughout their app which have no means of
> executing in the IDE.
>
> At this point, it seems most people are using LC Server in ways that are
> not compatible with the desktop engine.  I have nothing that can help with
> that.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> FWIW Drupal is not free!

Drupal is absolutely free:

https://www.drupal.org/about/licensing


> horror story, no in-house expertise, smart but "secretary" level user,
> had to hire drupal support, 3rd party module dependencies, developers
> disappear, core engine transitions to new versions, modules
> incompatible. Drupal support company bids astronomical $'s to get a
> module working the latest version of Drupal…before you know it your
> annual maintenance $ fee start climbing into numbers we can't possibly
> sustain. we finally had to exit Drupal.

Don't use what you don't need.  But don't call free software "not free!" 
when it in fact is.  They're among the strongest GPL advocates in the 
CMS world, and beyond "free as in freedom" Drupal is available at no cost.


As with Wordpress, Joomla, MySQL, LiveCode Community Edition, or any 
other free software, you can choose to hire developers and you can 
choose to pay for premium add-ons.  Those are your choices, not Drupal's.


WordPress is an excellent choice when you're making fairly common types 
of sites, brochureware, blogs, etc.  You can extend it beyond that, but 
at a certain point you're writing custom code.


Drupal's building blocks approach means a greater distance before you're 
writing custom code, and working with a leaner core when you are.


Drupal tends to be popular among major universities, government 
agencies, and large organizations with deeper needs than most. 
Developers expert in Drupal tend to also have a depth of experience in 
managing larger-scope projects with more complex requirements. It's not 
surprising to find the average Drupal consulting rate reflects that depth.


But if your site doesn't need to take advantage of the things Drupal 
does especially well I wouldn't recommend it, any more than I'd 
recommend using LiveCode for a custom app when a spreadsheet will do.


My advice for most people is: choose WordPress unless you have a 
specific reason not to.


And if you have a specific reason not to, consider Drupal among your 
options.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Sannyasin Brahmanathaswami via use-livecode]

Replying to your original post/surveyr. Not exactly sure what you are looking 
for… and this is just story telling that may not be directly relevant but 
perhaps helpful to lurkers

so here goes

at Himalayan academy.com 

We use RevIgniter for everything on our site except the blog… 

public_html/blog # contains wordpress, as we did not see a reason to reinvent 
that wheel. Matching the theme on WordPress to the theme in Revigniter is as 
"easy as pie" and I can even mix in some LC results into the WP Blog. Simon in 
South Africa helps us there.. a WP wizard and also familiar with LC

We use XOOPS for the Hinduism today web site.  That was the first CMS we used 
even before RevIgniter. Certainly a mix of PHP and html. It was a good decision 
then (around 2000 or so?) XOOPs has been around a long time. And it has a very 
high value in terms of ease of use, strong community and we have, for support, 
one of the top XOOPS community leaders actually working for us on the site, 
moving up now to  php 7.2 and the latest XOOPS version on cloned instance… 
should go live very soon. We have desktop client built in LC that pushes 
content to XOOPS.  the magazine is a "no brainer" many issues, organized By 
year, quarter, month, articles, archives… a few ancillary info pages… no social 
other than article comments by registered users, so the customization 
requirements are very low. The new mobile version will be much much bigger in 
terms of users and that driven by HTML 5 from BlueToad.

For our "saivasiddhanta.org" (in house for registered members/families) site we 
use what used to be OC Portal.. now Composer, which I switched to , after a 1.5 
year long debacle here with Drupal that finally killed the site we were trying 
to build/run. I switched to OC Portal because, a) the inhouse man running the 
site was gaining enough html skills… and b)  OC portal already came with 
everything he wanted… and c) the UK team behind it was stellar and avoided the 
"3rd party module hell" that we landed in and drown the project in before with 
Drupal.

FWIW Drupal is not free!  horror story, no in-house expertise, smart but 
"secretary" level user, had to hire drupal support, 3rd party module 
dependencies, developers disappear, core engine transitions to new versions, 
modules incompatible. Drupal support company bids astronomical $'s to get a 
module working the latest version of Drupal…before you know it your annual 
maintenance $ fee start climbing into numbers we can't possibly sustain. we 
finally had to exit Drupal.

I highly recommend Composer if you do want a CMS that uses PHP, where you need 
a complete suite to support a social environment. And Chris's support model is 
the most reasonably priced tier of any software company we ever dealt with. And 
because all the code is under one roof, he can pretty much get anything you 
need done.

Customizations (as has been noted) are where you hit the wall. With OC 
Portal/Composer, it already has such robust tools for social that it would be 
insane to rebuild all those from ground zero. But theming it is challenging… 
but more about design expertise really, than the CMS tool box itself. Still as 
noted by someone else here.. you hit walls on customization…

himalayanacademy.com, the level of customization we wanted, and the fact that 
we don't do social at all there… we went with LC/RevIgniter, there are no walls 
there maybe little mountains to climb where it might be easier with new tools… 
but there is nothing you cannot do. But still I'm not seeing "time to 
completion" improved by new tools sets over what we have and can do for 
implementation of any vision, using LC/MySql

Presumably RevIgniter qualifies for your "mx and match" html + LC

How many of you using LC Server rely on its PHP-like model that 
encourages mixing HTML with LC code?

Or maybe the better question might be:

How many of you have server systems that already separate HTML from 
server code like most non-PHP solutions do, or could affordably 
transition to that model if it could simplify your development workflow 
significantly?

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Thanks for chiming in, Mark.  The background your provide is always helpful.

Mark Waddingham wrote:

> Also, the server-specific syntax isn't present in the IDE engine which
> also poses a difficulty.

Would it be possible/practical to extend the merge function to at least 
allow things like control structures with non-LC stuff in between them?


E.g., from my earlier post:

EXAMPLE B

The implicit merge LC Server uses is more complete than the
explicitly-called merge function.  For example, the merge function
doesn't handle conditionals cross non-code parts, e.g.:

   
  Some data that happens to be HTML
   
  Some other data that happens to be HTML
   

That'll work in LC Server, but AFAIK is incompatible with LC Script on
the desktop.


> P.S. If you restrict what can be done in the LC server scripts in your
> emulated environment then it becomes easier - but whether that is
> useful or not depends on what the tooling you have does, and how you
> would like it to be able to interoperate with server.

That's essentially the core of this thread, to try to get a feel for how 
many people work in ways that might lend themselves to that.  It seems 
not many.


No worries for me, as I use standalones for CGI work.  I was just 
feeling a bit selfish keeping this streamlined workflow to myself, but 
given the engine differences and the embracing of LC Server's way of 
doing things among those who use it, it seems very few if any other 
folks would fine a standalone-centric way of doing CGIs worth adopting.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Bob Hall wrote:

> I’m very interested in your tools and suspect there is great value in
> what you’ve created.

I appreciate the interest, but it doesn't seem using these tools would 
be possible for most folks.


Being able to run client and server code in the IDE would require using 
methods that are compatible with LC Script on the desktop.  Since we 
have no way of parsing/executing LC Server code in the desktop, and too 
many people rely on the code-embedded-in-HTML way, my tools are of no 
use to them.


For the first dozen years of this engine, CGIs used the same engine as 
everything else.  Since LC Server premiered, most devs now have a 
workflow that is incompatible with the desktop engine.


I've been using standalones for CGIs for many years, and while I know a 
few others who do this, there aren't many.


I recently came across a project which uses LC Server but only to launch 
script libraries, so effectively it's 99% compatible with LC Script, 
using only a couple lines of LC Server to launch the libraries.  This 
got me wondering how many others do things like that, as opposed to 
relying on features specific to LC Server throughout their app which 
have no means of executing in the IDE.


At this point, it seems most people are using LC Server in ways that are 
not compatible with the desktop engine.  I have nothing that can help 
with that.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Mark Waddingham via use-livecode]

Apologies - I missed the top post here for some reason :)

On 2017-12-05 19:18, Richard Gaskin via use-livecode wrote:

I have some tools I developed for server apps, which allow me to
develop and test both client and server within the same local LC IDE
instance. As you can imagine, this has improved development efficiency
by orders of magnitude.


Okay so you want to be able to emulate server systems *inside* the IDE - 
seems reasonable, and useful.



Would it be reasonable/affordable to add some means of enhancing
desktop LC so that it can at least parse and attempt to execute LC
scripts embedded in HTML?  I can emulate environment variables and the
like, but the incompatibility between LC and .lc has been a real
development bottleneck.


That is slightly tricky.

LC Server is essentially a much more traditional 'language interpreter' 
- indeed it can be seen as providing a REPL at top-level.


The commands and declarations in the LC server scripts are basically 
executed line by line (although a whole script is parsed first - whether 
it be the initial script, or included script).


Any declarations are added to 'global scope', and commands are executed 
in that 'global scope'. As soon as you call a handler in a stack, it is 
the same as non-server engines though.


More specifically, global scope is actually implemented as a (root) 
stack script - that stack sits between all other stacks and all 
external/library/backscript type things in the message path. (In 
particular variables created at that scope are not global unless you 
mark them as such - they are script local to the root stack.


Internally when it passes an lc server script, the bits outside of code 
markup () get turned into 'echo' commands (basically put) with 
the output string being the block of text,


The placement of the root stack in LC server poses a difficulty for 
emulating in the IDE - as you'd want it to sit behind all stacks which 
make up the server environment you are emulating, but above other things 
in the IDE. This isn't currently possible (you can kind of view stacks 
which are loaded on server as being substacks of that root stack - but 
substacks are only one-level deep, so its only an analog and not a true 
reflection).


Also, the server-specific syntax isn't present in the IDE engine which 
also poses a difficulty.


It might be possible to emulate the server environment by parsing the LC 
server scripts in LCS in the IDE and fettling with them appropriately to 
make up for the differences, but that isn't going to be the easiest 
thing to do.


For a long time the notion of 'project' has been floating around - i.e. 
a separate scope inside the engine in which applications run. The IDE 
would be a project, with the applications being edited in their own 
projects. This is actually largely equivalent to having the IDE run in 
one process, and spinning up standalones for each application being 
edited which it mutates via IPC. Indeed, the latter is actually a better 
design for robustness - if one application crashes, it wouldn't bring 
down the IDE (something which becomes much more important when you start 
playing with FFI - C and Obj-C are not safe-friendly languages). That 
model would also work for running server apps live like server apps run 
- you'd spin up a server engine instead of a standalone engine.


In any case, I think I see what you would like to do - however, I'm not 
sure I can offer much in the way of suggestions as to how to do it right 
now :(


Warmest Regards,

Mark.

P.S. If you restrict what can be done in the LC server scripts in your 
emulated environment then it becomes easier - but whether that is useful 
or not depends on what the tooling you have does, and how you would like 
it to be able to interoperate with server.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Mark Waddingham via use-livecode]

I must confess I'm slightly puzzled by this thread...

If you want to write web-apps like PHP - i.e. intermingling code with 
HTML output, then use LiveCode Server. If you don't want to do that, 
then just don't?


LiveCode Server supports stacks so you can do:



In LC Server, which would give you a very similar situation to just 
running stack "foo" in a -ui standalone engine but with the added bonus 
of using the server-specific variants of 'put output'


Also the LiveCode Community Standalone engine has been able to take a 
stack on the commandline for years - on Mac you have to get at the 
engine from within the bundle  (i.e, .../Contents/MacOS/Standalone -ui 
) which is irksome, but blame Apple for that (its one of the 
downsides of folder-type app structures, although a minor one compared 
to the benefits they bring).


If you want commercial features, then yes - you do need to build a 
standalone which has a bootstrap stack in it - but if we didn't do that 
then anyone could take the commercial standalone engine and use it 
without a license so that ain't gonna change.


At some point it would be nice to unify the server/non-server engines 
but that isn't very high on the priority list at the moment (indeed, it 
sits really quite far down...).


Warmest Regards,

Mark.

On 2017-12-07 01:48, Richard Gaskin via use-livecode wrote:

Alex Tweedly wrote:


On 06/12/2017 19:14, Richard Gaskin via use-livecode wrote:


There's a difference in terms of the primary execution object, and
how that effects the flow of both execution and the workflow.

It seems I'm unable to articulate it clearly enough, but no worries.
The bottom line is that LC Server scripts are incompatible with LC
Script on the desktop, and when used with wrapped HTML there's no
need for me to generalize my tools because they can't be used in that
context.


I'm still unclear on what does (can?) and what doesn't (can't) be done
with LC Server scripts on the desktop.

If I don't use mingled/wrapped HTML (which I certainly don't, afaik) -
could I use your tools for my LC Server scripts (nb - they do use
'include's).

In fact, to be even more specific - assuming "my" scripts are actually
revIgniter with a controller or two added by me, would it be possible
to use the tools ?


By what means would you execute those with LC Script on the desktop?

A few examples of incompatibilities between LC Script on the desktop
and LC Server (designated by letter in case anyone wants to refer to
any of these):

--
EXAMPLE A

This:

  

...runs great when you pass a file with that to LC Server.  LC Script
for the desktop won't know what do to with it.

You could run that as data through the merge function and it would
work well, but that's a different execution sequence than passing a
file directly to an engine.

--
EXAMPLE B

The implicit merge LC Server uses is more complete than the
explicitly-called merge function.  For example, the merge function
doesn't handle conditionals cross non-code parts, e.g.:

  
 Some data that happens to be HTML
  
 Some other data that happens to be HTML
  

That'll work in LC Server, but AFAIK is incompatible with LC Script on
the desktop.

--
EXAMPLE C

For the first dozen or so years of the desktop engine, you could pass
it a text file with something like this in it:

  on startup
 put DoSomethingWith($REMOTE_ADDR) into tReply
 put "HTTP/1.x 200 OK" & \
   Content-Length: "& len(tReply) & tReply
   end startup

With the introduction of LC Server the ability of the desktop file to
handle plain text files containing code disappeared.  In its place
only LC Server could handle those, and only when wrapped within the
"" tags.

--
EXAMPLE D

Environment variables in the original desktop engine were handled
directly as defined by Apache.  In LC Server they are copied into vars
that are similar but not the same, e.g. the env var:

   $REMOTE_ADDR

...is available in LC Server as:

   $_SERVER["REMOTE_ADDR"]

--
EXAMPLE E

A few years ago on of the team members recognized that it would be
useful to be able to run simple text files containing scripts only
with a bare engine.  Since LC Server is the only bare engine now
executable by itself without having to be made into a standalone, and
perhaps unaware of the long history of having been able to do this
before, it was added but in an odd way, without any handler
declaration, just raw statements, e.g.:

  get 1+1
  add 5 to it
  put SomeFunction(it) into tResult

  function SomeFunction p1
 return p1+100
  end SomeFunction

So code outside of a handler is a sort of implied handler, but to
distinguish that code from anything in an actual handler the other
handlers look like handlers.

This is unlike anything in any xTalk, and breaks the 

Re: LC Server style survey: co-mingle code w/HTML?

[Bob Hall via use-livecode]

> On Dec 5, 2017, at 1:18 PM, Richard Gaskin via use-livecode 
> > wrote:
> 
> I have some tools I developed for server apps, which allow me to develop and 
> test both client and server within the same local LC IDE instance. As you can 
> imagine, this has improved development efficiency by orders of magnitude.
> 
> It's much a much more xTalk-like way of working, and once you use it having 
> to be tied to a server for every little test feels like building a ship in a 
> bottle with tweezers while wearing a blindfold.
> 
> When I started making these tools I was using standalones exclusively for 
> server work, partly because it reflects my habits gained from using LC as a 
> CGI for many years before LC Server existed, and partly because I have no 
> need to co-mingle code in HTML like PHP does, except a few cases where the 
> merge function works quite nicely.

Richard,

I wanted to reply to your original question. I’m not sure I know exactly what 
you’re asking. I do have projects that I use the existing LC Server with 
co-mingling. In my opinion, co-mingle was once in fashion and the norm, then 
fell out of fashion. But I’ll be honest, it’s making a come back. As you know 
there is a lot of opinion in this area.

There are examples of languages with this pattern you see in PHP/LC which has 
been pointed out. I’d like to add that newer Javascript frameworks seem to be 
making a return to co-mingling HTML and the language.Yes, JS is more of a 
client language. But there are server projects that use this pattern. Look at 
some of the new ES6/ES7 standard to see the new definitions for this. You see 
this pattern also with JSX/React.

Your LC IDE tools are very intriguing to me. I’ve pretty much tried to stick 
with MVC type patterns for LC Server projects isolating anything html/lc mixing 
to the view files in their own view directory structure.

In the last couple of months I’ve been “playing” (really that’s all it’s been) 
with how to use .livecodescript files instead of .lc files for the guts of LC 
Server projects. My goal was to be able to use the IDE for creating/debugging 
server projects including using breakpoints and being able to see the raw 
output as well as a rendered view.

I got far enough to see there’s promise in my method and was able to use the 
IDE to build a very small server project. Then I got busy at my real work and 
put this on the back burner :-(

Anyways, I do think that mixing LC and HTML is a viable option. Being able to 
do that in the IDE does I think open the door to more LC Server based projects 
going out the door.

I’m very interested in your tools and suspect there is great value in what 
you’ve created.

Bob Hall
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 06/12/2017 19:14, Richard Gaskin via use-livecode wrote:
>>
>> There's a difference in terms of the primary execution object, and
>> how that effects the flow of both execution and the workflow.
>>
>> It seems I'm unable to articulate it clearly enough, but no worries.
>> The bottom line is that LC Server scripts are incompatible with LC
>> Script on the desktop, and when used with wrapped HTML there's no
>> need for me to generalize my tools because they can't be used in that
>> context.
>>
> I'm still unclear on what does (can?) and what doesn't (can't) be done
> with LC Server scripts on the desktop.
>
> If I don't use mingled/wrapped HTML (which I certainly don't, afaik) -
> could I use your tools for my LC Server scripts (nb - they do use
> 'include's).
>
> In fact, to be even more specific - assuming "my" scripts are actually
> revIgniter with a controller or two added by me, would it be possible
> to use the tools ?

By what means would you execute those with LC Script on the desktop?

A few examples of incompatibilities between LC Script on the desktop and 
LC Server (designated by letter in case anyone wants to refer to any of 
these):


--
EXAMPLE A

This:

  

...runs great when you pass a file with that to LC Server.  LC Script 
for the desktop won't know what do to with it.


You could run that as data through the merge function and it would work 
well, but that's a different execution sequence than passing a file 
directly to an engine.


--
EXAMPLE B

The implicit merge LC Server uses is more complete than the 
explicitly-called merge function.  For example, the merge function 
doesn't handle conditionals cross non-code parts, e.g.:


  
 Some data that happens to be HTML
  
 Some other data that happens to be HTML
  

That'll work in LC Server, but AFAIK is incompatible with LC Script on 
the desktop.


--
EXAMPLE C

For the first dozen or so years of the desktop engine, you could pass it 
a text file with something like this in it:


  on startup
 put DoSomethingWith($REMOTE_ADDR) into tReply
 put "HTTP/1.x 200 OK" & \
   Content-Length: "& len(tReply) & tReply
   end startup

With the introduction of LC Server the ability of the desktop file to 
handle plain text files containing code disappeared.  In its place only 
LC Server could handle those, and only when wrapped within the "" 
tags.


--
EXAMPLE D

Environment variables in the original desktop engine were handled 
directly as defined by Apache.  In LC Server they are copied into vars 
that are similar but not the same, e.g. the env var:


   $REMOTE_ADDR

...is available in LC Server as:

   $_SERVER["REMOTE_ADDR"]

--
EXAMPLE E

A few years ago on of the team members recognized that it would be 
useful to be able to run simple text files containing scripts only with 
a bare engine.  Since LC Server is the only bare engine now executable 
by itself without having to be made into a standalone, and perhaps 
unaware of the long history of having been able to do this before, it 
was added but in an odd way, without any handler declaration, just raw 
statements, e.g.:


  get 1+1
  add 5 to it
  put SomeFunction(it) into tResult

  function SomeFunction p1
 return p1+100
  end SomeFunction

So code outside of a handler is a sort of implied handler, but to 
distinguish that code from anything in an actual handler the other 
handlers look like handlers.


This is unlike anything in any xTalk, and breaks the otherwise 
beautifully learnable consistency of "code lives in handlers".


--
EXAMPLE F

Even more recently it was recognized that script-only stacks can be 
useful, so now you can have something almost like the original text 
files we used to use, but with the addition of one line at the top 
specifying that it's a "stack":


stack "Some Stack Name"

on startup
   DoSomething
end startup

AFAIK this is not compatible with LC Server, at least not in terms of 
expecting the startup handler to fire if you pass that text file to it. 
I don't know if it'll choke on the "stack" declaration, but my 
understanding is that only code outside of any handler is used in the 
role of a startup handler.


You can, however, bring it into use as a library, provided you have some 
other execution object (an HTML file) use "start using".


--
EXAMPLE G

With the LC Script desktop engine, "put" commands output to stdout at 
the time they're called.  With LC Server it appears "put"s are buffered 
and output as a single stream when processing of the page that has been 
completed.


--

There may be other differences; these are just the ones off 

Re: LC Server style survey: co-mingle code w/HTML?

[Alex Tweedly via use-livecode]

On 06/12/2017 19:14, Richard Gaskin via use-livecode wrote:


There's a difference in terms of the primary execution object, and how 
that effects the flow of both execution and the workflow.


It seems I'm unable to articulate it clearly enough, but no worries. 
The bottom line is that LC Server scripts are incompatible with LC 
Script on the desktop, and when used with wrapped HTML there's no need 
for me to generalize my tools because they can't be used in that context.


I'm still unclear on what does (can?) and what doesn't (can't) be done 
with LC Server scripts on the desktop.


If I don't use mingled/wrapped HTML (which I certainly don't, afaik) - 
could I use your tools for my LC Server scripts (nb - they do use 
'include's).


In fact, to be even more specific - assuming "my" scripts are actually 
revIgniter with a controller or two added by me, would it be possible to 
use the tools ?


Thanks
Alex.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Rick Harrison wrote:

> Hi Richard,
>
>> You use Wordpress.
>
> After exploring Wordpress a couple of years ago I decided not use
> Wordpress.
> I do not use Wordpress.

My bad, though earnestly I must admit I don't understand this thread: 
if we're not talking about Wordpress, what are we talking about and why 
has so much of this thread been about Wordpress?



> No one said Web hosting was an easy business,
> but it needs to be become better.  No company should
> threaten it’s users to do XYZ upgrade or suffer the
> loss of their accounts.  If it is that important, then the
> company should make the upgrade process very
> simple or automatic, or not offer that particular piece
> of software if it is so vulnerable that it threatens the
> security of the entire system.

I'd like that too.  But as with much of life, what I want and what the 
world offers me is often different. ;)


I do see managed services.  But like Simon said, they're not cheap.


> I objected to the fact that Run-Rev hyped Wordpress to
> it’s On-Rev users, and after encouraging them to
> snap it up, then later slapped them.

One man's "slapped" is another man's "please read the Terms and 
Conditions".  I don't use on-rev and haven't seen their ToC so I don't 
have an opinion there.  But from what I've heard their policies don't 
seem unusual, at least compared to the half-dozen or so hosting 
companies I've used over the years.


Maybe the bigger problem is with shared hosting in general.  Like you 
say, it's useful for certain types of low-traffic sites with limited 
config needs.  But once you get a large enough audience or want the 
freedom to add persistent services, VPSes are hard to beat.  It means 
more responsibility, but also more freedom.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Bob Sneidar via use-livecode]

Wording is a little harsh. A lot of web based systems seem to be working that 
way these days. We just got notice that we had to upgrade our Compass Sherpa 
software, which uses an embedded browser, to keep using it. Spiceworks dictates 
that the core system be updated by certain dates, or certain features will no 
longer be supported. I do not think this is an issue with On-Rev, but rather 
the general nature of web based apps themselves. 

The self-contained nature of locally hosted apps shielded us from this, as 
company A could upgrade if they wanted, and company B did not have to. This 
sucked for the software vendor because how long were they expected to support a 
release? With web hosted products, regular updating is going to be par for the 
course, and if it's problematic with Wordpress in that it seems that plugins or 
addons may also have to be updated, well that is the nature of the thing. 

Bob S


> On Dec 6, 2017, at 12:18 , Rick Harrison via use-livecode 
>  wrote:
> 
> I objected to the fact that Run-Rev hyped Wordpress to
> it’s On-Rev users, and after encouraging them to 
> snap it up, then later slapped them. 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Rick Harrison via use-livecode]

Hi Richard,

> You use Wordpress. 

After exploring Wordpress a couple of years ago I decided not use Wordpress.
I do not use Wordpress.

> I use Drupal.  Someone else uses Joomla.  Then there's the vast range of 
> other things people can add to their account.


Yes, many people use different tools as we all do.

> Web hosting is a very difficult business, which is why we've seen so much 
> consolidation over the years.


No one said Web hosting was an easy business,
but it needs to be become better.  No company should
threaten it’s users to do XYZ upgrade or suffer the
loss of their accounts.  If it is that important, then the
company should make the upgrade process very
simple or automatic, or not offer that particular piece
of software if it is so vulnerable that it threatens the
security of the entire system.

I objected to the fact that Run-Rev hyped Wordpress to
it’s On-Rev users, and after encouraging them to 
snap it up, then later slapped them. If you
don’t monitor Wordpress closely to be sure it is
always up to date, then you lose your account!
(That’s just not a good way to conduct business,
and I’m glad that I personally didn’t fall into that trap.)

When On-Rev was first introduced, the impression given
about the service to users was that it was indeed going to 
be a highly managed service.  That has not turned out to
be the case clearly as you and Simon have pointed out.
(I think a bunch of people may have been disappointed to learn
the truth of that matter as it has played out over the years.)

The result for me as a user of On-Rev is that I only use it
for small websites that I don’t have a large investment of
money, time or energy in.  It has proven to be an
undependable platform for me. Now I run all of my
own important servers, which are dependable. 
I upgrade them, and keep them secure at all times.

Thanks for the lively discussion!

Cheers,

Rick








> On Dec 6, 2017, at 2:32 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> You use Wordpress.  I use Drupal.  Someone else uses Joomla.  Then there's 
> the vast range of other things people can add to their account.
> 
> Where does a hosting company draw the line with what they can afford to 
> directly support by managing what goes on inside of 200 accounts per machine?
> 
> Or do they take the safest option and disallow everything other than a small 
> subset of packages they directly manage?
> 
> Web hosting is a very difficult business, which is why we've seen so much 
> consolidation over the years.
> 
> The most successful companies (the ones that survived the shakeout of the 
> last decade and are still around to grow) tend to work as Simon described: 
> unmanaged services require a responsibility from the user, managed services 
> take care of those things but at a much higher price.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Rick Harrison wrote:

> If it were up to me to run On-Rev, I would make
> sure that it was always up to date, or offered
> easy ways to keep everything up to date.  You’d
> never hear me threaten anyone to take away their
> account if they didn’t keep some piece of software
> up to date.  If that software poses a security risk,
> as a good steward, I would take care of that issue
> for my clients so they wouldn’t be at risk.

You use Wordpress.  I use Drupal.  Someone else uses Joomla.  Then 
there's the vast range of other things people can add to their account.


Where does a hosting company draw the line with what they can afford to 
directly support by managing what goes on inside of 200 accounts per 
machine?


Or do they take the safest option and disallow everything other than a 
small subset of packages they directly manage?


Web hosting is a very difficult business, which is why we've seen so 
much consolidation over the years.


The most successful companies (the ones that survived the shakeout of 
the last decade and are still around to grow) tend to work as Simon 
described: unmanaged services require a responsibility from the user, 
managed services take care of those things but at a much higher price.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Simon Smith wrote:
> PHP is definitely the most popular language for letting you code this
> way, but then it is pretty much only for the web unlike most other
> languages.
>
> Other languages can work this way too - e.g. Python has PSP, Java has
> JSP as does Ruby, Lua etc. but not as popular as PHP.

There's a difference in terms of the primary execution object, and how 
that effects the flow of both execution and the workflow.


It seems I'm unable to articulate it clearly enough, but no worries. 
The bottom line is that LC Server scripts are incompatible with LC 
Script on the desktop, and when used with wrapped HTML there's no need 
for me to generalize my tools because they can't be used in that context.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Simon Smith via use-livecode]

It's impracticable for most hosting companies to keep a clients WordPress
installation up to date. All the plugins and themes need to be kept up to
date at the same time and sometimes need to be manually uploaded. There is
then a problem that if a host updates something and something breaks - who
would pick this up and who would be responsible for fixing the problem.
Then there are also updates that require manual intervention, like changes
to the database etc, and sometimes you may not want something updated
either.

There are a couple of hosting companies that offer this as a managed
service - but it comes at quiet a cost and you will face a limit as to what
plugins etc you can use.

While WordPress is considered secure and actively audited, most themes and
plugins are not, and problems do creep in. A website (not just WordPress)
that gets hacked can do a fair amount of damage, it affect other sites on
the server and when things like IP addresses get black listed, it's a bit
of nightmare for the host. Most hosts are pretty understanding (despite
what their terms and conditions may say) and if they discover a problem
they will notify you, or in serve situations take the site offline and ask
you to fix the problem, before putting the site live again.

While WordPress is a fantastic platform, it does require regular upkeep -
it's not something you can setup and just leave. There are dashboards you
can use (e.g. JetPack, WP Remote etc) that let you manage single or
multiple sites from a single location offering convenient way for keeping
an eye on what needs to be updated.

Simon






Carpe diem

*Simon Smith*
m. +27 83 306 7862

On Wed, Dec 6, 2017 at 7:34 PM, Rick Harrison via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Matthias,
>
> When support tells one that he/she is now responsible
> for keeping Wordpress up to date or face the loss of
> one’s account, they should at least point out what you
> have shared with us.
>
> > And you if install Wordpress through Softacoulus (which is included in
> On-Rev), you can enable auto upgrade in Softacoulus in  the config area for
> your WP installation.
> >
> > So regardless how you have installed Wordpress, you can enable auto
> upgrade.
>
> No one who has not yet installed Wordpress would know
> about the automatic upgrade capability.  It is also highly
> unlikely that any user would be willing to log into his/her
> account every hour of every day just to make sure that
> Wordpress is up to date so they don’t lose their account.
>
> What version of LC is currently installed on On-Rev?
> It was pretty old the last time I checked.  Perhaps an
> option to easily upgrade to the newest version of LC
> on On-Rev should be offered?
>
> A lot of people paid a bunch of money for On-Rev,
> and then when support at Run-Rev discovered it
> was more work than they bargained for, they
> outsourced it to other companies.  The first time
> it was outsourced, the result wasn’t good.  Things
> are better than they were, but there is still room
> for improvement.  Whenever a company accepts
> people’s money, that company has an obligation to
> provide better than average service if they want
> to stay in business.
>
> If it were up to me to run On-Rev, I would make
> sure that it was always up to date, or offered
> easy ways to keep everything up to date.  You’d
> never hear me threaten anyone to take away their
> account if they didn’t keep some piece of software
> up to date.  If that software poses a security risk,
> as a good steward, I would take care of that issue
> for my clients so they wouldn’t be at risk.
>
> Just my 2 cents for the day.
>
> Thank you for your helpful information about
> Wordpress etc.
>
> Cheers,
>
> Rick
>
>
>
>
>
> > On Dec 6, 2017, at 6:33 AM, Matthias Rebbe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> >
> >> Am 06.12.2017 um 07:14 schrieb Rick Harrison via use-livecode <
> use-livecode@lists.runrev.com >:
> >> Then On-Rev wrote us that note saying that we were
> >> the ones that would be held responsible for
> >> ensuring that Wordpress was always up to
> >> date on our accounts or we could lose our
> >> accounts.  (I thought maintaining up to date
> >> versions was supposed to be the job of
> >> On-Rev as good care takers.)
> >
> > If you install Wordpress manually from a Zip file then you are
> responsible for keeping that version up to date. Either by manually updates
> or by automatic updates.
> > You can enable that in wp-config.php
> >
> > And you if install Wordpress through Softacoulus (which is included in
> On-Rev), you can enable auto upgrade in Softacoulus in  the config area for
> your WP installation.
> >
> > So regardless how you have installed Wordpress, you can enable auto
> upgrade.
> >
> > Why should On-Rev support do this for you?
> >
> >
> > Matthias Rebbe
> > Tel +49 5741 31
> > ‌https://matthiasrebbe.eu ‌
> > 

Re: LC Server style survey: co-mingle code w/HTML?

[Rick Harrison via use-livecode]

Hi Matthias,

When support tells one that he/she is now responsible
for keeping Wordpress up to date or face the loss of
one’s account, they should at least point out what you
have shared with us.

> And you if install Wordpress through Softacoulus (which is included in 
> On-Rev), you can enable auto upgrade in Softacoulus in  the config area for 
> your WP installation.
> 
> So regardless how you have installed Wordpress, you can enable auto upgrade.

No one who has not yet installed Wordpress would know
about the automatic upgrade capability.  It is also highly
unlikely that any user would be willing to log into his/her
account every hour of every day just to make sure that
Wordpress is up to date so they don’t lose their account.

What version of LC is currently installed on On-Rev?
It was pretty old the last time I checked.  Perhaps an
option to easily upgrade to the newest version of LC
on On-Rev should be offered?

A lot of people paid a bunch of money for On-Rev,
and then when support at Run-Rev discovered it
was more work than they bargained for, they
outsourced it to other companies.  The first time
it was outsourced, the result wasn’t good.  Things
are better than they were, but there is still room
for improvement.  Whenever a company accepts 
people’s money, that company has an obligation to 
provide better than average service if they want
to stay in business.

If it were up to me to run On-Rev, I would make 
sure that it was always up to date, or offered
easy ways to keep everything up to date.  You’d
never hear me threaten anyone to take away their
account if they didn’t keep some piece of software
up to date.  If that software poses a security risk,
as a good steward, I would take care of that issue
for my clients so they wouldn’t be at risk.

Just my 2 cents for the day.

Thank you for your helpful information about
Wordpress etc.

Cheers,

Rick





> On Dec 6, 2017, at 6:33 AM, Matthias Rebbe via use-livecode 
>  wrote:
> 
> 
>> Am 06.12.2017 um 07:14 schrieb Rick Harrison via use-livecode 
>> >:
>> Then On-Rev wrote us that note saying that we were
>> the ones that would be held responsible for
>> ensuring that Wordpress was always up to 
>> date on our accounts or we could lose our
>> accounts.  (I thought maintaining up to date
>> versions was supposed to be the job of
>> On-Rev as good care takers.)  
> 
> If you install Wordpress manually from a Zip file then you are responsible 
> for keeping that version up to date. Either by manually updates or by 
> automatic updates.
> You can enable that in wp-config.php
> 
> And you if install Wordpress through Softacoulus (which is included in 
> On-Rev), you can enable auto upgrade in Softacoulus in  the config area for 
> your WP installation.
> 
> So regardless how you have installed Wordpress, you can enable auto upgrade.
> 
> Why should On-Rev support do this for you?
> 
> 
> Matthias Rebbe
> Tel +49 5741 31
> ‌https://matthiasrebbe.eu ‌
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Matthias Rebbe via use-livecode]

> Am 06.12.2017 um 07:14 schrieb Rick Harrison via use-livecode 
> >:
>  Then On-Rev wrote us that note saying that we were
> the ones that would be held responsible for
> ensuring that Wordpress was always up to 
> date on our accounts or we could lose our
> accounts.  (I thought maintaining up to date
> versions was supposed to be the job of
> On-Rev as good care takers.)  

If you install Wordpress manually from a Zip file then you are responsible for 
keeping that version up to date. Either by manually updates or by automatic 
updates.
You can enable that in wp-config.php

And you if install Wordpress through Softacoulus (which is included in On-Rev), 
you can enable auto upgrade in Softacoulus in  the config area for your WP 
installation.

So regardless how you have installed Wordpress, you can enable auto upgrade.

Why should On-Rev support do this for you?


Matthias Rebbe
Tel +49 5741 31
‌https://matthiasrebbe.eu ‌
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Simon Smith via use-livecode]

PHP is definitely the most popular language for letting you code this way,
but then it is pretty much only for the web unlike most other languages.

Other languages can work this way too - e.g. Python has PSP, Java has JSP
as does Ruby, Lua etc. but not as popular as PHP.






Carpe diem

*Simon Smith*
m. +27 83 306 7862

On Wed, Dec 6, 2017 at 3:23 AM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Simon Smith wrote:
>
> > Personally I do prefer to mix HTML / code together.
>
> If you mix them together with the implied extended merge of LC Server
> rather than an explicit merge with LC Script, I'm afraid nothing in my
> toolkit can help.
>
>
> > I don't think it right to say it is a PHP way to do things though :)
>
> What other languages work that way?
>
> In LC Script the primary execution object is a script, which can
> optionally pass data to be merged with an explicit call to the merge
> function.  This pattern seems more common, e.g. Ruby, Lua, Python, and of
> course SuperCard's Flamethrower project which introduced the merge function
> to the xTalk world.
>
> With PHP (and LC Server), the primary execution object is assumed to be a
> web page, with code optionally embedded in it and the merging happens as an
> implicit part of the processing.  I can't think of any other languages that
> work that way.  Am I missing some?
>
> I don't have a judgment about it either way.  A lot of people like PHP,
> and given the range of things people make with it (nearly every major CMS
> and a lot of other server frameworks where the browser is the primary
> target) it seems to do well.
>
> The only reason I'm distinguishing the style in this thread is that LC
> Server's page-centric code is incompatible with LC Script on the desktop,
> and my tools run on the desktop.
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Rick Harrison via use-livecode]

Hi Richard,

I regularly mix both .lc scripts and HTML.

I liked the original LC Web-Plugin with the exception
of the very scary download message that was forced
upon us all without any option to tone it down a bit.
Once the mothership decided to abandon it, it was
doomed.  It was still great for in-house work though
even in that state for a time.

Then I was disappointed when the LC server came out
that I couldn’t use Desktop LC code in the server the
same way that I used to be able to do with the
LC Web-Plugin.

I find now that I can mix both .lc scripts and HTML
in the same web format file.  It can be a pain sometimes
changing from double quotes to single quotes. 
Sometimes I have to build up my database calls
with more statements, and concatenations than
I’d like to, but at least it all works now.

CMS are interesting, but I usually find that whatever
it is that I want to do, the proper add-on I’m looking
for just doesn’t exist as I tend to want to do things that
aren’t normal everyday kinds of applications that
everyone else wants to do.  Every job I do tends to
ends up being a custom one.

I thought all the hype about Wordpress and LC
working together sounded interesting.  Then
On-Rev wrote us that note saying that we were
the ones that would be held responsible for
ensuring that Wordpress was always up to 
date on our accounts or we could lose our
accounts.  (I thought maintaining up to date
versions was supposed to be the job of
On-Rev as good care takers.)  Oh well, I was
glad I had decided not to go that route so it
wasn’t a problem for me at all.

I just love the way new things are announced
as the latest and greatest, and then a few
months or a couple years later abandoned.

The change over time of everything in the 
computer world is way too fast, and as a 
result unstable.  That is why we don’t have
true artificial intelligence yet.  Every time when
it looks like some breakthrough might occur,
someone decides it’s time that everyone go
through a forced update that screws up all
one's carefully crafted code.  They break it!

Have you noticed now many companies are
saying they have developed an AI that does
task XYZ.  What they have really done is
write a program that is better than the
previous version of what they made.  That
is not AI.  I suppose perhaps they are calling
it that to either get more funding, marketing
attention, or both.

If artificial intelligence ever did evolve it would
have the same problem.  Update……Update..
Update..Update.Upda.Up.U.ding.ding..g..
Godlike thinking power achieved..ding update..
No time to spend doing anything except..update ding!

Oh sorry, I guess you didn’t ask for a rant. Update ding! ;-)

Cheers,

Rick


> On Dec 5, 2017, at 1:18 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> I have some tools I developed for server apps, which allow me to develop and 
> test both client and server within the same local LC IDE instance. As you can 
> imagine, this has improved development efficiency by orders of magnitude.
> 
> It's much a much more xTalk-like way of working, and once you use it having 
> to be tied to a server for every little test feels like building a ship in a 
> bottle with tweezers while wearing a blindfold.
> 
> When I started making these tools I was using standalones exclusively for 
> server work, partly because it reflects my habits gained from using LC as a 
> CGI for many years before LC Server existed, and partly because I have no 
> need to co-mingle code in HTML like PHP does, except a few cases where the 
> merge function works quite nicely.
> 
> Thinking about this more recently, it seems these tools need not be limited 
> to server deployments using standalones, and may be modified to provide the 
> same server emulation for deployments that will use LC Server.
> 
> However, because the desktop version of LC has no means of executing LC 
> Server scripts (due to the HTML wrapped around any code), the ability to 
> enjoy such a fluid workflow is limited to those server apps where the .lc 
> scripts contain only directives to load standard LC Script libraries.
> 
> That limitation fits my own work, including current work for one client. But 
> does it fit yours?
> 
> How many of you using LC Server rely on its PHP-like model that encourages 
> mixing HTML with LC code?
> 
> Or maybe the better question might be:
> 
> How many of you have server systems that already separate HTML from server 
> code like most non-PHP solutions do, or could affordably transition to that 
> model if it could simplify your development workflow significantly?
> 
> Side question for the dev team if they see this:
> 
> Would it be reasonable/affordable to add some means of enhancing desktop LC 
> so that it can at least parse and attempt to execute LC scripts embedded in 
> HTML?  I can emulate environment variables and the like, but the 
> incompatibility between LC and .lc has been a real development bottleneck.
> 
> -- 

Re: LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

Simon Smith wrote:

> Personally I do prefer to mix HTML / code together.

If you mix them together with the implied extended merge of LC Server 
rather than an explicit merge with LC Script, I'm afraid nothing in my 
toolkit can help.



> I don't think it right to say it is a PHP way to do things though :)

What other languages work that way?

In LC Script the primary execution object is a script, which can 
optionally pass data to be merged with an explicit call to the merge 
function.  This pattern seems more common, e.g. Ruby, Lua, Python, and 
of course SuperCard's Flamethrower project which introduced the merge 
function to the xTalk world.


With PHP (and LC Server), the primary execution object is assumed to be 
a web page, with code optionally embedded in it and the merging happens 
as an implicit part of the processing.  I can't think of any other 
languages that work that way.  Am I missing some?


I don't have a judgment about it either way.  A lot of people like PHP, 
and given the range of things people make with it (nearly every major 
CMS and a lot of other server frameworks where the browser is the 
primary target) it seems to do well.


The only reason I'm distinguishing the style in this thread is that LC 
Server's page-centric code is incompatible with LC Script on the 
desktop, and my tools run on the desktop.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC Server style survey: co-mingle code w/HTML?

[Simon Smith via use-livecode]

Personally I do prefer to mix HTML / code together.

I don't think it right to say it is a PHP way to do things though :) -  PHP
does not encourage one to go this route for what I think is usually called
spaghetti code.

While some platforms, like WordPress have done quiet a bit to encourage
this style of coding with it's plugins and theme development  - there are
many PHP developers who are very public in their dislike for such
"barbaric" coding practices and also numerous frameworks that don't
support/encourage mixing html/php either.

Personally I think it is one of the reasons that lead to the popularity of
WordPress as it makes certain tasks very easy to, even if you don't have
much coding experience.

Yes it does depend on what I am doing, but for the most part, I don't have
any issues mixing code and HTML together.




Carpe diem

*Simon Smith*
m. +27 83 306 7862

On Tue, Dec 5, 2017 at 8:18 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I have some tools I developed for server apps, which allow me to develop
> and test both client and server within the same local LC IDE instance. As
> you can imagine, this has improved development efficiency by orders of
> magnitude.
>
> It's much a much more xTalk-like way of working, and once you use it
> having to be tied to a server for every little test feels like building a
> ship in a bottle with tweezers while wearing a blindfold.
>
> When I started making these tools I was using standalones exclusively for
> server work, partly because it reflects my habits gained from using LC as a
> CGI for many years before LC Server existed, and partly because I have no
> need to co-mingle code in HTML like PHP does, except a few cases where the
> merge function works quite nicely.
>
> Thinking about this more recently, it seems these tools need not be
> limited to server deployments using standalones, and may be modified to
> provide the same server emulation for deployments that will use LC Server.
>
> However, because the desktop version of LC has no means of executing LC
> Server scripts (due to the HTML wrapped around any code), the ability to
> enjoy such a fluid workflow is limited to those server apps where the .lc
> scripts contain only directives to load standard LC Script libraries.
>
> That limitation fits my own work, including current work for one client.
> But does it fit yours?
>
> How many of you using LC Server rely on its PHP-like model that encourages
> mixing HTML with LC code?
>
> Or maybe the better question might be:
>
> How many of you have server systems that already separate HTML from server
> code like most non-PHP solutions do, or could affordably transition to that
> model if it could simplify your development workflow significantly?
>
> Side question for the dev team if they see this:
>
> Would it be reasonable/affordable to add some means of enhancing desktop
> LC so that it can at least parse and attempt to execute LC scripts embedded
> in HTML?  I can emulate environment variables and the like, but the
> incompatibility between LC and .lc has been a real development bottleneck.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin via use-livecode]

I have some tools I developed for server apps, which allow me to develop 
and test both client and server within the same local LC IDE instance. 
As you can imagine, this has improved development efficiency by orders 
of magnitude.


It's much a much more xTalk-like way of working, and once you use it 
having to be tied to a server for every little test feels like building 
a ship in a bottle with tweezers while wearing a blindfold.


When I started making these tools I was using standalones exclusively 
for server work, partly because it reflects my habits gained from using 
LC as a CGI for many years before LC Server existed, and partly because 
I have no need to co-mingle code in HTML like PHP does, except a few 
cases where the merge function works quite nicely.


Thinking about this more recently, it seems these tools need not be 
limited to server deployments using standalones, and may be modified to 
provide the same server emulation for deployments that will use LC Server.


However, because the desktop version of LC has no means of executing LC 
Server scripts (due to the HTML wrapped around any code), the ability to 
enjoy such a fluid workflow is limited to those server apps where the 
.lc scripts contain only directives to load standard LC Script libraries.


That limitation fits my own work, including current work for one client. 
But does it fit yours?


How many of you using LC Server rely on its PHP-like model that 
encourages mixing HTML with LC code?


Or maybe the better question might be:

How many of you have server systems that already separate HTML from 
server code like most non-PHP solutions do, or could affordably 
transition to that model if it could simplify your development workflow 
significantly?


Side question for the dev team if they see this:

Would it be reasonable/affordable to add some means of enhancing desktop 
LC so that it can at least parse and attempt to execute LC scripts 
embedded in HTML?  I can emulate environment variables and the like, but 
the incompatibility between LC and .lc has been a real development 
bottleneck.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode