look, instead of making something that is super flexible and super complicated why dont we separate these two behaviors into two different solutions. i dont think anyone would want to use both at the same time - and even if they do we can declare wicket:message and wicket:staticmessage or whatever.

what johan wants has already been implemented by eelco (?), so take that and commit it and give it a name WicketStaticMessageTagHandler and be done with that usecase.

now lets come up with a solution for the second usecase and be done with that as well.

i mean if we can come up with something simple that will work for both usecases then im more then fine with that, but lets not go overboard.

-Igor


On 9/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Properties reloading would not work then though. And it wouldn't be
useable for other purposes if we'd ever come up with that. But it
would be very efficient.

Eelco


On 9/23/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> we still have the problem of looking up the message at render time
> everytime.
> I just want an option to do it once. Just with the markup loading. No
> components
> what so ever are touched/added or needed. As long as we also have that
> option it is fine by me.
>
> johan
>
>
>
> 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

Reply via email to