Login  Register

NAML Feedback

Posted by DavidJCobb on Mar 15, 2012; 9:07pm
URL: https://support.nabble.com/NAML-Feedback-tp7377071.html

I just released an update for the NAML on Reaching Perfection. As I developed it, I noted things to ask about or suggest; here are the notes I came up with:

PROBLEM: Strings that contain null


If a string contains line breaks in addition to <n.null/>, that string becomes a ticking time bomb. The standard null-handling macros -- even binary ones like "is_null" and "default" -- will fail to detect the null, but it will still cause errors if the value is written to the page or passed to any string-handling macro.

The situation that triggered this bug for me was a macro that output <n.null/> deliberately if a set of exception checks failed. Even though the macro used the "unindent" attribute, the line breaks contained in its code were still returned along with the null. The caller stored the return value in a var, essentially making that var "toxic" in the manner I have described.

I worked around the bug by simply wrapping the processing parts of the null-returning macro in a call to "no_output", such that no line breaks were produced. However, it does seem as though "is_null" and friends ought to be able to detect strings that contain null, in addition to values that are null and only null.

Simplified test case: <n.default to="No bug" text="[n.crlf/][n.null/]"/>


PROBLEM: Some HTML tags are not recognized


THEAD and TFOOT are not recognized as valid tags, and will trigger errors if used.


SUGGESTION: Arbitrary node lists


I couldn't find any way to persistently store an arbitrary node list, or to easily convert something similar (i.e. a string of comma-separated IDs) into one.

For the Portfolio Index, I used a string list stored as a property on the root node. I rigged up a macro that allowed me to paginate the list, but since I'm not using a real node list, I can't sort the nodes by their subjects, last post dates, or anything that a real node list could offer.

This is more of a nice-to-have thing than an urgent feature.


QUESTION about translations


I noticed that some strings are wrapped in "T" tags, and after doing some research, I learned that this is part of your translation system. My question is, if I use "T" tags to wrap a string that doesn't have a translation, would that cause errors?

(My thinking is that if others want to use any features I've created with NAML, wrapping the strings in "T" tags would allow them to translate them without having to manually edit the macros.)


SUGGESTION: Reading cookies from NAML


I don't know how feasible this would be, but I can see a few uses for reading and writing cookies from NAML.

For example, one might allow mobile users to view a "gateway" page, which sets a cookie to signal that the user is on a mobile device. Then, NAML code could be used to check the cookie and tailor certain pieces of output for mobile devices (i.e. no embedding redirection since many mobiles don't support IFRAMEs, and writing a SCRIPT tag for jQuery Mobile instead of standard jQuery). Granted, it'd probably be better to build an entirely separate part of the app for mobiles, rather than just tweaking a desktop-oriented app, but the latter could serve as a decent step toward the former.

Much of what this idea would accomplish could be done through JavaScript alone. Doing it through NAML may make the code cleaner, though. Nice-to-have, but not essential.


PROBLEM: Error pages don't escape tags


On the Error 500 page, angle brackets in the stack trace are escaped when the trace is written to the page's TITLE, but they are not escaped in the page's BODY. This means that one must view the page source to see the trace.


SUGGESTION: Control over unhandled exception output


If an exception occurs and is caught with handle_exception, but there is no n.exception call for that specific exception name, then a message is printed at the bottom of the handle_exception block, noting the unhandled exception and its name.

This is a very convenient feature, but it would be nice to have more control over the output (just in case some unanticipated exception occurs in a final product rather than on a test app). Perhaps it would be possible to add macros like "has_unhandled_exception" and "print_unhandled_exception" for this?