[ http://issues.apache.org/jira/browse/TAPESTRY-889?page=comments#action_12371216 ]
André commented on TAPESTRY-889: -------------------------------- Solution suggestion: I had a look into tapestry's sources, never did that before in these places and also I'm new to hivemind etc ..., thus this is just an unqualified guess and forgive any fault in thoughts: As I understood it, Resources seem to be stored in Hivemind and then retrieved by eg. IAsset childAsset = _assetSource.findAsset(libraryResource, path, null, location); in NamespaceResourcesImpl -> findSpecificationResource() You could introduce a new element, for example <library-override id="contrib" specification-path="/org/my/own/tablePages/component/x.library"/> that would essentially function like a library, the code could resused completely. Only one override would be allowed per override, but that's perfectly sufficient - to keep things simple. You'd in there override components previously specified in eg. <library id="contrib" specification-path="/org/apache/tapestry/contrib/Contrib.library"/> This mean 1. With regard to parsing etc. everything is similar to libraries, but you should check that only one override per id is present. This library then is stored as Resource, just like with ordinary libraries, with some prefix OVERRIDE_[ID] or something like that in hivemind 2. When a specific component is requested you check a) if an override resource has been stored and use that if it has been stored b) if not, the usual mechanism applies This means 1.) One additional check in findSpecificationResource() (or the most adequate method in that region) - not sure where exactly is the best place 2.) Parser addition for <library-override ...> that act like a library but prefixes If I got it right, this would be a robust solution, solving the problem and only by adding a bit parser related code and one check. > Components and pages cannot be overriden with ease (contrary to documentation) > ------------------------------------------------------------------------------ > > Key: TAPESTRY-889 > URL: http://issues.apache.org/jira/browse/TAPESTRY-889 > Project: Tapestry > Type: Bug > Reporter: André > > In > http://jakarta.apache.org/tapestry/UsersGuide/components.html#components.libraries.namespace > it is stated that components (from framework) can be overriden. > "In fact, it is possible to override both pages and components provided by > the framework. This is frequently used to change the look and feel of the > default StateSession or Exception page. In theory, it is even possible to > override fundamental components such as Insert or Foreach!" > Why is it then not possible to override components within other namespaces? > It is, for example, not possible just to override the contrib:TablePages > component, while not touching the rest of contrib. There are several > inelegant workarounds where you have to copy more or less of the component > specs and templates. > If Insert is overrideable, why not "namespace:Insert" for instance? This > sound illogical to me and results in copy&paste'ing. > Is this functionality important? To my opinion yes > 1) It reduces code & configuration to maintain > 2) It allows upgrading of single components within components without the > need to touch the whole thing > To solve this, it would be sufficient to allow overriding components in > subsequent <library>ies. > <library id="contrib" > specification-path="/org/apache/tapestry/contrib/Contrib.library"/> > <library id="contrib" > specification-path="/org/my/own/tablePages/component/x.library"/> > This currently results in an error message. "namespace already existent" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
