Alexander,
Was talking with Iain MacNeil and he explained that in order to support the ability for the PDS to login to an existing account at a website or for it to automatically create a new account for the user at a website, it needs to present forms to the user. Since the set of attributes required in each case varies by website these need to be dynamic forms. Since the view-builder vocabulary already allows us to describe the attributes, etc. required to create a dynamic form, we thought we could re-use a view-builder structure to describe these (comparatively simple) login and registration forms.
A login form, for example, might require an email address and a password. So we would create a simple three node view-builder structure consisting of a parent Group node and two child Slot nodes for email and password. For the login form the slots would usually have view-builder:attribute values of proxy:userid and proxy:password respectively. In most websites these days the userid is an email address so the template context contain should "override" the default value of skos:prefLabel of proxy:userid by including the following statement so that the user sees a prompt for "Email" not for "Username":
proxy:userid skos:prefLabel "Email"@en .
In the template vocab [2] we already have two kinds of view-builder structures. One for the main context editor form/page and another for the "settings" page. These are attributes, template:viewRoot and template:settingsViewRoot, respectively of a template:ContextPrototype. So I added two new attributes, app-data:login and app-data:registration to [1].
Paul
|