wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Vaynberg" <igor.vaynb...@gmail.com>
Subject Re: MarkupAttributes in Component
Date Mon, 02 Oct 2006 15:25:35 GMT
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 <juergen.donnerstag@gmail.com> 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 <matej@knopp.sk> 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 <juergen.donnerstag@gmail.com> 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 <matej@knopp.sk> 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 <matej@knopp.sk> 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
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >> >
> > >>
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message