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
