I’m glad you are ok.
First Steps to Web Publishing
Panorama’s Help file has excellent information on getting your server up and running. In particular, see Panorama Server and Using an External Web Server. The simplicity it adds to getting the Apache server software configured and running is impressive.
Once you’ve got it running and responding to that degree, it’s worth noting that any static HTML pages you create for your site go to the site’s root folder. The Apache panel of Panorama X Preferences will take you right to it.
Separate from any Panorama generated pages, this becomes the place for html pages, graphics, templates and other parts of any built out web site.
The Panorama databases for your website are automatically placed inside ~/Library/Application Support/PanoramaX/Server/Public Databases. You have no need to deal with these directly other than to back up the folder for critical data.
There are many purposes for having Panorama driving a website or parts of it. For this particular example, I’m going to start with a page that requires users to log in before they can access other parts of the site.
I’ve built a fairly basic HTML page with two cells and a Submit button that I’ve renamed to Log In:
Here’s the HTML code, which can be created in any app that handles text:
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
<title>Log In</title>
</head>
<body>
<form action="/cgi-bin/panoramax.cgi?dbase~login" method="post" id="login" name="login">
<table>
<tr>
<td> Email Address:</td>
<td><input placeholder="Your Email Address" type="text" name="Email" size="20" maxlength="50" autocomplete="off" /></td>
</tr>
<tr>
<td> Password:</td>
<td><input placeholder="Your Password" type="password" name="Password" size="20" maxlength="25" autocomplete="off" /></td>
</tr>
<tr>
<td></td>
<td><input type="submit" name="submit" id="submit" value="Log In"></td>
</tr>
</table>
</form>
</body>
</html>
The default home page of any site is index.html. So for now, I’m going to name this page it to match the default and save it to my site’s root folder. As the site’s index page, it can be reached as MyURL.com.
The form action of this page directs the browser to send it to MyURL.com plus /cgi-bin/panoramax.cgi?dbase~login. This tells Apache, via panoramax.cgi, to pass the hit on to Panorama. When Panorama gets it, it’s going to look for a web published database that I’ve named dbase. Within dbase, it’s going to look for a procedure named login. So I’d better make sure that I’ve fulfilled those expectations.
My database(s) can be named anything I want.
See Creating Shared Databases
Obviously I’ll want to do much more, but for now simply demonstrating a response from Panorama, my login procedure is simply:
Let lvEmail = “”
Let lvPassword = “”
WebFormItem “Email”,lvEmail
WebFormItem “Password”,lvPassword
cgiHTML = “You submitted “+lvEmail+” as your user name and “+lvPassword+” as your password”
cgiHTML is a variable created by Panorama and holds the contents of what is being returned to the browser. If my programmed response is plain text as it is here, Panorama builds an HTML page to hold it. ( I tend to build the entire HTML page myself and Panorama respects that )
So when I click on the Log In button to submit my entries of:
Panorama responds and my browser displays:
And now I’m ready to get busy building it out however I desire.
A more ambitious and realistic version for a log in stystem will search the online database for a matching email address and password. It will accept or reject the result of the search and respond accordingly. A link on the login form such as “I forgot my Password” is also useful.
Using more advanced techniques, the HTML page can include javascript and CSS to make it very full featured and polished. It can include checks before the form is submitted to be sure the cells have been filled and that the email address is properly formatted.
Of course, this login page as a gatekeeper is just one example of what can be done with Panorama on a website. Panorama can be used solely for generating pages of information that gets updated with some frequency. You can publish a personal directory of your contacts that you can access with your cell phone. Or you can build a catalogue of your company’s products that is fully responsive to customers’ searches. How about a questionnaire to gather and process information?
Hi Jim,
I am making progress. If you believe that we learn from our mistakes, then I must be a genius by now.
I have set up a url using Noip, evrange.hopto.org. I have my Mac Mini running the PanX server, and it is set to update its IP address with Noip so it will remain reachable at this url.
I turned on the Apache server, and edited the index.html file with the login form that you posted.
That’s as far as I have gotten. Anyone who enjoys filling out login forms can try it out.
I am continuing to work through the steps in your last post.
Tom
BTW, Jim, the Shared Database link above is taking me to the Under Construction Page. I can access Creating a Shared Database within the PanX help system.
Where do I put the response code? Where is the login procedure?
I’m building the rest for you and will provide the parts. Meantime I’ll continue to post notes of how I’m doing it here.
Based on your questions and what I get via the form, it appears that what you most lack at present is the Panorama database and its single ( at present ) procedure.
If you refer to my example, I created a database named dbase and shared it as a Web Published database. For now it consists of a single procedure named login.
Rather than Panorama, I should have written PanoramaX Server.
That worked. Thanks.
cgi URL Structure
We’re dealing with URL’s built for a cgi application. For Pan X Server, that amounts to the domain name followed by /cgi-bin/panoramax.cgi?
In a URL directed to PanX Server, everything following the ? is an element of an array using tildes as the separator. PanX Server picks the array apart in order to know what to do with it. The first element is the name of the database the hit is being directed to. In this case: dbase. The second element is the name of the targeted procedure. In this case: login.
The array can be extended quite a bit with more elements that you, the Panorama programmer, can use within your procedure and any others it calls.
The two web pages shown below do the exact same thing. Functionally they are equals.
They both serve as the front door to a site being run by Panorama X Server.
Once an Email Address and Password are submitted, PanX Server will scan the appropriate database for matches. The Email Address must have the right string, but case is irrelevant. The Password must be a precise match.
The Forgot Password link on the login page requires that an email address be included before submitting to the server. If that email address is matched in the database, an email is sent from the server with the password.
Failing to find a match in any of these scenarios, the programming will respond that no such account was found. If too many matches are found ( shouldn’t happen ) it will also reject the effort to log in.
A successful login will be matched ( in this case ) to a user level that will be used to include or exclude links and capabilities in subsequently generated pages; something akin to Read Only, Read and Write type privileges although many other degrees are possible. Similarly, a Date field can be used as an expiration date for access.
And from there, the possibilities for what the website can do in exchanging information is boundless.
The difference in the two web pages below is that one is pretty much bare bones HTML. The second has the benefit of CSS styling to give the page some visual appeal. Panorama doesn’t care which approach you take and works with either equally well.
BTW, I respect intellectual property rights. I am in contact with the illustrator regarding the right to use the image in a limited manner.
There is. See Mailbox in the Database Exchange. It can be used on your Desktop machine to send one or many emails from a Panorama database.
Mailbox uses a Python script and can differentiate between Python versions to correctly process the sending.
Currently there is an error in the Python script, exclusively when attachments are included, but merging data and embedding graphics is working properly.
Thank you, Jim.
After failing to get Python working to send an email, I tried using Panorama’s sendemail statement. While a database on the server machine can use sendemail without a, when the server tries to send an email I get an error:
Panorama X Server Error: Error: Not authorized to send Apple events to Mail.(-1743)
Does anyone know how I can fix this?
BTW, is it unclear what I mean when I say “the server tries to send an email”?
Yes, it’s unclear, possibly because of a missing word in the second sentence? (“can use sendemail without a,”): without a what?
Sorry, I meant to say “While a database on the server machine can use sendemail without a problem, when the server tries to send an email I get an error: …”
Do you mean that you can send email from a copy of PanoramaX.app running on the server computer, but you cannot send email from a copy of PanoramaX Server.app? I think that must be what you mean.
In recent versions of macOS, Apple Events are locked down. At some point you must have given permission for PanoramaX.app to send Apple Events to Mail.app. You’ll need to give the same permission to PanoramaX Server.app. The exact procedure for this depends on what version of macOS you are running, but I know this is done using the System Preferences/System Settings window.
If you are running Monterey this window is now completely different.
Note that I’ve never needed to give PanoramaX Server.app permission to send Apple Events, so I don’t know if there are any special roadblocks that you will encounter.
Actually, I’m not sure if using Apple Mail is a good idea from the server. I think when you do that it involves the user interface of Mail, which you wouldn’t want to run from the server. You want server requests to be handled completely silently, without invoking any user interface in Panorama, Mail or anything else. I think you would be much better off getting Python to work, or to use mailgun as I explained a couple of months ago.
I just noticed that AWS has macOS computers available in their cloud… has anyone tried running the Panorama server from there? (either database sharing or web sharing) I dont know AWS that well but this seems like something fun to explore…
cw
I haven’t looked at it lately, but when it was announced the pricing wasn’t really good for a 24/7 application like a server. It’s billed hourly, I think they are intending it for intermittent applications like rendering, maybe Xcode builds, things like that.
Email with Attachments can be sent from Panorama using Mailbox in the Database Exchange. It requires that you set up your email configuration just as you would in Apple Mail. Per the included Help you can assign values to five specified variables then call Mailbox from any other database to send your message and attachments:
FileGlobal fgToEmail, fgCcEmail, fgSubject, fgMessage, fgFiles, fgResult
fgToEmail = To
fgCcEmail = CC
fgSubject = Subject
fgMessage = Message
fgFiles = lftocr(Attachments)
fgResult = ""
Local lvCaller
lvCaller = info("DatabaseName")
FarCall "Mailbox",".SendMail",lvCaller
Back to the original topic…
For sure, one of the things you want to do with Panorama on a web site is to put info from a database into an HTML page. Just as in any Panorama form, the physical arrangement can vary greatly, depending on what you’re trying to present.
Where you might use a Text List or Matrix on a Panorama form, an HTML table is a common equivalent.
Built into Panorama X is the ability to do a very nice job of this for you.
htmldatatable allows you to build a table from elected data, control its appearance, embed links and much more. It’s truly an impressive statement and is probably as much as many users ever need.
Of course, there’s always the ability to take on the task yourself, but why? Maybe you want to include some variables, formula results, more detailed design using CSS,… Or maybe it’s just a contributing element of the final page you want to present.
I make a lot of use of arrays in my HTML construction. In that array, some elements may have calculated data and/or links. Often there is more than one table, there are other generated links, variable contents to be merged into the head of the page.
An element in a cr() separated array named MyData might look like:
FieldOne+tab()+FieldFive+tab()+lookup(…)+tab()+{<a href = "/cgi-bin/panoramax.cgi?dbase~procedure~addlinfo~}+IDField+{“>Edit My Order</a>}
There are a couple of ways to convert it to an HTML table.
For instance:
ArrayFilter MyData,MyData,cr(),{<tr><td>}+replace(import(),tab(),{</td><td>})+{</td></tr>}
Those of you familiar with HTML will recognize this as an incomplete table. Yup, it’s missing the necessary opening and closing tags, but Panorama makes quick work of that for me:
{<table>}+MyData+{</table>}
Now I have a complete HTML table ready for inclusion in my finished page.
Here’s one that’s loaded with Panorama touches, including many you don’t see since it’s load with javascript actions that were modified by Panorama to fit the situation.
In this case, a paleontologist working anywhere in the world can log in to enter information about Samples from a site. The page is assembled by Panorama with much of it pre-built and saved as a template with static elements in place and markers embedded for where Panorama will merge data and variables.
The table is on the right. At the top are links built to match the user’s account. On the left is content that can be posted back to the appropriate record in the Panorama database. Popup menus have been built to match specifics in the record being edited, and are tied to javascript that was also modified to fit those same specifics.
Just one way to apply Panorama on the web.