[Xerte-dev] Re: A little help digging into Xerte's internals?

Sat May 9 10:03:45 BST 2015

Ok, I going to answer your original question first....

I am afraid, it's because some temporary code was committed to develop, 
and it is not fixed yet. We are trying to make the properties of the 
pages more consistent, and we were debating whether to change the size 
attribute that takes a 'width,height' string to two separate width and 
height attributes. In order to be able to do that, and not break older 
LO's we needed a mechanism to deprecate optional properties, so I 
implemented that, and to demonstrate it, I changed the .xwd of the 
videoText page. However, I didn't change the code, so that page is 
effectively broken now. I'll fix it today.

Now to your other questions, so you will understand what is happening. I 
will start from your original e-mail, and anser them one by one, 
repeating some of John's information (sorry John):

Ok, I am going bac k to this one...

Smith, Bradley schreef op 9-5-2015 om 0:17:
> I’ve noticed that, at least for me, the “Video Width” and “Video 
> Height” properties on video pages don’t seem to have any effect. I’d 
> like to learn more about Xerte’s internals and help out by 
> troubleshooting this, so I’ve been digging around, but I’ve hit some 
> walls and only have so much time I can spend on the issue (which 
> unfortunately is making the video page pretty much unusable for me).
>
> So, in light of the recent thread about how handy it would be to have 
> more some more detailed references re how XOT content is built, how 
> about I write up what I’ve figured out, and then hopefully someone 
> more knowledgable can help me fill in the missing pieces?
>
>  1. A template page
>     like `modules/xerte/parent_templates/Nottingham/wizards/en-GB/data.xwd`
>     defines the properties you see in the `edithtml.php`
>       * …but the field definitions in here don’t look like they’re
>         intended for human consumption, so maybe they come from
>         somewhere else? like
>         `src/Nottingham/wizards/en-GB/textVideo.xwd`? If so, I haven’t
>         been able to make changes in the latter show up in the former…
>

As a developer, you would normally work with the 
src/Nottingham/wizards/en-GB files. These define the forms displayed in 
the editor. After editing the src files, you can build a data.wxd file, 
that is actually used by the system. The build script can be found 
src/Nottingham/buildXWD.txt

These individual files per pagetype are easier to maintain than the 
large data.xwd file, and the idea is, in the future to be able to 
determine the pages that are available in an installation through 
management.php.

Also, these files rae used as input to the XerteTrans website, where all 
the .xwd files are loaded and parsed, and where people can translate the 
English phrases into another language. XerteTrans uses the translated 
phrases to build translated .xwd files, to create the data.xwd file in 
another language.
>
>  1. When you save content in the editor, it is written to
>     `USER-FILES/$ID-$USER-$TEMPLATE/preview.xml`, which is read by
>     `show_preview_code()` in `modules/xerte/preview.php` when you
>     click Play.
>       * side-note: it looks like XOT saves the last ten versions as
>         `preview.xml.1`, `preview.xml.2`, which would suggest some
>         kind of revision control feature, which is cool but I’ve seen
>         no evidence of such a thing. What’s going on there?
>
When you save or play the LO from the edito, the content is saved in 
preview.xml. When you publish the LO, it is saved in data.xml. In an 
exported LO, this information is stored in template.xml. The preview.xml 
file is used by <xerte root>preview.php, which calls the appropriate 
preview.php of a module, so modules/xerte/preview.php for a Nottingham 
LO, and modules/site/preview.php for a Bootstrap LO

Similar for data.xml and play.php

The reason why we store the .1, .2 etc files, is that we are suffering 
from (very) intermittent loss of data problems, and we like to figure 
out the reason for this. To give us some extra information to work with, 
we store the last 10 versions. We don't know yet how useful this will be 
in debugging this problem. And we might extend it to some version 
control system, by enabling an end-user to go back to a previous version.

Current theory is either connection problems, or invalid XML being 
generated.

