Auto Wizard loading URLs and Breaking Wizard

[StephenOwens-dcat]

I have an instance of alpaca in which some of my data elements are URI based. Apparently alpaca is attempting to load these URI's and throwing errors when they fail to load. The data fields are supposed to be URI format, but not necessarily live links. The wizard next button will not work as a consequence of these failures and it is impossible to fix the issues via the Alpaca generated wizard because the fields do not appear on the first step of the wizard.

[StephenOwens-dcat]

I have figured out that Alpaca for whatever reason attempts to load fields containing URL's even when the fields are marked as type "text", if the URL's are not valid then Alpaca throws up obnoxious errors stating that it could not load the urls. It should not be trying to load these urls at all this is extremely unwanted behavior and renders the whole thing useless for any sort of application where the text field content may contain data that looks like a URL.

[uzquiano]

One solution and perhaps an improved design would be to introduce new configuration properties - dataSource, schemaSource and optionsSource. These would let you specify that the data, schema and/or options should be loaded from an external source.

The data, schema and options properties would then be reserved for direct data only.

The *source properties could take a URI or they could take a function that passes in a callback to receive the loaded data.

Do you think this design would improve Alpaca? Would it help your use case?

[ryangadams]

Hi, I have this issue too. I'm trying to understand the rationale behind fetching that data, could you explain it?

[uzquiano]

There was a checkin over the weekend that addressed this in the master branch.

The "schema", "options", "data" and "view" properties are simply data properties. If you supply values that look like URIs, they are no longer assumed to be data sources and loaded.

Instead, Alpaca now supports four new properties - "schemaSource", "optionsSource", "dataSource" and "viewSource" that let you supply URIs, functions or other configuration for your Connector. The default connector assumes URIs and loads from remote sources.

The rationale behind the support of dynamic loading is so that you can quickly build forms that utilize schema, field configuration, layouts and more from a back-end system. In our case, we utilize Cloud CMS. JSON Schema also supports some of this mechanism with it's notion of $ref fields and hyper-schemas.

While the attempt to use URI detection in the core "schema", "options", "data" and "view" properties was clever, I don't think it was ever sophisticated enough to be worthwhile. It just got in the way and I think it created an obstruction for folks who simply wanted to represent values.

This will be included in the next release which I hope will be tomorrow morning. That said, for now, you can try building from master. Could you give it a shot and let us know how it works?

Cheers!

[uzquiano]

This has been implemented in 1.1.0 which is now released. As such, Alpaca now allows for URI values without any problem. If you run into any issues, feel free to re-open or submit another issue.

[PratikshaAtDure]

Any one working on dependencies in alpaca wizard? I'm facing a default issue can any one help me out? Suppose a case where parent is a select menu with yes/no ; on selecting 'YES' child text box is shown which is required fields after touching the fields (error shown :This is a required field) npw user just updates the parent option to 'NO' keeping the previous page validation as it is. In this case next button does not allow to navigate to next step.

Thanks in advance,
Pratiksha