René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add dynamic Widget/Component creation","articleBody":"### What’s the problem?\n\nThe current UI definition paradigm requires us to know exactly which UI elements are needed before a `Page` creation. This is often **_not**_ the case for larger apps. Although data binding handles dynamic UI updating nicely for tabular data and other small items, it is not the right solution for large dynamically generated UI compositions.\n### What do we have now?\n\nThe existing capabilities of {N} **_do**_ allow for us to specify isolated groupings of UI components (_or widgets_) referenced into the XML of the parent `Page`.\n\n```\n// Define our Widget in file \"xml-declaration/widget1\".\n\u003cStackLayout id=\"stackLayout\" \u003e\n    \u003cLabel id=\"label1\" text=\"Label1\" /\u003e\n    \u003cButton id=\"button1\" text=\"Button1\" /\u003e \n\u003c/StackLayout\u003e\n```\n\n```\n// Embed our custom Widget into our Page.\n\u003cPage xmlns:widgets=\"xml-declaration/widget1\"\u003e\n     \u003cwidgets:Widget1 /\u003e\n\u003c/Page\u003e\n```\n### What do we need?\n\nWe need a dynamic widget builder, providing full control over **_when**_ a custom widget gets created.\n\nIdeally we’d expect its usage and API to be simple, perhaps something like:\n_(using the widget XML declared above)_\n\n```\nvar widget1 = viewBuilder.build({ name: ‘xml-declaration/widget1’ });\nsomeView.addChild(widget1);\n```\n\nCurrently we **_do**_ have the ability to dynamically create `Page` views/controllers from an XML file.\nThis is done via the `Frame` class using the static method `resolvePageFromEntry()`:\n\n```\nvar widget1 = frameCommon.resolvePageFromEntry({ moduleName: 'xml-declaration/widget1' });\nsomeView.addChild(widget1);\n```\n\nwhere the XML would be declared something like:\n\n```\n\u003cPage xmlns=\"http://www.nativescript.org/tns.xsd\" loaded=\"pageLoaded\" \u003e\n    \u003cStackLayout id=\"stackLayout\" \u003e\n        \u003cLabel id=\"label1\" text=\"Label1\" /\u003e\n        \u003cButton id=\"button1\" text=\"Button1\" /\u003e \n    \u003c/StackLayout\u003e\n\u003c/Page\u003e\n```\n\nNote that the widget must be wrapped in a `Page` element or this will **_not work**_!\nBut making every widget a `Page` would incur excessive overhead, and quite frankly you could create some nonsensical compositions, like a `Page` with a `StackedLayout` parent.\n\nThis is not the right solution.\n### Technical considerations\n\nThe main _benefit_ of having a `Page` as our root in a widget is contains the internal method `addCssFile()` which applies styling during the `resolvePageFromEntry()` call, where the css file name is dynamically determined from the target module name.\n\nThe main _drawback_ of having a `Page` root is that it knows about app Navigation, which a small widget absolutely should **_not**_. This abstraction is wrong for our widgets.\n\nCurrently the visible UI elements have different direct parent classes: `TextBase`, `Layout`, `ContentView`, and `View`. So introducing a generic builder which handles the automatic styling (like the `Page` does now) would mean they would all have to have a common base having the `addCssFile()` styling capability. Perhaps this could be retrofitted up into the shared-common base class `View`? Or perhaps some other class abstraction in between would be more correct.\n\nThen using the same builder call proposed before, we would be handed the correct (and stylized) widget, regardless of the outer container type specified in the XML:\n\n```\nvar widget1 = viewBuilder.build({ name: ‘xml-declaration/widget1’ });\nsomeView.addChild(widget1);\n```\n","author":{"url":"https://github.com/patrickseda","@type":"Person","name":"patrickseda"},"datePublished":"2015-07-03T21:46:29.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/389/NativeScript/issues/389"}