[
https://issues.apache.org/struts/browse/SHALE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40486
]
Gary VanMatre commented on SHALE-353:
-------------------------------------
Generally when you talk about inheritance there are a couple techniques, lookup
or copy down. Clay uses the copy down approach. The inheritance is resolved
when the config beans are added to the cache. Values in the super class are
copied down.
The ComponentConfigBean's resolveInheritance methods do the work. The first
step is to hookup the inheritance pointers. Then we check for circular isa and
hasa relationships. Next, we perform the copy down. Each config bean has a
isInheritanceFinal flag to indicate the copy down has been performed. As the
recursive process works its way through the data, it has to drill up, making
sure that the parent's inheritance is final before copying down inherited data.
I'm thinking that our new allowOverride flag would work similar to the case
where there was not a parent. If there is not a parent to inherit from or the
inheritance has already been resolved, we don't attempt the copy down.
We would just ignore the inheritance versus throwing an exception. We have
other validation checks that we can only handle at runtime too. For example,
our XML configuration will allow you to add a validator to a outputLabel. Not
until runtime do we log a warning.
It would be nice if we could pull this off without changing the DTD. Maybe it
could be an attribute in the components attributes collection?
> Add a new attribute allowOveride in order to prevent certain attributes from
> being altered when subclassing clay components
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: SHALE-353
> URL: https://issues.apache.org/struts/browse/SHALE-353
> Project: Shale
> Issue Type: New Feature
> Components: Clay
> Affects Versions: 1.0.4-SNAPSHOT
> Reporter: Hermod Opstvedt
> Fix For: TBD
>
>
> In a setting where Clay components are distributed as reusable components, to
> for instance have company wide standards for look&feel etc. it would be nice
> to able to lock down certain attribute values so that when sombody subclasses
> the component they are restricted from overriding attribute that has been
> flagged.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