>  1. `show_preview_code()` calls show_template_page() in play.php.
>     Assuming you’re rendering as html5, this loads
>     `modules/xerte/player_html5/rloObject.htm`
>       * A fun fact I picked up here: you can append “&page=X” to the
>         url to link directly to page X of the LO. Nice!
>
See also John's remark.
>
>  1. At this point most of the heavy lifting seems to be handled by
>     `modules/xerte/parent_templates/Nottingham/common_html5/js/xenith.js`
>
That is true only for the main Nottingham template, but yes, xenith.js 
loads the preview.xml or data.xml, and then the individual pagetype 
codes dynamically. (with AJAX)

>  1. This does an AJAX call to
>     retrieve USER-FILES/$ID-$USER-$TEMPLATE/preview.xml?time=$UNIX_TIMESTAMP
>      1. First, why would you pass a url argument to a request for a
>         static file? Is there something more going on here? There are
>         some .htaccess files scattered about, but they don’t look like
>         they do anything related to this, and yet... I answer this
>         inline, because the numbering is messed up (like in the items
>         above, but didn't feel like retyping). The timestamp is a
>         trick to circumvent caching problems. The .htaccess files are
>         only used if Apache mode is switched on in management.php, and
>         gives you better readable URLs. Fair warning, though, these
>         cause sometimes problems because the rewrite rules are not
>         always tested thoroughly enough.
>      2. The xml just describes the structure of the LO, and has
>         "<![CDATA[ Enter text for the page here ]]>”where all the
>         content should be, so it must be being replaced by something…
>         No, that's an unfortinate coincidance. Your learning object
>         actually contains the text: 'Enter text for the page here'. So
>         all the contents entered by the user ends up in the
>         preview.xml or data.xml. Nothing to be replaced. The actual
>         page is renedered by the models_html5/<pagetype>.html files.
>         See also below.
>  2. …and at this point I’ve spent more time than I can justify today
>     digging around trying to get to the bottom of this problem.
>     Unfortunately I still haven’t answered question I really need to
>     answer here: where the heck does the actual page content come from?
>       * A model file like
>         `modules/xerte/parent_templates/Nottingham/models_html5/textVideo.html`
>         seems like it has to be involved, since it appears to define
>         the code that actually displays a given page type, but when I
>         make changes in this file they don’t seem to be reflected in
>         what gets rendered.
>
Again, this is only true for the Nottingham template. For each .xwd file 
from src, there is an equivalent .html file in 
modules/xerte/parent_templates/Nottingham/models_html5 with the same 
basename. This html file is used to render the data stored in the 
pagetype node. The pagetype node has the same basename as the .xwd or 
the .html file, (except text, which is a text node in the xml, but is 
called simpleText for the .xwd and the .html)

All this is combined by either the flash engine (XMLEngine.swf), or the 
html5/javascript engine (xenith.js). So, to change the behaviour of a 
page you have to change the .html file (the so-called model file). 
Historically there are two versions of the model file, the ones stored 
in modules/xerte/parent_templates/Nottingham/models, used by the Flash 
engine (deprecated), and the ones stored in 
modules/xerte/parent_templates/Nottingham/models_html5. The can access 
the data stored in the preview.xml and/or data.xml.

In your case the preview.xml contains data about the size of the video 
in two separate entities, (width and height) and the model file, still 
assumes they are stored in one (size). Sorry about that. Like I said, I 
will fix that this afternoon.

>
> I feel like I’ve gotta be close to the end of this trail (at least, I 
> dearly hope I am…), but I just don’t have any more time to spend on 
> this. Could one of the devs help me out? Then maybe this could be 
> turned into a sort of architecture overview on the github wiki to help 
> other new folks in the future.

We're working on generating proper documentation of all this.
>
> Thanks!
> —Brad
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
> _______________________________________________
> Xerte-dev mailing list
> Xerte-dev at lists.nottingham.ac.uk
> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev

-- 
--

Tom Reijnders
TOR Informatica
Chopinlaan 27
5242HM Rosmalen
Tel: 073 5226191
Fax: 073 5226196

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nottingham.ac.uk/pipermail/xerte-dev/attachments/20150509/cf80032f/attachment.html>