Yeah, but we don't need to store the id in component. It can be computed
when necessary. So even if we decide to cache it, we can clean the
cached value on detach.
I know it's just one string, but I'm starting to be concerned with the
size of Component in 2.0.
-Matej
Juergen Donnerstag wrote:
See Component.java. It is required for JavaScripts
/**
* Retrieves id by which this component is represented within the
markup.
* <p>
* If the id attribute is present in the markup attributes of this
component
* it will be used, otherwise the page-relative path of this
component will
* be used.
*
* @return the Markup id
*/
public String getMarkupId()
{
String id = getMarkupAttributes().getString("id");
if (id == null)
{
id = getPageRelativePath();
// first escape _ with __
id = id.replace("_", "__");
// then replace : with _
id = id.replace(':', '_');
getMarkupAttributes().put("id", id);
}
return id;
}
On 10/2/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
+1 to remove it. I never liked this copy on write value map. It's
nothing I can't do in onComponentTag or using a behavior.
I think method to retrieve tag attributes from markup would be
sufficient.
Btw. what would be the purpose of id variable?
-Matej
Juergen Donnerstag wrote:
> Currently Component.java maintains a copy-on-write ValueMap for markup
> attributes which user might want to change, such as getMarkupId()
> which adds the id="xxx" attribute to the tag.
>
> However, the current implementation doesn't work properly as the
> Component owned attribute map keep the "old" value even when the
> markup has been re-loaded because of locale, style or variation
> changes (see FormExample)
>
> I wonder if this general use case of being able to modify any tag
> attribute in the constructor realy exists or if "id" is the only case.
> If the latter is true, than I would like to suggest to remove
> markupAttribute from Component as it requires some realy hackish code
> later on. I'd much rather add a "id" variable to the component for the
> specific purpose of MarkupId()..
>
> What do think?
>
> Juergen
>
