XUL Talk:Templates Plan: Difference between revisions
| Line 3: | Line 3: | ||
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? | 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. | BTW, in this view (queries apply all conditions and the builder just builds), the current template's conditions are its query section. I know the argument might be - want to keep your templates simple, be my guest and such a subset is supported. My only concern with supporting generic conditions within the builder is that it delays the release of support for new query and data types. | ||
==== RDF caching and refresh ==== | ==== RDF caching and refresh ==== | ||
Revision as of 22:40, 5 March 2005
Comments User:Conor325
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. I know the argument might be - want to keep your templates simple, be my guest and such a subset is supported. My only concern with supporting generic conditions within the builder is that it delays the release of support for new query and data types.
RDF caching and refresh
Neil pointed out that RDF refresh was implemented last year and it can be called from remote code. However, RDF caching is still an issue. Refresh and caching is a general issue for all "file based" data sources i.e. where they is a load at startup and subsequent queries run off a local cache.
RDF templates and RDF loading
A big shortcoming of rdf templates now is that they seem to load data sources synchronously (Neil pointed out to me that this is just an impression - they actually load asynchronously but so fast that they block the browser anyway). A large file certainly blocks the browser. They seem to load the datasource as part of template parsing which doesn't allow a page to register as a builder listener and so catch when the first build of an element completes. As part of version 2, I think loading shouldn't block the browser (some timer stuff or what?) and there should be an event like "datasourceLoaded" to mark its end.
Problems with RDF query
- can't extract "about"
- can't extract a literal predicate's value directly from a scoped resource