Hi i have a problem with LunaExpress example with sqlite inmemory database.
AloeExpress reponds correct the first time i query data from the rest client.
The following requests respons database error Nr 1
The dbconnection error text tells me that there is no table with that name in my database.
How to use LunaExpress with inmemory db?
@Kato Gangstad: Without seeing your project, it’s hard to say with certainty what is causing this.
However, I suspect that the in-memory database SQLite database is being created when the first API request is being processed, then the database goes out of scope and is destroyed, and the second request is assuming that the database still exists (or that it will be in the same state that the first call left it in). In other words, it could be that the in-memory database isn’t being created in a scope (App-level) that will allow it to persist between the API calls.
That’s just a hunch, but it might help you to troubleshoot. If this doesn’t help, let me know, and I’ll try to work up a demo that uses an in-memory database.
Thanks for answering @Tim Dietrich
I found a solution for my problem:
LunaExpress Process metod I commented out this line:
DBConnection.CloseThis made my public App level database go NIL on me.
Can I run my app like this ?
Additional info:
LunaExpress DatabaseInit metod is like this:
DBConnection = App.DBDiscoveredI would guess just make sure to close the database when you exit the app then.
@Tim Dietrich ,
Hope life is treating you well. 
After going down the Python route over the last few weeks for a SaaS rewrite, I’ve decided to return to Xojo but use your Aloe to power the web application. After looking through all the demos I’ve decided to focus on using the MustacheLite template as it appears to be amazingly straight forward.
Having said that, I did notice in the notes that you might deprecate it in the future. What is the chances of this occurring? I really like the simplicity of its use for building out sites with data.
Thank you…
Hi @Robert Litchfield!
There’s a long story behind that “possible deprecation” comment, but I’ll spare you some it by simply answering the question that you asked: “What is the chances of this occurring?”
My answer: Very low.
If you’re interested, here’s the story behind that deprecation comment and why I’ve reconsidered…
I think that the MustacheLite class that’s is helpful and easy to use. However, it was a nightmare to implement. There are some things that I think it desperately needs (such as Helpers, Partials, false values / empty lists), and I have a feeling that adding those is going to be a challenge.
So I started to think that maybe server-side templating didn’t make sense, and realized that I could just pass data down to the client, and use an established Javascript-based templating option to handle the merge. I experimented with using client-side, Javascript-based versions of Mustache (ex: https://github.com/janl/mustache.js) as well as Handlebars (http://handlebarsjs.com). (BTW, Handlebars is really, really nice, and I recommend checking it out if you have some time. )
What I found was that while the client-side templating options are also easy to use (and much more powerful than my MustacheLite class), using them doesn’t always make sense. The major drawback to using them is that you often end up having to send down a lot of data to the client in order for it to be merged. I’ve also run into situations where the business logic that needs to be applied to the data is best applied upstream on the server. And, of course, there’s the additional client-side overhead involved in loading the JS libraries, doing the merge, etc.
To summarize: I think there are cases where client-side templating makes sense, and times were server-side templating makes sense - and I think we really need to be able to do both. Therefore, the MustacheLite class’s future is looking good.
This is great news.
I did checkout Handlebar JS and liked what I saw, however, what I couldn’t get my head around was how to pass the data to the client in a secure manner. If I was to build the backend using Xojo/Aloe and pass the appropriate JSON to the client, how could I secure that data so that someone else couldn’t build a web client and simply take it. While I’m sure there is a solution, I just don’t grok it at the moment.
Your MustacheLite solutions removes this concern for me as it all happens in the server and only the results (HTML) is passed to the client.
@Robert Litchfield: Agreed, and that’s another potentially huge downside to doing the merge on the client-side. You have to be very careful about what you deliver in the data payload.
There’s a new demo in the latest Aloe Express project file which shows a simple example of client-side templating. In that example, there’s an XMLHttpRequest made to the server for the data. The benefit of this approach is that if the data is likely to be refreshed, the client can just reach out for the data instead of pulling down the entire page.
When I have time, I’ll take another pass through MustacheLite and see if I can’t add some of those things that I think it needs. I’d also like to get a Handlebars-like class in the Templates module as well. In the meantime, please let me know if you have any feedback about the current MustacheLite class, or anything else AE-related.
Will do Tim… Thank you for the work your doing to support the community!
@Tim Dietrich … Is there something special that needs to be added to the MustacheLite class when adding a new module? I have basically recreated your DemoTemplatesServerSide and it will not load the JSON file. However, if I copy your full DemoTemplatesServerSide module directly into my project, along with the appropriate template HTML & JSON files, it works without a problem.
A few things I’ve tested are:
My generate file:
// Get the orders as a JSON string.
Dim Lang As String = AloeExpress.FileRead(Request.StaticPath.Parent.Parent.Child("data").Child("lang.json"))
// Create a Template instance.
Dim Template As New Templates.MustacheLite
// Load the template file and use it as the source.
Template.Source = AloeExpress.FileRead(Request.StaticPath.Child("login.html"))
// Use the contents of the JSON data file as the merge data source.
Template.Data = New JSONItem(Lang)
// Pass the Request to the Template so that request-related system tokens can be handled.
Template.Request = Request
// Merge the template with the data.
Template.Merge
// Update the response content with the expanded template.
Request.Response.Content = Template.ExpandedI’m sure it is something small and stupid that I forgot, but a few hours of debugging hasn’t helped fix the issue. 
@Robert Litchfield : It sounds like the FolderItem that you’re passing to the FileRead method is invalid.
I would check this - Request.StaticPath.Parent.Parent.Child(“data”).Child(“lang.json”) - to be sure that it really is pointing to your JSON data file.
@Tim Dietrich … After a good nights sleep and with fresh eyes, I’ve found the issue. It was with the path as I had one to many .parent in my code. Once I fixed that…everything came up golden. I’ll let you know if I run into any non-user issues.
Hi everyone. I’m working on Aloe Express 4.0, which adds support for WebSockets.
To test AE 4.0, I’ve put together a very basic chat app. I’m looking for a few people to login and give it a try.
If you have a few minutes and would like to help, please PM me and I’ll send you information on how to connect.
Thanks in advance.
A quick “thank you” to @Kem Tekinay and @Seth Ober for testing the AE chat app today.
Hi again.
As I mentioned yesterday, I’m adding support for Websockets to Aloe Express. I’d like to get some more feedback on it, and see how well it holds up under load.
If you are interested in helping out, please go to https://chat.aloe.zone, choose a username, and start chatting.
Please keep in mind that this is a very basic chat app, with a minimal interface and not much in the way of features. And there’s likely a few bugs crawling around in there, too.
It’s 12:45PM EDT. I’ll keep the app running until around 1:00PM - maybe longer if there is interest.
Thanks.
22 on the forums, cmon lurkers, click the link and join in the test
We ended up with around 6 users in the chat. Thanks everyone!
Just missed it. And I had such clever things to chat about. 
Good morning from rainy Richmond, Virginia.
I’m testing Aloe Express’s WebSockets support again this morning, and have the demo chat app up and running.
If you’re interested in helping to test, please join us at: https://chat.aloe.zone.
The app should be up for a few hours, unless something goes terribly wrong.
I just tried connecting from my phone as Im out and about. It connected but my messages werent coming out but I could read yours. iPhone