Community
Participate
Working Groups
Created attachment 200856 [details] hypothetical simplified/clarified syntax for tokenizer (parser) It would be desirable to simplify some of the tokenizer syntax by making the following changes: 1. <target> has been eliminated 2. <append> has been eliminated 3. <set>, <put>, <add> replaced by: <attribute> <property> The name field will be taken as the unique identifier. If the "name" field is set, the following occurs: a. the current env is searched for that object; if it exists, it is used b. else the current map of dynamic objects is searched, and if that object is found, it is used c. else, a new object is constructed and its fields are set. If the name field is set, it is placed in the dynamic map; an ordered list of all such objects is also maintained, so that upon completion of the parsing, they can be merged together with the first property preceding it in the list that is not anonymous (no name; this is similar to how the parser works currently). 4. <entry> is replaced directly by <add> and <put>, which are understood to refer to List and Map objects for the 'value' field: <add>@2</add> for a list; and <put key="@1">@2</put>; 5. The test object now is simplified; while recursive test using op=AND,OR,NOT is still possible, the comparison tests work the same way as <attribute> and <property>, i.e., <test name="status" op="EQ" value="Q"> <property name="status" value="QUEUED_ACTIVE"/> </test> means: if the value field of the status object is equal to Q, set it to QUEUED_ACTIVE. Use of Java introspection/reflection is eliminated. Attached are the original tokenizer examples rewritten to conform to these hypothetical changes.
Oh, yes, it should be apparent from the examples that valueGroup valueIndex etc. now are represented by something like @1. Every string value that is set will have to be replaced for each index of the regex group/split (a bit more work, making this polynomial time, but the number of such operations in most cases should be small enough for it not to matter). The iteration should proceed backwards so as to replace longer strings before shorter ones: for ( int i = array.length - 1; i >= 0; i--) { fieldValue = fieldValue.replaceAll("@" + i, array[i]); }
I just realized that some provision must be made for being able to replace the name of an attribute that exists (that's how the jobId mechanism works). So we will probably need to retain the "ref" field on the attribute/property placeholder: <property ref="jobId" name="@1@3" ...> etc.
