Alexei,
I have narrowed it down a bit further. The writable computed observable
that is returned by getEditedNode correctly reads the values retrieved by
the method getEditedBranch(), but then, if the concept is in Arabic, it
does not pass it to the "write" callback, despite the variable 'ret' (which
is returned by the 'read' method in the observable) correctly storing the
value of the Arabic concept. 'ret', in this case, is essentially not passed
to the 'write' callback. However, if I add a new branch when the platform
language is Arabic, save the form and then edit it, all works fine: 'read'
passes ret to the object 'value' of the 'write' callback and no problem
arises. I don't understand why the problem is occurring, but I am certain
that it happens at the juncture between read and write in getEditedNode.
Andrea
On Monday, July 4, 2016 at 7:38:19 PM UTC+1, zerbini...@gmail.com wrote:
>
> Hi Alexei,
>
> I have been debugging branch-list.js, and particularly the method
> getEditedNode. It would appear that the problem lies with the viewModel not
> correctly picking up the labels when the language selected is not the one
> with which the branches were originally saved.
> The form data is correctly passed by forms.py with labels in the selected
> language. So, a console log this.data[this.dataKey].branch_lists of on the
> nodes SITE_FUNCTION_CERTAINTY_TYPE and SITE_FUNCTION_CERTAINTY returns this:
>
>
> {"nodes":[{"value":"d30fef92-728b-46f6-a4c5-b42e552a0326","label":"عالي","child_entities":[],"entitytypeid":"SITE_FUNCTION_CERTAINTY_TYPE.E55","parentid":"679aa456-943d-4b2d-8c25-947c1f635307","entityid":"86e23739-93f0-40d4-8793-d1dc5043a4f9","property":"P2","businesstablename":"domains"},{"value":"92c37d46-dc23-4869-b868-b978d9f972aa","label":"ديني","child_entities":[],"entitytypeid":"SITE_FUNCTION_TYPE.E55","parentid":"6b8526b0-62ec-4860-9bee-ddf6830d3ff8","entityid":"679aa456-943d-4b2d-8c25-947c1f635307","property":"P2","businesstablename":"domains"}]}
>
>
> This branch had been added, originally, in English, but the labels passed
> by the "load" method have been altered to adhere to the selected language
> (Arabic). However, when debugging getEditedNode, this function correctly
> reads the values of the two selected concepts
> (d30fef92-728b-46f6-a4c5-b42e552a0326 and
> 92c37d46-dc23-4869-b868-b978d9f972aa) BUT, for whatever reason, passes an
> empty object to the write method within getEditedNode.
>
> Can you think of any reason why this might be happening?
>
> Andrea
>
> On Tuesday, June 28, 2016 at 12:20:21 AM UTC+1, Alexei Peters wrote:
>>
>> Hi Andrea,
>> Have you confirmed that you're getting all the data in all languages when
>> a form loads, but that somehow the client side code is filtering based on
>> language?
>> The "load" method in forms.py would potentially allow a user to only load
>> data with a specific language code, you're code isn't doing that is it?
>> Cheers,
>> Alexei
>>
>>
>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>
>> On Fri, Jun 17, 2016 at 8:26 AM, wrote:
>>
>>> Dear Alexei,
>>>
>>> I have got it to work:
>>> https://github.com/azerbini/eamena2/blob/app/models/forms.py
>>>
>>> I was modifying the wrong method, in entity.py instead of looking into
>>> app/models/forms and changing that get_nodes. My bad.
>>>
>>> Now, the problem is that, for whatever reason (and unrelated to my
>>> changes to get_nodes()), the JS libraries only allow me to edit branches in
>>> the language of original insertion. So, when the selected language is
>>> English, I am able to pull up and edit in a form all of the branches that
>>> were initially saved in the DB in English. Viceversa, when the language
>>> selected is Arabic, I can only edit branches (or entities - call them as
>>> you may) that were saved into the DB in Arabic. Any idea as to why the JS
>>> does this?
>>>
>>> Thank you - getting there step by step!
>>>
>>> Andrea
>>>
>>> On Thursday, June 16, 2016 at 7:43:59 PM UTC+1, Alexei Peters wrote:
Hi Andrea,
I'll have to look into this.
Cheers,
Alexei
Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
On Wed, Jun 15, 2016 at 10:43 AM, wrote:
> A small update. I have been able to bypass the indexing problem by
> commenting off lines 228-30 in app/search/search.py and replacing the
> custom exception with a standard return False.
> I subsequently modified get_nodes() as visible here:
> https://github.com/azerbini/eamena2/blob/app/models/entity.py
>
> Now, the labels returned by get_nodes are in the correct language, and
> yet they keep being visualised in the templates in the language of
> original
> insertion (see screenshot attached). Once again, what do I need to modify
> in order to tweak the resource graph which is passed as an observable
