![]() ![]() Because both parsers report the character positions you can then use an OutputDocument to generate the final output with all the necessary substitutions and also being able to determine the context of each server tag in relation to HTML elements. Use your own parser for all the server tags and the HTML parser for the HTML. Do all parsing on the same source document but use different parsers. You don't need to do the expression substitution before the tag parsing. Here's a link showcasing our tag language for album templates: With a better html template parser, we would greatly simplify development of themes/skins for our software. It loses track of line numbers and derails miserably on some syntactical errors, like missing ">" characters in start tags and such. I wish to replace our home brewn parser as it dosn't handle error reporting very well. This problem seems to be the single stumbling block for us. ![]() Your library really seems like the best fit for our needs so I hope you can accomodate this request. I therefore simply cannot perform a dumb global search&replace operation before or after using your library, I need to parse these expressions just like any other elements as I traverse the element hiearchy. With each iteration, the variables referenced in the expression language syntax gets new values. I have iterator elements that encapsulate expression language syntax, iterator elements that may themselves be encapsulated in if/else elements or switch elements (nested to any level). Unfortunately I can't work it out that way, and here is why: When replacing expression language syntax with the corresponding values, I have to take the scope in account. Thanks for your reply Martin, I was anticipating that reasoning.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |