support for HTML and XML tags

Author: ulrichmerkel@web.de (ulrich-merkel)

when you want to create HTML or XML tags, the contents of angel brackets are a necessity to end up in the file unchanged. In Uniface, there is a natural conflict with the precompiler constants, which are converted during the precompiler processing. Because we can not be sure that nobody specifies a global constant "p" we need some means to protect a part of our code against the precompiler constant conversion or a special character for non-constant-angel-brackets, perhaps as an enhancement of the GOLD family? Please support my wish http://unifaceinfo.com/wishdetails/?id=270

In a couple of the Uniface 9.6 samples that are to be released I use HTML in blockdata and it works fine. There is a possibility for a theoretical conflict, but since your defines and your blockdata are in the same Uniface component, it would be a little bit strange if you ran into a conflict with yourself. But if there is a high demand for changing the behavior: - Initially I liked the idea of not converting compiler constants in blockdata. But that would create a big incompatibility with previous versions, so it is not a good option. - special gold character is difficult as we already have gold> and gold< for retrieve profiles. - #noprecompiler / #endnoprecompiler does not seem very elegant but at least it should get the job done without creating incompatibilities. - maybe %% is an idea, as we already have %%^ for a crlf when assigning text. Are we sure that does not create incompatibility elsewhere? More opnions, options, ideas are welcome.

Hi Theo, thank you for your contribution, its very good to have some additional views on that issue. My wish was sparked because a HTML file I created from sourcecode, did not work any more in the HTML widget of 9.6 from one day to the other. Someone used the same tag-id in a #for loop, but had not #undefine'd it after the #endfor. So instead of the tag the file included the value of the constant and the display was neatly messed up. "There is a possibility for a theoretical conflict, but since your defines and your blockdata are in the same Uniface component, it would be a little bit strange if you ran into a conflict with yourself." In my post above I mentioned GLOBAL constants which are not in the scope of the component. Same goes if some other programmer added something in the defines triggers (or uses a #for #endfor without #undefine). And do not forget all the things which are done already with #include procs which are not visible in the source text any more. The ones changing the include procs have no means to check any single code their code is included for sideeffects. On your %% suggestion: unfortunately %%s are not processed within blockdata and I use sometimes the combination of %%..%%% together with precompiler constants already in my coding to include the external version of fields in a string driven by a #for loop. Agreed, the #noprecompiler / #endnoprecompiler is not too elegant and we may have errors of "unbalanced ..." But if you copy some HTML file into blockdata to use it as a template, you need some instrument of protection. As it looks, this may be the "minimal inversive" implementation of that functionality. On the gold family: I think about something like GOLD{ and GOLD} as a begin-tag/end-tag replacement. Perhaps we can add another option which is converted to a "non-commenting-;" so we can #define a text including a ";" This way, we can have tags and constants mixed in a single command (expl. replace a constant with a tag in the output file). Because these combinations are brand-new, there should not be too many side-effects (beside some KTLs). Perhaps we need some enable/disable options for the ASN file to guard them. So it would be beneficial to see the enhanced GOLD-family and the #noprecompiler / #endnoprecompiler implemented.

Nasty roll-your-own version. Define global constants <html_on> as < and <html_off> as > Then write <html_on>html<html_off><html_on>body<html_off>Hello World<html_on>/body<html_off><html_on>/html<html_off>

Hi Iain, thanks for taking part in this discussion. I just tested your suggestion, but unfortunately the precompiler puzzles together something he sees as another precompiler constant and interprets it again. So nothing is gained in fact. The codeline reads: message/info "<html_on>abc<html_off>" but the ProcListing unveils: [ 1] #define html_on = < [ 2] #define html_off = > [ 3] #define abc = 123 [ 5]****** entry test_it [ 6] 1 message/info "123" [ 7] 2 end ; test_it

I should have known from the templates constants .<FIELD.<ENTITY>>

Hi Iain, no need to worry: this attempt was one of my first speculations to outwit the precompiler as well. Unfortunately, it seems hard to do the job without my wish beeing implemented. So perhaps you and MANY OTHERS will vote for this wish to make it happen (I know it's hard to deal with the wishlist, but if you click DATE twice, you will get the wish mostly on top ready to be voted) Happy New Year, Uli

The following should work: #define html_on = %%< #define html_off = %%> #define abc = 123 message/info "<html_on>abc<html_off>" ProcListing: [ 5]****** entry test_it [ 6] 1 message/info "<abc>" This is also documented: * Uniface Library > Programming in Uniface > Data Handling in Proc > Substitution in String Values "Rules for String Substitution The following rules apply: [...] * Use two percent signs followed by a left or right angle bracket (%%< or %%>) to include the angle bracket in the resulting string. [...]" Hope this helps. Kind regards, Daniel

Hi Daniel, thanks for pointing this out. In fact I have not seen this string substitution anywhere in the "whats new" section of the helpfile (or just have overlooked this line). Good to know that these substitutions work not only in "strings", but even in #defines Perhaps it would be a good idea to mention this in the precompiler pages as well. But unfortunately this does not work in blockdata because substitution is disabled in blockdata. And this is where the majority of my tags reside for the moment. But giving all angle brackets a "%%" prefix in the external editor where I slice my sample files and creating a small ret_blockdata function to remove the prefixes again may do the job. Tricky, you have to hide the %%-prefixed angle brackest in blockdata so you can replace them with ordinary brackets. I have added this plus the democode to my dIToHTML document which can be downloaded from www.uli-merkel.de