[Sorien]

maybe using some kind of namespace would be more suitable .

Code:

<include file="MyControls.xml" param:posx="225" param:posy="150" param:color="white">MyControl1</include>

Code:

<include name="MyControl" param:posx="120" param:posy="120" param:border="5" param:background="foo.png">
  <control ...>
    <posx>$PARAM[posx]</posx>
    <posy>$PARAM[posy]</posy>
    ...
    <!-- nested include call -->
    <include param:color="$PARAM[color]">MyControl2</include>
    ...
  </control>
  ...
</include>

ist a bit weird (maybe just for me) to use capitalized attributes

[rahotep]

I was initially considering this and am not against it. It would be interesting to hear what others think.

Capitalized attributes are also a kind of a 'namespace', but implicit, and with minimum "overhead". Perhaps a less verbose form 'p:' instead of 'param:' could be used?

Anyway, good news is that include parameters feature has been implemented and is waiting to be included.

[Sorien]

but as someone said capitalized attributes are less readable, maybe namespace should be mapped directly to params for even better flexibility and low overhead

Code:

<include name="MyControl" a:posx="120" a:posy="120" a:border="5" b:background="foo.png" b:posx="50" b:posy="70">
  <control ...>
    <posx>$A[posx]</posx>
    <posy>$A[posy]</posy>
    ...
    <!-- nested include call -->
    <include param:color="$A[color]">MyControl2</include>
    ...
  </control>
  <control ...>
    <posx>$B[posx]</posx>
    <posy>$B[posy]</posy>
    ...
    <!-- nested include call -->
    <include param:color="$A[color]">MyControl2</include>
    ...
  </control>
  ...
</include>

[rahotep]

I may be wrong, but I think the comment about readability was directed towards $PARAM[Name] references themselves and entire 'include with parameters' feature.

Anyway, one issue with your latest approach could be possible overlapping with built-in dollar references (both current - $VAR, $INFO, $ESCINFO, $LOCALIZE, $ADDON, $NUMBER etc. - and future ones), which we wanted to avoid in the first place. Introducing a priority would probably be even messier.

[null_pointer]

the namespace approach looks easier to read, just my 2 cents worth.

Code:

<include name="MyControl" param:posx="120">
  <control>
    <posx>$PARAM[posx]</posx>
  </control>
</include>

[rahotep]

OK, I've just changed the parameter syntax from capitalized attributes (PosX="120") to a namespace prefix (param:posx="120").

[`Black]

I'm working with this now since a few days and it's awesome. Just one thing which could be optimized:

PHP Code:

#Defining some vars with a default posx value
<include name="MyControlVars" param:posx="120">
    <posx>$PARAM[posx]</posx>
</include>

#Using the vars in a concrete control
<include name="MyControl">
  <control type="button">
    <include param:posx="$PARAM[posx]">MyControlVars</include>
    <onclick>SomeAction</onclick>
  </control>
</include>

#Using MyControl without posx as parameter
<include>MyControl</include> 


Now <include>MyControl</include> is defined without a parameter but it doesn't seem to use the default value from MyControlVars. So at the moment if you have some common vars, you need to define the default values in every include where you use them.

[rahotep]

Yes, the default value is not used because you're explicitly overriding it with something that resolves to an empty string. This is by the current design. Since posx parameter has not been passed to MyControl nor there is a default value defined for it in MyControl, "$PARAM[posx]" gets expanded to "" and behaves as if you'd explicitly written <include param:posx="">MyControlVars</include>, which does override the default value in MyControlVars.

I think we could implement what you proposed by adding a special case for passing parameter values of the form "$PARAM[name]" to the nested include (with no extra characters around), where 'name' refers to an undefined parameter, so that the default value from the nested include is used instead.

Thanks for the suggestion.

[rahotep]

After giving it some more thought, I edited my previous post to make it more clear and deleted the unnecessary follow-up.

[bkury]

I really like this idea and it would be even nicer if it would also support $INFO as a parameter e.g.

Code:

<include name="MyPosition" param:posx="$INFO[Skin.String(MyPosX)]" param:posy="$INFO[Skin.String(MyPosY)]">
    <posx>$PARAM[posx]</posx>
    <posy>$PARAM[posy]</posy>
</include>

[`Black]

That's already working.

[bkury]

Ah I see, must have missed that part ... thank you!

[null_pointer]

in which version will this be available in?

[`Black]

Helix

[null_pointer]

Do we have a wiki page or other documentation on how this new feature works?