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]
