that's the idea. In 2.0 because it happens in the constructor you
wouldn't need any check it is attached just once.
Juergen
On 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> so how exactly does your solution work?
>
> we add IBehavior[] slot to ComponentTag
>
> allow markup tag handlers to populate it
>
> then on _first_ render the component checks its tag and transfers the
> behaviors over to itself in 1.2 and in the construction process in 2.0?
>
>
> -Igor
>
>
> On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED] > wrote:
> > The problem that resolvers are currently only called if the component
> > can not be found might be a problem. The fix seems simple, but I can
> > imagine quite a lot of side effects. To Johans point, the resolver
> > would be called for every component, and that is exactly what we try
> > to avoid.
> >
> > Juergen
> >
> > On 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > i guess what i dont like is having yet another way to do something here
> -
> > > and that is keeping special attribute modifiers in componenttag and
> > > attaching them to the component.
> > >
> > > why cant we do this with a resolver, and using normal attribute
> modifiers?
> > >
> > > WicketMessageResolver:74
> > > if (tag.getAttributes ().containsKey("wicket:message
> > > ")&&tag.getId().startsWith("wicket-message"))
> > > {
> > > final String id = "_message_" +
> > > container.getPage().getAutoIndex();
> > > container.autoAdd(new WebMarkupContainer(id)
> > > {
> > >
> > > public boolean isTransparentResolver()
> > > {
> > > return true;
> > > }
> > >
> > > });
> > >
> > >
> > > container.add(WicketMessageAttributeModifier.INSTANCE);
> > > return true;
> > > }
> > > and then below do the same for components that had wicket:message and
> > > wicket:id attrs in the markup.
> > >
> > > doesnt this solve the problem without introducing anything new into the
> > > framework? or is this less elegant then what you had in mind?
> > >
> > > -Igor
> > >
> > >
> > >
> > > On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > > > (cont) Because of Johan's performance concerns we came up with a
> > > > solution which doesn't have that penality. If the wicket message
> > > > handler detects a wicket:message attribute, it could add an attribute
> > > > modifier to the component tag, and the render process make sure they
> > > > get attached to the components associated with these tags, hence no
> > > > performance penalty.
> > > >
> > > > Juergen
> > > >
> > > > On 9/23/06, Juergen Donnerstag < [EMAIL PROTECTED] > wrote:
> > > > > We are going in circles, the solution already was laid out. Why are
> we
> > > > > starting at the beginning again?
> > > > >
> > > > > <wicket:message> already creates a container (not exactly, it
> creates
> > > > > a label) to replace the text.
> > > > >
> > > > > Changing wicket tag identifier IMO would the completely wrong way of
> > > > > doing it. If we do that we'll end up with discussions like "my
> > > > > attribute should create a compent tag as well.". IMO the rule is
> very
> > > > > simple: every tag which has a wicket:id becomes a component tag.
> > > > > Handlers, like WicketMessageHandler need to set the wicket:id with
> an
> > > > > automatically generated id, and we have several examples for that
> > > > > already.
> > > > >
> > > > > For the render process you now must register a resolver to handle
> tags
> > > > > with wicket:message where the id has been generated automaticaly,
> > > > > because you must automatically create a very simple container for
> > > > > that. This 5 lines of code, very simple.
> > > > >
> > > > > The real issue is that wicket:message attributes might appear in
> *any*
> > > > > component. Now you call it IComponentTagHandler, when I outlined the
> > > > > solution before I called it IOnComponentRenderListener and the
> methods
> > > > > are slightly different, but it essentially the same. The reason why
> we
> > > > > were looking for another solution is because Johan was complaining
> > > > > about the performance. Every component when rendered iterates over
> the
> > > > > list of application level handlers, and in case of wicket:message
> > > > > checks the attributes if an wicket:message attribute exists or not.
> > > > > Johan is worried about the penality it takes for all the components
> > > > > which don't have wicket:message tags, besides that he think
> > > > > wicket:message doesn't need to be extended at all.
> > > > >
> > > > > Juergen
> > > > >
> > > > > On 9/23/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> > > > > > i guess part 1 can be done in a tag handler...
> > > > > >
> > > > > > -Igor
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 9/22/06, Igor Vaynberg < [EMAIL PROTECTED] > wrote:
> > > > > > > well, i looked into it and here is what you have to do. i dont
> have
> > > the
> > > > > > time this weeend (jewish new year) so maybe someone who does can
> > > implement
> > > > > > the full func.
> > > > > > >
> > > > > > > 1) you have to let wicket resolvers handle markup that has
> > > wicket:message
> > > > > > attr and no wicket:id, for this you need to make wicket think this
> tag
> > > is
> > > > > > not raw markup - so an id needs to be set
> > > > > > >
> > > > > > > WicketTagIdentifier:126
> > > > > > >
> > > > > > > // Identify wicket:message attr tags
> > > > > > > if
> > > > > >
> > > (
> xmlTag.getAttributes().containsKey("wicket:message")&&tag.getId()==null)
> > > > > > > {
> > > > > > > // replace random with some counter - but you
> get
> > > the
> > > > > > idea...
> > > > > > > tag.setId("wicket-message" + Math.random());
> > > > > > > }
> > > > > > >
> > > > > > > now we need to autoadd a webmarkupcontainer for any of these
> tags
> > > > > > >
> > > > > > > WicketMessageResolver:74
> > > > > > > if (tag.getAttributes
> > > > > >
> > >
> ().containsKey("wicket:message")&&tag.getId().startsWith("wicket-message"))
> > > > > > > {
> > > > > > > final String id = "_message_" +
> > > > > > container.getPage().getAutoIndex();
> > > > > > > container.autoAdd (new WebMarkupContainer(id)
> > > > > > > {
> > > > > > >
> > > > > > > public boolean isTransparentResolver()
> > > > > > > {
> > > > > > > return true;
> > > > > > > }
> > > > > > >
> > > > > > > });
> > > > > > > return true;
> > > > > > > }
> > > > > > >
> > > > > > > and thats the meat of it, now you need that IComponentTagHandler
> {
> > > > > > oncomponenttag() } deal, a way to register it in settings and
> > > something like
> > > > > > >
> > > > > > > Component:1666 <=== wow
> > > > > > >
> > > > > > > Iterator handlers =
> > > > > >
> > >
> getApplicationSettings().getComponentTagHandlers().iterator();
> > > > > > > while (handlers.hasNext())
> > > > > > > {
> > > > > > >
> > > > > >
> > >
> ((IComponentTagHandler)handlers.next()).onComponentTag(this,
> > > > > > tag);
> > > > > > > }
> > > > > > >
> > > > > > > and oh yeah...the taghandler that does the actual resource
> lookup
> > > > > > >
> > > > > > >
> > > > > > > -Igor
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 9/22/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > > On 9/22/06, Igor Vaynberg < [EMAIL PROTECTED] > wrote:
> > > > > > > > > but you DO want it to sync with your component tree because
> you
> > > want
> > > > > > the
> > > > > > > > > localization lookup to be synced to the component tree.
> > > > > > > >
> > > > > > > > Yep. I want it to work the same as <wicket:message>.
> > > > > > > >
> > > > > > > > Eelco
> > > > > > > >
> > > > > > > >
> > > > > >
> > >
> -------------------------------------------------------------------------
> > > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > > Join SourceForge.net's Techsay panel and you'll get the chance
> to
> > > share
> > > > > > your
> > > > > > > > opinions on IT & business topics through brief surveys -- and
> earn
> > > cash
> > > > > > > >
> > > > > >
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > >
> _______________________________________________
> > > > > > > > Wicket-develop mailing list
> > > > > > > > Wicket-develop@lists.sourceforge.net
> > > > > > > >
> > > > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > >
> -------------------------------------------------------------------------
> > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > share your
> > > > > > opinions on IT & business topics through brief surveys -- and earn
> > > cash
> > > > > >
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > >
> > > > > > _______________________________________________
> > > > > > Wicket-develop mailing list
> > > > > > Wicket-develop@lists.sourceforge.net
> > > > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> -------------------------------------------------------------------------
> > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share
> > > your
> > > > opinions on IT & business topics through brief surveys -- and earn
> cash
> > > >
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > _______________________________________________
> > > > Wicket-develop mailing list
> > > > Wicket-develop@lists.sourceforge.net
> > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > >
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > > opinions on IT & business topics through brief surveys -- and earn cash
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >
> > > _______________________________________________
> > > Wicket-develop mailing list
> > > Wicket-develop@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> > >
> > >
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
