Intelligent Parallel Parsing (P^2)

Ok, I guess you can do it to old way. I guess that will be much more flexible.

No, I don’t think we’re trying to get away from that -- I think we have to allow both default cacheability via the Widget/Element definition as well as overriding it with an instance-specific cacheable flag -- otherwise, if I want to control the cacheability on an instance by instance basis, I would only be able to by nesting a noncacheable snippet in the tag or duplicating the Widget/Element with a different default cacheable setting.

As to Element vs. Widget, now I’m really confused. Widgets previously were things like you described below, but in the new definition, if I am following, they still are these things (like DataGrid)? I thought we decided that Widgets was now the terminology for all of the various elements, from Snippets to Chunks to Plugins, and that some new terminology would be applied to the former widgets (which is why I prefer Elements to avoid confusion with legacy users already having trouble grasping all the various terminology and concepts). For instance, in Tattoo, every Element type (Elements [aka Templates/Chunks], ScriptElements [aka Snippets], PluginElements [aka Plugins], ModuleElements [aka Modules], etc.) would allow an InputClass, InputParameters, Transform/OutputClass, and Transform/OutputParameters.

So are we talking about old-style Display Widgets or Widgets as Snippets/Chunks/Plugins/etc. are to be considered in the future?

Quote from: OpenGeek at Jan 18, 2006, 02:50 PM

So are we talking about old-style Display Widgets or Widgets as Snippets/Chunks/Plugins/etc. are to be considered in the future?

Widgets IMO will become a merge of Snippet/Plugins and the now Display Widgets. This means that you’ll be able to create 1) widgets that can be connected to a Content Field, 2) Widgets that can be inserted inside a page, 3) Widgets that can be made to listen to system/custom events.

Chunks will be merged into Templates

Maybe the things on a page are elements, and the things that listen or transform are widgets.

Quote from: rthrash at Jan 18, 2006, 03:25 PM

Maybe the things on a page are elements, and the things that listen or transform are widgets.

I for one like Jason’s Element suggestion but there are somethings that sounds better with widget than they do with Elements and visa versa.

Condsider the following:

List of users
[[DataGrid?source=`[[DataConnector?query=`SELECT * FROM users` &format=`xml`]]` &format=`xml`]]

Usage Info
[[PropertyBag?name=`MyData` &content=`[[ReadFile?path=`assets/files/data.xml`]]` ]]

[[DataList?source=`[[PropertyBag?name=`MyData`]]` ]]

The confusion with widgets could be cleared up a bit if we were to actially implement every current widget (TV output things) as actual plugins (what will be widgets). Then they can be widgets in the old sense and the new sense.

And since someone brought up the whole naming thing again so I don’t have to take the flack for it...

I still like components. To me, widgets are like controls, elements refer to XML/Javascript and components are building blocks for an application framework. But that’s just me, and really any of the three would be fine with me as long as we don’t name them chunks or modbots or something.

Quote from: aNoble at Jan 18, 2006, 03:54 PM

I still like components. To me, widgets are like controls, elements refer to XML/Javascript and components are building blocks for an application framework. But that’s just me, and really any of the three would be fine with me as long as we don’t name them chunks or modbots or something.

Back in the MS world we refer to them as Controls. Why controls? Because they either transform or control some other component or device inside the system

For example:
Button control
Timer control
Grid control
Ticker control
PropertyBag control
SMFConnector control
MSIEPNG control
etc

Either way is fine with me. So what’s it going to be widgets, controls, elements, components? I’m nore for either Components or Widgets. Just trying to find a term that unique describes all the above.

Raymond, I think that’s reason enough NOT to use the word "controls"!!! lol

Quote from: rthrash at Jan 18, 2006, 04:42 PM

Raymond, I think that’s reason enough NOT to use the word "controls"!!! lol 

You meant all the more reason to use it

Ok,

I think I might have found a solution caching issue by adding an intelliCache option. This will allow the parser to turn on or off it’s ability to not cache top-level widgets if it contains a nested non-cacheable widget. IntelliCache is turned off by default.