Merge lp://qastaging/~lomov-as/charm-helpers/cloud-foundry-multiple-units-in-relation-context into lp://qastaging/~cf-charmers/charm-helpers/cloud-foundry

The idea here is fine. I'd suggest that this is a different context type as it implies a different relationship to the template is manages however. Any consumer/template needs to be prepared to iterate a list.

Maybe a subclass called RelationListContext which sets multiple units to True and the base class doesn't expose a way to change this directly, set to False in the class. That way we share the implmentation but it is explicit to the template what they will be consuming.

I thought about making distinct class ( something like
RelationUnitListContext ), but this idea didn't suits me because having
list of units with their own properties is something that stands behind
juju relations. In this case I would like to see this functionality inside
RelationContext. What do you think?

On 22 May 2014 04:06, Benjamin Saller <email address hidden> wrote:

> The idea here is fine. I'd suggest that this is a different context type
> as it implies a different relationship to the template is manages however.
> Any consumer/template needs to be prepared to iterate a list.
>
> Maybe a subclass called RelationListContext which sets multiple units to
> True and the base class doesn't expose a way to change this directly, set
> to False in the class. That way we share the implmentation but it is
> explicit to the template what they will be consuming.
>
>
> --
>
> https://code.launchpad.net/~lomov-as/charm-helpers/cloud-foundry-multiple-units-in-relation-context/+merge/220508
> You are the owner of
> lp:~lomov-as/charm-helpers/cloud-foundry-multiple-units-in-relation-context.
>

> I thought about making distinct class ( something like
> RelationUnitListContext ), but this idea didn't suits me because having
> list of units with their own properties is something that stands behind
> juju relations. In this case I would like to see this functionality inside
> RelationContext. What do you think?
>

My agument is the same, that while the List subclass can share the implementation with the parent they present a suitably different interface to the consuming template. Templates written to this type of relation must use iteration over a list and these methods will always return a list of values even if there is only 1. To me this seems sufficently different to warrent some clear indication in the declartive part of template configuration.

>
> On 22 May 2014 04:06, Benjamin Saller <email address hidden> wrote:
>
> > The idea here is fine. I'd suggest that this is a different context type
> > as it implies a different relationship to the template is manages however.
> > Any consumer/template needs to be prepared to iterate a list.
> >
> > Maybe a subclass called RelationListContext which sets multiple units to
> > True and the base class doesn't expose a way to change this directly, set
> > to False in the class. That way we share the implmentation but it is
> > explicit to the template what they will be consuming.
> >
> >
> > --
> >
> > https://code.launchpad.net/~lomov-as/charm-helpers/cloud-foundry-multiple-
> units-in-relation-context/+merge/220508
> > You are the owner of
> > lp:~lomov-as/charm-helpers/cloud-foundry-multiple-units-in-relation-context.
> >