I would file a JIRA. If nothing else maybe it will get the thought process started.
On Oct 22, 2011, at 1:38 PM, Wechsung, Wulf wrote: > Hi Steve, > >> No parser (that I'm aware of) actively enforces attributes to be returned in >> a particular order. > > Besides the issue of what the spec really means by "not significant" (I > strongly suspect it means for validity only), I really don't understand > what's behind that statement. I mean, every XML parser simply parses text. > Text always and forever until the heat death of the universe will have a > beginning and an end and every character will have a distinct position that > is either more or less than that of any other character. There is no need to > explicitly enforce anything. If the parser proceeds front to back and > refrains from imposing its own order, the document order will be preserved > without fail 100% of the time. Like I said in my other email, in this regard > I think the XML spec (or the parser makers interpretation) is broken. > > /rant out :) > > Best Regards, > Wulf > > > > -----Original Message----- > From: Steve Eynon [mailto:[email protected]] > Sent: Samstag, 22. Oktober 2011 15:33 > To: Tapestry users > Subject: Re: ComponentResources.getInformalParameterNames() > > Hiya, > >> Bearing in mind XML doesn't enforce ordering on attributes. > > I was merely quoting the W3C XML recommendation which states: > > http://www.w3.org/TR/REC-xml/#sec-starttags > "The order of attribute specifications in a start-tag or empty-element > tag is not significant." > > So any XML parser that returns attributes in their specified order, > just "happens" to do so. No parser (that I'm aware of) actively > enforces attributes to be returned in a particular order. Therefore > for T5 to be 100% certain that attributes are returned in their > specified order, the T5 crew may have their write their own! Eeek! > > Unfortunately you've hit upon an exceptional use case where by > <p:parameter/> blocks (whose order is maintained) are linked to > attributes (whose order is not). > > I'm thinking you may just have to lump it in this case. :( > > By the way, I love your (do|find|get|make)XYZOr(Null|Throw) convention > - the explicit OrNull / OrThrow should end countless years of debate! > > Steve. > > > On 22 October 2011 20:59, Wechsung, Wulf <[email protected]> wrote: >> Hi Robert, >> >> thanks for your response! >> >> I see. I understand that the attribute order (even element order ...) in the >> document is supposed to be insignificant but does that really mean that the >> information about the attribute order should be actively discarded ie that >> code that does processing on any kind of XML *must* never take attribute >> order into account? To me, that's a completely counter-intuitive approach. >> Apparently, also one that a significant amount of XML-based and related >> technologies do not follow. For browsers document order is clearly not >> "insignificant" and neither is it for anything based on xpath (for example, >> what is use could //root/element[0] possibly have if it doesn't refer to the >> document order?). >> >> Alas, I shall create yet another trivial XYZModel class that has to be >> cumbersomely instantiated at every call-site just to convey the same >> information that already exists in the template and of course error handling >> in case the model does not match the template (inevitable, really) ... DRY >> becomes "Repeat yourself constantly" + incessant boilerplate. >> Well, sometimes technologies (in this case, java, t5, xml) interact in such >> a way that you get hit with all the ugly at once ;) >> >> Best Regards, >> Wulf >> >> >> >> -----Original Message----- >> From: Robert Zeigler [mailto:[email protected]] >> Sent: Samstag, 22. Oktober 2011 14:26 >> To: Tapestry users >> Subject: Re: ComponentResources.getInformalParameterNames() >> >> Block parameters are only one type of informal parameter.Consider: >> >> <t:mycomponent informal1="a" informal2="b" informal3="c"> >> <p:informal4>....</p:informal4> >> </t:mycomponent> >> >> Steve was thinking about attributes rather than block parameters because >> that's teh most common case for informal parameters. >> >> In your case, you need to define some sort of tab model that defines the tab >> ids as possibly also the tab names, and use the ordering from your tab model >> to determine the ordering to use. >> >> Robert >> >> On Oct 22, 2011, at 10/226:32 AM , Wechsung, Wulf wrote: >> >>> 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] >>> >> >> >> --------------------------------------------------------------------- >> 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] >> >> > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
