How do you control it today? If getMarkupId() were changed to
getMarkupId(boolean createIfRequired) and if createIfRequired were
true, that would essentially do the same as setOutputMarkupId(true)
but create the markupId as well which gets cached and on subsequent
calls returned by getMarkupId(true/false).

I looked into Link e.g. and I think you could replace
if (anchor.getOutputMarkupId())
{
   id = anchor.getMarkupId();
}
else
{
    id = anchor.getMarkupAttributes().getString("id");
}

with just id = anchor.getMarkupId(true);

Juergen

On 10/2/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
so if i have:

final WebMarkupContainer c=new WebMarkupContainer(this, "c");

AjaxLink link=new AjaxLink(this, "l") {
  onclick(AjaxRequestTarget t) {
         t.add(c);
  }
}

how do i make c output its id if we dont have setOutputMarkupId(true)
anymore? nowhere in this code there is a call to getMarkupId().

-Igor



On 10/2/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
>
> You mentioned you fear Component gets too big, I think the API slowly
> gets bloated and this an opportunity to get rid of 2 methods which are
> IMO not needed. The number of methods has grown over time, that is
> natural and nothing to worry about, but from time to time one should
> re-think implementation, pattern etc and apply lessons learned and if
> there is an opportunity to improve in 2.0, than we should do it.
>
> Juergen
>
> On 10/2/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > 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
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >
> >
> >
>


Reply via email to