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]
