You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Hermod Opstvedt <he...@opstvedt.com> on 2007/03/11 12:02:43 UTC

SV: [jira] Commented: (SHALE-353) Add a new attribute allowOveride in order to prevent certain attributes from being altered when subclassing clay components

Hi

Yes, I don't think changing the DTD is the way to go, due to backwards
compatibility, so adding another attribute seems right for this.

Hermod


-----Opprinnelig melding-----
Fra: Gary VanMatre (JIRA) [mailto:jira@apache.org] 
Sendt: 11. mars 2007 03:34
Til: issues@shale.apache.org
Emne: [jira] Commented: (SHALE-353) Add a new attribute allowOveride in
order to prevent certain attributes from being altered when subclassing clay
components


    [
https://issues.apache.org/struts/browse/SHALE-353?page=com.atlassian.jira.pl
ugin.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.