Re: Detecting unbound options

On Thu, May 28, 2009 at 9:29 AM,  <Toman_Vojtech@emc.com> wrote:
> Beautiful.
>
> Just a note about this:
>
>>> Alas, I think that would just trade a great big nested p:try/p:catch
>>> for a great big p:choose...
>>
>> A small win, but a win !
>
> I think that it's not that small win, actually. The problem with
> try/catch is that the catch sub-pipeline is invoked whenever *anything*
> goes wrong, not just when some of the options are unbound. If, for
> instance, the directory-list simply fails to read the contents of the
> directory, the catch will run a second directory-list, which fails, too,
> and so on. Of course, you can check the error code in your catch
> sub-pipeline to detect what really went wrong, but that would be a)
> unreliable, and b) it would make the pipelines even more horrible.
>
> With choose, you don't have this problem.
>

May I also suggest that the choose is more "streaming-proof" than the try/catch

So indeed, that's a significant win

But I, again, voice for the suggestion

> 2) To add an attribute on p:with-option that says
> @bound-like-this-option="$foo" ; if foo is bound then the variable
> will be bound and the value will be the content of the select and will
> not be bound if $foo isn't bound

We could also add for more complex use case the p:is-option-bound() function

Xmlizer

Received on Thursday, 28 May 2009 07:38:17 UTC