XUL Talk:Templates Plan: Difference between revisions

Line 1: Line 1:
== Comments [[User:Conor325]] ==
== Comments [[User:Conor325]] ==
==== why a separate condition step? ====
==== why a separate condition step? ====
As queries are free-form, conditions can be applied as part of a query. But in addition, in the current proposal, conditions are also applied per rule by the builder which would take a query's result and sift out more data before building content. The question is, is this overkill and overly complex? Why not make query scope match what must be built. If the query returns data then content will be built around it - there is no more nuance required. Want variations of content then vary the query. But isn't this less efficient? What if you want to share most of a query and add nuance in multiple rules? Well, yes, this could be supported but it adds complexity to the syntax and does it really give much more USEFUL power? BTW, in this view (queries apply all conditions and the builder just builds), the current template's conditions are its query section.  
As queries are free-form, conditions can be applied as part of a query. But in addition, in the current proposal, conditions are also applied per rule by the builder which would take a query's result and sift out more data before building content. The question is, is this overkill and overly complex? Why not make query scope match what must be built. If the query returns data then content will be built around it - there is no more nuance required. Want variations of content then vary the query. But isn't this less efficient? What if you want to share most of a query and add nuance in multiple rules? Well, yes, this could be supported but it adds complexity to the syntax and does it really give much more USEFUL power? In this view (queries apply all conditions and the builder just builds), the current template's conditions are its query section.  


BTW, my main concern with supporting generic conditions within the builder is that it delays the release of support for new query and data types.
BTW, my main concern with supporting generic conditions within the builder is that it delays the release of support for new query and data types.
40

edits