Re: MarkupAttributes in Component

[Matej Knopp]

I'm not I understand this. If this worked as you suggest, then 
component.markupId may not be transient, right? Otherwise you'd have to 
call getMarkupId not only in constructor, but every time the page is 
deserialized.

What would be the benefits of removing setOutputMarkupId and 
getOutputMarkupId()?

-Matej

Juergen Donnerstag wrote:
Actually we could get rid of Component.FLAG_OUTPUT_MARKUP_ID,
Component.getOutputMarkupId() and Component.setOutputMarkupId() as
well.

If Component.getMarkupId() were implemented like
    public String getMarkupId()
    {
        String id = getMarkupAttributes().getString("id");
        if (id == null)
        {
            if (this.markupId != null)
            {
                return this.markupId;
            }
           
            id = getPageRelativePath();
            // first escape _ with __
            id = id.replace("_", "__");
            // then replace : with _
            id = id.replace(':', '_');
           
            // cache the value
            this.markupId = id;
        }
        return id;
    }

than you only need to call getMarkupId() once to make sure the id is
properly set and rendered in the output.
May getMarkupId() is not the right the name than, what about
enableMarkupId() or requiresMarkupId(boolean)

Juergen

On 10/2/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
The size of Component is not different than in 1.2, as far as I'm
aware nothing has changed so far except that Johan added
markupAttributes. Replacing markupAttribute with a transient String
doesn't increase the size either. A transient would allow us cache the
id on first request (lazy) and re-compute in case of cluster / session
reload scenarios.

Any yes, getMarkupAttributes() would be a read-only map.

Juergen

On 10/2/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> 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
> >> >
> >>
> >>
> >
>
>