#include will include the contents of a file it references inline wherever it is called. That is handy for reusable interface elements (like the navigation area for your site) in your HTML pages. But it is also critical for managing your framework.
I recommend storing all of your framework files in a single directory. I'll assume it is called "MyFramework" for the sake of this example. You can organize them in any way you'd like in subdirectories within that one directory. But I think you will find it most convenient to keep all of your framework code in one place. So how do you include what might be many files into a web page you're working on?
First, make sure all of your framework files and directories are in the MyFramework directory. In that directory, create a new text file named "MyFramework.inc". The contents of your MyFramework.inc file might look like this:
#include "/MyFramework/myStringModule.yuma"
#include "/MyFramework/myDatabaseModule.yuma"
#include "/MyFramework/customer/invoice.yuma"
#include "/MyFramework/customer/payment.yuma"
?>
Note that paths must be separated by forward slashes, regardless of the operating system in which Yuma is running. In this case, I've used an absolute path which is evaluated from the site root directory. If I had used a relative path, Yuma would first look for the file relative to the file doing the including and then in any "include" directories specified in Yuma's server configuration.
So, to make all of the files in my framework available to the code in my HTML document, I just need to include the MyFramework.inc file with a single line and all of the others will be included in turn.
#include "/MyFramework/MyFramework.inc"
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
...
It is important to note that #include really is a preprocessor directive, not a function. All of your #include calls are evaluated before any processing takes place in your pages. If you are coming to Yuma with PHP experience, you may wonder how Yuma's #include compares to PHP's include(), include_once(), require(), and require_once(). Those four items all perform similar tasks. And they are functions in PHP, not preprocessor directives. Yuma's #include functions most like PHP's require_once() function.
If you do use a ".inc" extension for your included documents, be sure to add ".inc" to Yuma's list of Yuma File Extensions. That will instruct Yuma to evaluate the contents of the included file and keep your source safe in case someone happens to request your include file directly. Without adding the extension to your settings, Yuma will serve the contents of the include file to the browser exactly as you see it above. In other words, a site visitor would see each of the individual #include calls with their paths. If the server is set to evaluate ".inc" files, no output will be sent to the browser.
Thanks for the post. It reminds me I really must tidy up my include files. I hadn't even considered giving them a different extension.
I've blogged about one of my include files and the equivalent module in RB today.
Hopefully the link will appear at my name above.
As long as it's defined in the Yuma server settings, the file extension doesn't matter all that much; it's mostly just a reminder to you, the site developer, as to which files are meant to be accessed directly by a browser request, and which ones are just meant to be included. Of course any file in an "includes" directory is pretty clearly the latter anyway.
The only place where it might matter is in the text editor, where .yuma may be recognized as a Yuma file, and .inc might not. Of course that's not too important when the file only contains a bunch of #includes of other files, as in Brad's example above. And even this won't matter if Yuma ever gets its own IDE.
It's a shame that an IDE for Yuma couldn't be written in Yuma.
An IDE would be useful though.
RB is a rather expensive add-on if all you want to do is web development ;)
I realize it isn't quite the same, but if you are a Mac user, consider using BBEdit, TextMate, or Coda for your web development. We've added some support to all three for the Yuma language and will continue to do so.
I know this is heresy but I don't currently possess a working Mac.
My desktop development these days is only for Windows and Linux. If the BBEdit, TextMate and Coda support is available as any type of text file, I might try to port it to one of the Win32 editors.
Any suggestions?
We didn't have much luck finding Windows products comparable to these Mac text editors, so we asked around at REAL World. We still didn't have much luck. People seem to use either Visual Studio for this sort of thing, or nothing but Notepad.
However, if you (or any other readers) know of a powerful Windows text editor with plug-in language support, please let us know and we'll see what we can do.
As for Linux, there are some powerful editors there. We haven't delved too deeply into these yet, though. If you have a favorite, again please let us know.
I know that TextPad and Notepad++ are both very nice text editors. TextPad is shareware, and Notepad++ is GPL'd. Both do syntax highlighting and and other IDE type functions. Notepad++, iirc, does this with external files that tell it how to do it, so you can add new languages easily.
I must admit I mostly use vi and notepad but for syntax highlighting in the past, I've used Programmers notepad ( http://www.pnotepad.org/ ) with some success.
It's not bad for php.
The highlighting is based on fairly simple schemes in xml.
Just looked at pnotepad syntax highlighting/autocomplete again and documentation seems to have pretty much stopped long ago.
Whilst copying schemes for other languages might be a start, I doubt there's enough information to build a lexer.
Thanks for the suggestions, guys! We'll have to look at those. If any of you want to take the lead, so much the better; just let us know what we can do to help. (You might start by downloading the Mac package and poking around in the BBEdit and TextMate language files, where you'll find the full list of Yuma keywords for example.)
A programmers-editor 'par excellence' you can find at:
http://www.contexteditor.org/index.html
I use rhis Context-editor already for years now. It has numerous highlighters including HTML, PHP, several Basic-flavours, assemblers, just name it. It's an extremely fast editor. It has a batch-commands, you can define your own functions F-keys etc.
Maybe this one can help you.
SciTE is a great cross-platform open source text editor with language plug-ins.
http://www.scintilla.org/SciTE.html
I've been using HAPedit since I work with ASP and PHP. It would be great if they would incorporate YUMA into their editor.
HAP = HTML,ASP & PHP
HAPY = HTML,ASP,PHP & YUMA