Hi Steve,
Thanks for your reply.
LinkedHashMap serves for those cases, I would think ;). Is this bug-worthy
enough ie would raising a JIRA issue be fruitful here?
> Turning the question on it's head, why would you need the order of
informal parameters anyway? Bearing in mind XML doesn't enforce
ordering on attributes.
I'm not sure what you mean. The order is quite explicit in the XML document
itself. In fact, any XML parser will return nodes in the order they are in the
document and for good reason. You might as well ask why in the following xhtml
document I would expect the "Content 1" to show after "Content 2" (absent any
layout rules):
<body>
<h2>Headline</h2>
<p>Content 1</p>
<p>Content 2</p>
Element order is just an integral information for any structured document.
That's why this to me is equal to why I would expect the parameter names to
match the block's appearance in the template:
<t:codegen.client.UITabs tabs="Block One, Block Two, Three">
<p:block1>
Content of block 1
</p:block1>
<p:block2>
Content block 2
</p:block2>
<p:block3>
Content Block 3
</p:block3>
<p:all>
Content all
</p:all>
</t:codegen.client.UITabs>
What I want to do here is display JQuery-UI tabs with the content provided by
blocks and the labels provided by the "tabs" parameter (optional, obvs). I
explicitly don't want to make the user of the component (me ;) repeat himself
as to the order of the elements because that's just redundant, error-prone
boilerplate when the document already contains this info. Btw, it would be
awesome if blocks supported custom attributes so that I could write
<p:block1 label="Block One"/> ...
And generally, t5 has such a great focus on developer productivity that the
areas that don't seem to support this very well stand out over proportion.
Maybe as a suggestion to the committers, I think there are many worthwhile
additions to be made to some of the APIs, especially beanmodel
(getPropertyIds() comes to mind) and a lot of it could be remodeled to support
"principle of least surprise" (clearly broken by
ComponentResources.getInformalParameterNames()) and "exception by exception"
(the principle I just made up that dictates that exception shall only be thrown
if a callee has no sensible, default way to resolve an internal conflict. For
example, why in the world would beanmodel throw an exception when adding a
property that already exists?).
In my own APIs I use a (do|find|get|make)XYZOr(Null|Throw) convention that
works out really well because the caller can decide if it's truly an
exceptional circumstance or not. Also, I always include a check method if I am
going to throw or return null -> hasXYZ()? getXYZ().toString() : "no xyz".
Best Regards,
Wulf
-----Original Message-----
From: Steve Eynon [mailto:[email protected]]
Sent: Samstag, 22. Oktober 2011 06:15
To: Tapestry users
Subject: Re: ComponentResources.getInformalParameterNames()
Looking at the code, yes, the names are indeed sorted. But even if
they weren't I doubt they'd be returned in the template defined order
as internally they are stored as set of bindings and transformed into
a named map - and both structures are notorious for losing a defined
order.
Turning the question on it's head, why would you need the order of
informal parameters anyway? Bearing in mind XML doesn't enforce
ordering on attributes.
Steve.
On 22 October 2011 07:00, Wechsung, Wulf <[email protected]> wrote:
> Hi all,
>
> I just noticed the API Doc for ComponentResources.getInformalParameterNames()
> says that it returns the parameter names in alphabetical order. I'm stunned,
> to be honest because I would not have expected this at all and I really need
> them to be in the order as defined in the template ... is there any
> particular reason the framework decides to destroy otherwise inaccessible (?)
> information by doing a sort ( which would be like a single line if someone
> really needed it that way ..) before returning this?
>
> Thanks and kind Regards,
> Wulf
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
