1) ok. 2) no template needs to be parsed at runtime, since it doesn't change while you're running webcit (unless you use -T1 for debugging) While that initial parser run, subst.c tries to identify the handler for this token, which it can't if its in the SVPut hash, as thats just loaded at runtime.
if you build up a structure with the usual tmplut_* functions to put their fields into the global token namespace, this function callback can be looked up with the initial parse. The content to be done by that token is taken from the struct which the iterator prepared. so, theres very rare "need" for subst. >Mo Dez 22 2008 22:48:43 EST von m...@comalies (comalies) >Betreff: re: Citadel commit log: revision 6860 > > > > 1. Friends of LKRA already taken care of, see >GetRoomListHashLKRA<->GetRoomListHash . When someone needs to use a different >one just add another wrapper around GetRoomListHash > >2. I'm aware of that, in this case its intentional as this template needs to >be evaluated at runtime, are you saying there will still be a performance >gain in this case? > >3. Good question, for now I'm just building the JSON backend as a way of >presenting the server output in a nicer way to JavaScript. Shouldn't be any >need for one to build their own queries on client-side, named arrays could be >a possibility in the future. > > >> Dec 22 0:38 from dothebart <> >> >>Citadel commit log: revision 6860 >> >>---------------------------------------------------------------------------- >>---- >>------------------------------------------------------------------------------ >>-- >> >>Matt, three tiny comments: >> >>* LKRA has some friends with similar syntax: >>http://www.citadel.org/doku.php/documentation:appproto:rooms?s=lkra#list.comma >>nds You probably should create something that can easily handle all of them >>(maybe by some wrappers? >> >> * SVPut and friends are to be avoided in favour of passing structs through >>the context, and writing tiny callbacks. SVPut can't be pre-evaluated while >>parsing the templates, because of they're just known at runtime, while the >>callbacks are there from the start -> saves one hashtable lookup per >>occurance. >> >>* more of a question... Whats to be prefered? Anonymous arrays or named >>ones? Should we care? >> >>Should the json call be able to select the collumns its wanting to see? >>And, should it be able to select a vector of names to choose from to build >>named arrays? ala: >> >>ajax_servcmd?listnames=LKRA&select_columns=1,3,7&g_input=LKRA >> >>and listnames be looked up in a hashtable where we would find s.th. like >>that: >> >>struct json_token { int Type (= STR / INT); const char * Key, long >>Keylen(=HKEY("JSON_FIELDNAME")} >> >>struct json_array{ int nValues, const json_token** types}; >> >>so you could put a list of json_tokens into a json_array, and put the >>json_array into the hash named by for example LKRA >> >>the 100-evaluator could lookup them, select the columns you need, decide by >>Type what it needs to do (just print the number, or rather escape a string?) >>plus add the names.. >> >> >> >> >> >> > >
