Hello Robert,

actually, according to this: 
http://www.ibm.com/developerworks/xml/library/x-eleord/index.html a XML parser 
would be free to report even elements alphabetically. Pure lunacy! I'm sorry to 
say, but if this is true then whoever wrote the XML spec really screwed up 
there. In documents, things have positions that are relative to other things. 
There is no possible reason to discard that information. I suspect that the 
spec means from a validity point of view "insignificant" which would make a 
whole lot of difference. Bottom line, XML parsers really should return elements 
and attributes in the order they are declared in and if they don't, the Author 
deservers a sternly worded email. There might even be adjectives! ;-)

> In fact, Tapestry facilitates this sort of approach:

That's actually a pretty good solution and I will use it. Thanks :)
As for DRY, the repeating part is where I specify which blocks I have and then 
I have to specify which blocks I have ;). 
Might be I've hit my head too hard once too often but stuff like that just 
really bothers me.

Thanks for your insightful response and your great suggestion!

Kind Regards,
Wulf



-----Original Message-----
From: Robert Zeigler [mailto:[email protected]] 
Sent: Samstag, 22. Oktober 2011 19:07
To: Tapestry users
Subject: Re: ComponentResources.getInformalParameterNames()


On Oct 22, 2011, at 10/227:59 AM , Wechsung, Wulf 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?).
> 

There's a significant difference between element order and attribute order. 
Element order is meaningful to an XML parser; attribute order is not.  You're 
hitting the weird intersection, however, of attributes + elements, since 
informal parameters can be either.

As for DRY, I see no reason for repeating yourself here. Consider, eg:

page.tml:

<t:tabcomponent tabs="tab1,tab2,tab3"><!-- you could have a coercion from, eg, 
string to "tabmodel" if necessary... but that's probably not even necessary -->
   <p:tab1>
       <!-- content goes here -->
   </p:tab1>
   ...
</t:tabcomponent>

page.properties:
tab1-label=Tab One
tab2-label=Tab Two
tab3-label=Tab Three

Your component can grab the labels from the page properties file, and now 
you're not instantiating another model, and you gain the benefit of having 
i18n'ed your tab headers, so if/when you add a language, you simply add the 
appropriate properties file (eg: page_de.properties), and your component just 
works.

In fact, Tapestry facilitates this sort of approach:

@Inject
private ComponentResources resources;

resources.getContainerMessages().get("tab1-label");

Cheers,

Robert


---------------------------------------------------------------------
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]

Reply via email to