bobslee / orbeon-xml-api Goto Github PK

Like control not exists, when calling one.
Implement ControlNotFound Exception

To improve the API flexibility even better, subclassed (overrides) of Controls should be possible.
This will replace the Control Decoders implementation, mentoined in issue #5.

• Constructor arguments (kwargs: controls)
• Runner merge()

Refactor and improve code which merges a Builder (with updates) into a Runner (older version).
This currently is handled by class RunnerCopyBuilderMerge, which calls the Runner its merge() method. This Runner merge() method needs to be moved to the Merge class, and programmed in a stable and object-oriented way!

Currently the decode() function, for select controls, returns a (Python) list - with only the stored values.

Should be changed as following:

EXAMPLE:

Builder XML:

<dropdown>
    <label>Dropdown Menu</label>
    <hint>Standard dropdown</hint>
    <item>
        <label>Cat</label>
        <value>cat</value>
    </item>
    <item>
        <label>Dog</label>
        <value>dog</value>
    </item>
</dropdown>

Runner XML:

<dropdown>
    cat dog
</dropdown>

Decode shall return:

{"cat": "Cat", "dog": "Dog"}

Maybe usage of xmltodict causes some performance / slowness.
xmltodict is used in Control (class) its set_resource_dict() function.

Benchmark and maybe switch to alternative function, which is not complete yet and should be proven:

• file: utils.py
• function: etree_to_dict

Implement and Unit Test for some Typed Controls (US address)

The library is development on Python 2.7

Python 3.3 (and later) fails with:

• Import problems
• String/Bytes coding errors

Since the PR #15, the image and annotation elements won't be merged yet.
See for initial discussion/info the PR #15

The code which skips those elements is in merge() function of the runner.py, as:
if tag not in ['annotation', 'image']:

This still needs to be implemented (with tests) and reviewed.
Ideally to develop in conjunction with the refactoring of the merge, reported in issue #12

The problem could arise that the Orbeon XML comes from a different storage implementation.
This is possible via the so-called "Orbeon Persistence Layer" server configuration.

In such case, the XML could potentially be parsed - with controls e.g. image(s) - and stored in a different way (filesystem, Amazon S3, Dropbox etc.)

Therefor we need pluggable and specific Serializer objects per Control (StringControl, ImageControl). The Control its "decode / encode" functions should use that Serializer object, set via the Builder - Otherwise just run the default one (by Control itself).

These "Serializer" objects shall be given to the Builder constructor on the kwargs.

Likewise code should be something:

Builder (orbeon_xml_api):

from orbeon_xml_api import Builder
from my_serializers import MyS3ImageAttachmentSerializer

s3_image_attachment_serializer = MyS3ImageAtachmentSerializer()

builder = Builder( 
  xml, 'en', 
  image_serializer=s3_image_attachment_serializer
)

ImageControl (orbeon_xml_api):

Maybe we should put this in the base Control class.

class ImageAttachmentControl(Control):
  def decode(self, value):
    if self.builder.image_attachment_serializer is not None:
      return self.builder.image_attachment_serializer.decode(value)
    else:
      return value # The default decode implementation

MyS3ImageAttachmentSerializer (custom):

class MyS3ImageAttachmentSerializer:
  def __init__(self):
    self.s3_account = 'abc'
    self.s3_access_token = 'abc123'
    self.s3_bucket = 'xyz'
    self.authenticate()
    
  def decode(self, value):
    # Do something very special here
    data = self._get_s3_binary()
    ...
    return data_decoded

  def _get_s3_binary():
    # The actual implementation to get the image from Amazon S3