Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify property() function #57

Closed
MartijnR opened this issue Dec 22, 2016 · 6 comments
Closed

clarify property() function #57

MartijnR opened this issue Dec 22, 2016 · 6 comments

Comments

@MartijnR
Copy link
Contributor

MartijnR commented Dec 22, 2016

To be done in a way that we can present this as an XPath function (regardless of how exactly it's implemented in JavaRosa or Enketo (it is not)). This is not easy imo.

It would be easy if/once we replace preload items with an external session instance like CommCare because in that case property(PROP) is just a shortcut for obtaining instance('session')/PROP or something similar.

@MartijnR
Copy link
Contributor Author

@lognaturel writes:

Sounds like it might be a candidate for deprecation?

Yes, that would be good. And not document it at all perhaps.

@lognaturel
Copy link
Member

I think removing it from the spec for now is fine. It's ok to have things in JavaRosa that aren't part of the spec. Ideally in the near future JR will get its own documentation that amends this spec with any relevant implementation details and extra features.

When you suggest replacing "preload items with an external session instance like CommCare ", you mean having an external XML document that holds session information and which is retrieved as an external instance as per #50, is that correct?

@MartijnR
Copy link
Contributor Author

What are the exact property() parameter values that JavaRosa supports?

@lognaturel
Copy link
Member

Oops, totally missed this. Here is the relevant code, I believe. It accepts a single string parameter which represents the name of the desired property managed by the PropertyManager. I really don't think it belongs in this spec.

And to confirm, you are talking about #50 as a possible way to hold session information, right?

@MartijnR
Copy link
Contributor Author

Thanks. I see these:

  • "DeviceID"
  • "cur_locale"
  • "logenabled", returning either "Enabled" or "Disabled"
  • "jr_openrosa_api"

I really don't think it belongs in this spec.

Yes, I think I agree. I did coincidentally see a query from Esri about this function and I've asked them for their use case for it (that is not equally well met by preload items). Maybe there is one.

And to confirm, you are talking about #50 as a possible way to hold session information, right?

Yes

@MartijnR MartijnR mentioned this issue Jun 25, 2018
@MartijnR
Copy link
Contributor Author

To be removed as part of #189 fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants