dynamic select lists

[Benno Blumenthal]

I have just started using axel and it is going pretty well, thank you very much, and now I am trying to take it a bit further.

I would like to do select with dynamically-determined lists, i.e. read part of the document to determine the options.

As a first cut,  I wrote a plugin  selectJQ  which uses jQuery selectors (css selectors so far) to make a list of options, in my particular case

<xt:attribute types="selectJQ" param='placeholder=clear' name="rdf:about" values=".labelBox.Activity .axel-core-editable" i18n=".editBox.Activity .title .axel-core-editable"></xt:attribute>

I already had the classes defined in the edit form for css formating, so it was convenient.  One could argue that the .axel-core-editable could be added by the code, or not.

In any case, inside the code it does a $(searchstring)  and then loops through, pulling all the textContent for the matching nodes.

This works perfectly well for values by itsself, but not as well for i18n -- the menu is fine, but the initial values cannot be translated with i18n because the list is not available until the edit node tree is finished.

So,

1. is this fixable?
2. is this worth fixing?

alternatively, if there were a copy of the current xml document accessible, could search through that instead.  A current xml document might also allow xsl stylesheet chains -- I think the javascript xsl implementation updates the output when the input is changed, so edits in axel could automatically update xsl stylesheet output, which could be placed inside an element in the document.

    

[Stephane]

Hi,

Le 24 oct. 2013 à 18:31, Benno Blumenthal a écrit :
> I have just started using axel and it is going pretty well, thank you very much, and now I am trying to take it a bit further.

Excellent !

> I would like to do select with dynamically-determined lists, i.e. read part of the document to determine the options.
>
> As a first cut, I wrote a plugin selectJQ which uses jQuery selectors (css selectors so far) to make a list of options, in my particular case
> <xt:attribute types="selectJQ" param='placeholder=clear' name="rdf:about" values=".labelBox.Activity .axel-core-editable" i18n=".editBox.Activity .title .axel-core-editable"></xt:attribute>
> I already had the classes defined in the edit form for css formating, so it was convenient. One could argue that the .axel-core-editable could be added by the code, or not.
> In any case, inside the code it does a $(searchstring) and then loops through, pulling all the textContent for the matching nodes.
>
> This works perfectly well for values by itsself, but not as well for i18n -- the menu is fine, but the initial values cannot be translated with i18n because the list is not available until the edit node tree is finished.

Not sure I get it all, let me ask a few questions :

- do you mean that you want to populate your "selectJQ" list of options plugin with user edited content ?
- does this user edited content is also edited with an AXEL plugin ('text' or whatever) ?

If this is the case, when do you want to update your "SelectJQ" list selector ? on which event ? If the content you want to extract is statically available inside the document template (or host document) that sounds possible waiting for the 'axel-editor-ready' event as mentioned below. However I am not sure why you would use that method if this is statically available, since then you can replicate it directly inside the values and i18n attributes because you know the content in advance ? (unless you want to write a generic template document that initializes its list of options from it's host page ?).

The thing that puzzle me is why that would work for the .labelBox content and not for the .editBox content ? Did you test your selectors manually (Firebug for instance...)

Note that for values and i18n attributes, the space is a token separator, so think to use "\ " if you want to include a space in a token. Note that values and i18n expect to have the same number of tokens.

I suggest you send me directly your template file (or you create a gist / git / jsfiddle with it to share it).

For release 1.3.3, which is still under work into the "devel" branch, I am integrating some life cycle events into AXEL, maybe this could help, see the description it :

https://github.com/ssire/axel/wiki/AXEL-Life-Cycle-Events

For instance once the editor has been transformed AXEL triggers an 'axel-editor-ready' event on the document (and on the DOM node that holds the editor), or once some data has been loaded into the editor it triggers an 'axel-content-ready', maybe your plugin can subscribe to it in its onAwake function to finish installation later on with code like :

$(document).bind('axel-editor-ready', $.proxy(this, 'editorReadyCallback'));

Note that this is a way to avoid the current limitation that inside the onInit and onAwake functions of the plugin code, if this is invoke to instantiate an xt:component included with an xt:use, the component has not yet been inserted into the tree at the time of invocation.

> So,
>
> • is this fixable?
> • is this worth fixing?

I need more info to answer

> alternatively, if there were a copy of the current xml document accessible, could search through that instead. A current xml document might also allow xsl stylesheet chains -- I think the javascript xsl implementation updates the output when the input is changed, so edits in axel could automatically update xsl stylesheet output, which could be placed inside an element in the document.

Do you have a specific application in mind ? Live table of content generation ?

At the difference of XForms, AXEL does not maintain a copy of the current XML instance document somewhere into memory, instead it generates this document on demand when you serialize the editor's content with the $axel(...).xml() method. See https://github.com/ssire/axel/wiki/Wrapped-set. This is a Javascript API inspired by jQuery wrapped set to expose the "shadow" XML tree AXEL is editing behind the scene, but which is spread as annotations of the editor's DOM.

So practically (as soon as 1.3.3 is released) you can listen to some life cycle events (such axel-update, axel-add, axel-remove), call xml() serialization method on whole or parts of your editor's tree, and then feed this to your XSLT transformation. I would be very interested to hear reports of using this method with SAXON CE to create multiple views editors. I am developing this actually for the purpose of adding simple computed values into document editors (*), but this can also be used to generate extra document parts while editing. The limitation is that content generated this way is just illustrative, that would require more code to inject it back into the document XML output model so that it is serialized too when saving the document content (although that would be still possible).

Stéphane S.
---

(*) work in progress example for computed values : https://github.com/ssire/axel-forms/blob/devel/templates/samples/Computed.xhtml

[Benno Blumenthal]

| The thing that puzzle me is why that would work for the .labelBox content and not for the .editBox content ? Did you test your selectors manually (Firebug for instance...)

Sorry, I should have been more explicit, since you cannot see my document.  The reason it works for the labelBox content, is because no translation (using i18n) is required on initial display -- the value is already correct in the xml document, so axel simply copies and displays it.  When it needs to show a menu, it does the query and has a correct list.   i18n translation requires the list to display and to create the menu, and because my list is composed of axel edit elements that are farther down in the document that the select element is, axel simply has not created them when the select element is put in the HTML DOM and the display is created.  So it puts in the value that should have been translated with the i18n list.   If my jquery returned elements that were defined before the select element is rendered into HTML, then it would work.  Maybe. 

As it is, it is not bad -- the select element  works perfectly, it is just that the initial display shows what was supposed to be hidden instead of the i18n labels.

The reason I am doing this is that I am trying to cross-reference within the document  -- I have a list of "Activities", which I want to pick from, because each "Objective" is the result of one of the "Activities".   Another example might be section references within a paper -- see section N "section title".

In any case, it sounds like the event subscription could work -- I am using the devel branch anyway, because of the placeholder=clear fix you made for me.

Benno

--
Dr. M. Benno Blumenthal          be...@iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000   (845) 680-4450