Click Event on input field

[Andy]

I plan to use this capability in several dozen books, and on several pages in each book. So my first thought was to put the <make> section (with prolog) in a common area outside all of the published book folders. Since it is like a shared procedure I only need to define it once so I was thinking maybe at load book. But you explicitly say that all these files must be within the lesson structure so maybe there is something that happens with the xml during publishing.

I also notice that all these xml files seem to use <page> as the root element. So maybe the <make> can't be at the root. But can it still exist only once per book?

Similarly, since each page using this capability in a book will have the exact same fields is there a reason to require a different xml file for every page? My choice would be to use one per book if that would work.

I understand if there is a need for unique names or something; I'm just trying to come up with a solution that is fairly clean and maintainable.

[Clifton]

All XML files need a root. When I built the engine <page></page> is arbitraily made the root element.
You can organize your XML files anyway you like; whatever works for the scope of your project. Several smaller files are generally better than one big one. Especially when debugging and editing a particular section of the document. For example, here is a partial listing of XML files using my new learn to type program.

XML File List

Image 2.png (27.74 KiB) Viewed 4279 times

Can you imagine if I chose to put all the code in these files into a only one or two documents? You will likely find out very quickly that it is much easier and logical to keep the XML code spread out between logical filenames, so when you need to add features or troubleshooot problems it becomes obvious where to look.

In addition, a project can get as large as you want and the XML Engine will just keep loading the code from your files as you navigate the application. If too much code is in a single document, then you are asking the interpreter to do a lot of unnecessary work when it is not really needed. In addition, the interpreter caches your documents, so they will only load into the DOM once; then they will be loaded from the cache on each successive page visit.

In the page listing above, each page of my project has a correponding XML document. Above that there is "an all-shared.xml" document to define shared actions. Shared actions are grouped into two different <make> elements so I can find the functions needed and edit them when necessary. In a few cases, some pages load more than one document to split up the complexity and allow me to locate issues and problems in the development process.

The real nice thing about XML is that once you have your basic page structure in place for your book, you do not have to export your book over and over again each time you change an XML document. Just change the corresponding XML file and open (or refresh) the export in your browser.

NOTE: You should always use Firefox during development, as the Firefox developer tools has no equal anywhere else! Plus Firefox does necessarily require that you always use a server to load your content.

In the long run, go ahead and experiment. As you run into issues and see how things work, you will progressively come up with a system that works for you. In the future, it may be better to make your posts and topics in the XML section of the forum to make these conversations easier for others to benefit from.