Re: [Wicket-develop] localized attributes
Sorry, my fault. Fixed it.
It should now be working.
Juergen
On 9/25/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> Could you please take a look at SimplePageTest.testRenderHomePage_7.
> Something has changed the behavior of
>
> Juergen
>
> On 9/25/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > ok, i implemented it almost all the way, but have problem for one usecase.
> >
> > it is working when it is attached to markup with wicket:id or to raw markup
> > without wicket:id
> >
> > it is not working when it is attached to raw markup that contains
> > components, ie
> >
> > > wicket:id="label">
> >
> > if you take a look at WicketMessageResolver:80 that created
> > auto-webmarkupcontainer needs to be transparent, but we took this
> > functionality out of 2.0. juergen do you know how to fix this? checkout
> > WicketMessageAttributeTest, it has a failing test in there to test this.
> >
> > -Igor
> >
> >
> >
> > On 9/24/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > > go ahead
> > >
> > > On 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > sounds good. do you want to work on it? i would happily take care of
> > this so
> > > > you have more time for the iatlernateparentprovider stuff, since i have
> > a
> > > > project waiting on that :)
> > > >
> > > >
> > > > -Igor
> > > >
> > > >
> > > > On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > > > > 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 PROT
Re: [Wicket-develop] localized attributes
Could you please take a look at SimplePageTest.testRenderHomePage_7.
Something has changed the behavior of
Juergen
On 9/25/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ok, i implemented it almost all the way, but have problem for one usecase.
>
> it is working when it is attached to markup with wicket:id or to raw markup
> without wicket:id
>
> it is not working when it is attached to raw markup that contains
> components, ie
>
> wicket:id="label">
>
> if you take a look at WicketMessageResolver:80 that created
> auto-webmarkupcontainer needs to be transparent, but we took this
> functionality out of 2.0. juergen do you know how to fix this? checkout
> WicketMessageAttributeTest, it has a failing test in there to test this.
>
> -Igor
>
>
>
> On 9/24/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > go ahead
> >
> > On 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > sounds good. do you want to work on it? i would happily take care of
> this so
> > > you have more time for the iatlernateparentprovider stuff, since i have
> a
> > > project waiting on that :)
> > >
> > >
> > > -Igor
> > >
> > >
> > > On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > > > 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?
> > > > > > > > >
> > > > > > > > > already creates a container (not exactly,
> it
> > > > > creates
> > > > > > > > > a label) to replace the text.
> > > > > > > > >
> > > > > > > > > Changing wicket tag identifier IMO
Re: [Wicket-develop] localized attributes
ok, i implemented it almost all the way, but have problem for one usecase.it is working when it is attached to markup with wicket:id or to raw markup without wicket:idit is not working when it is attached to raw markup that contains components, ie
if you take a look at WicketMessageResolver:80 that created auto-webmarkupcontainer needs to be transparent, but we took this functionality out of
2.0. juergen do you know how to fix this? checkout WicketMessageAttributeTest, it has a failing test in there to test this.-IgorOn 9/24/06, Juergen Donnerstag
<[EMAIL PROTECTED]> wrote:
go aheadOn 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:> sounds good. do you want to work on it? i would happily take care of this so> you have more time for the iatlernateparentprovider stuff, since i have a
> project waiting on that :)>>> -Igor>>> On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:> > 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?> > > > > > >> > > > > > > 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.>
Re: [Wicket-develop] localized attributes
go ahead
On 9/24/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> sounds good. do you want to work on it? i would happily take care of this so
> you have more time for the iatlernateparentprovider stuff, since i have a
> project waiting on that :)
>
>
> -Igor
>
>
> On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > 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?
> > > > > > >
> > > > > > > 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 per
Re: [Wicket-develop] localized attributes
sounds good. do you want to work on it? i would happily take care of this so you have more time for the iatlernateparentprovider stuff, since i have a project waiting on that :)-Igor
On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
that's the idea. In 2.0 because it happens in the constructor youwouldn't need any check it is attached just once.JuergenOn 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?
> > > > >> > > > > 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
Re: [Wicket-develop] localized attributes
This whole thing is 2.0 only too btw.
Eelco
On 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> 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?
> > > > > >
> > > > > > 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
> > > > > >
Re: [Wicket-develop] localized attributes
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?
> > > > >
> > > > > 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
> >
Re: [Wicket-develop] localized attributes
so how exactly does your solution work?we add IBehavior[] slot to ComponentTagallow markup tag handlers to populate itthen 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?-IgorOn 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 canimagine quite a lot of side effects. To Johans point, the resolverwould be called for every component, and that is exactly what we tryto avoid.
JuergenOn 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?> > >> > > 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("wick
Re: [Wicket-develop] localized attributes
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?
> > >
> > > 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
> > >
Re: [Wicket-develop] localized attributes
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?-IgorOn 9/23/06,
Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
(cont) Because of Johan's performance concerns we came up with asolution which doesn't have that penality. If the wicket messagehandler detects a wicket:message attribute, it could add an attributemodifier to the component tag, and the render process make sure they
get attached to the components associated with these tags, hence noperformance penalty.JuergenOn 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?>> 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 (h
Re: [Wicket-develop] localized attributes
On 9/23/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > 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. Juergen implemented that, but in a basic version (search stack only has the class that loaded the markup). I tried to fix it to take in the component, but there could be all kinds of troubles with that). Johan said earlier that a simple search stack would be good enough for him, so having that thing optionally is fine I guess. Btw, I think I still have to reverse that last change I made. > 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. Honestly, I didn't think being able to 'annotate' tags so that they can later be interpreted, e.g. to attach an attribute modifier was that crazy. I kind of see some beauty in that. 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
Re: [Wicket-develop] localized attributes
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.-IgorOn 9/23/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Properties reloading would not work then though. And it wouldn't beuseable for other purposes if we'd ever come up with that. But itwould be very efficient.EelcoOn 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?> > >> > > 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 WebMarkupCont
Re: [Wicket-develop] localized attributes
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?
> > >
> > > 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()
Re: [Wicket-develop] localized attributes
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.
johanOn 9/23/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
(cont) Because of Johan's performance concerns we came up with asolution which doesn't have that penality. If the wicket messagehandler detects a wicket:message attribute, it could add an attributemodifier to the component tag, and the render process make sure they
get attached to the components associated with these tags, hence noperformance penalty.JuergenOn 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?>> 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 .> > > >> > > > Eelco> > > >> > > >> > -
> > > > Take Surveys. Earn Cash. Influence the Future of IT> >
Re: [Wicket-develop] localized attributes
Thats true, it took some time to find a solution everyone is happy with.
Juergen
On 9/23/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ok sorry. its just that this thread has been going on for a very long time
> without any actual implementation :)
>
> -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?
> > >
> > > 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
> > > > >
> > >
Re: [Wicket-develop] localized attributes
ok sorry. its just that this thread has been going on for a very long time without any actual implementation :)-IgorOn 9/23/06, Juergen Donnerstag
<[EMAIL PROTECTED]> wrote:
(cont) Because of Johan's performance concerns we came up with asolution which doesn't have that penality. If the wicket messagehandler detects a wicket:message attribute, it could add an attributemodifier to the component tag, and the render process make sure they
get attached to the components associated with these tags, hence noperformance penalty.JuergenOn 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?>> 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 .> > > >> > > > 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 surv
Re: [Wicket-develop] localized attributes
(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?
>
> 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 .
> > > >
> > > > 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
Re: [Wicket-develop] localized attributes
We are going in circles, the solution already was laid out. Why are we
starting at the beginning again?
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 .
> > >
> > > 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
>
> ___
>
Re: [Wicket-develop] localized attributes
i guess part 1 can be done in a tag handler...-IgorOn 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 tagsWicketMessageResolver: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 likeComponent: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 .Eelco-Take Surveys. Earn Cash. Influence the Future of ITJoin
SourceForge.net's Techsay panel and you'll get the chance to share youropinions 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.nethttps://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
Re: [Wicket-develop] localized attributes
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 tagsWicketMessageResolver: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 likeComponent: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 .Eelco-Take Surveys. Earn Cash. Influence the Future of ITJoin
SourceForge.net's Techsay panel and you'll get the chance to share youropinions 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.nethttps://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
Re: [Wicket-develop] localized attributes
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 . 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
Re: [Wicket-develop] localized attributes
but you DO want it to sync with your component tree because you want the localization lookup to be synced to the component tree.-IgorOn 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:> just talked to eelco, so we want full stack for case(a) just as if it was a> component? pretty crazy, that we can handle just like wicket:message works > now - add an empty webmarkup container and let the icomponenttaghandler> handle it just like it would a regular component.So why didn't we say 'just create an empty webmarkup container' whenwe had the discussion about tags? Because the whole point is here that you can do i18n directly in your markup withouthaving to have it in sync with your component tree. Same here.Eelco- Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions 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.nethttps://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
Re: [Wicket-develop] localized attributes
On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > just talked to eelco, so we want full stack for case(a) just as if it was a > component? pretty crazy, that we can handle just like wicket:message works > now - add an empty webmarkup container and let the icomponenttaghandler > handle it just like it would a regular component. So why didn't we say 'just create an empty webmarkup container' when we had the discussion about tags? Because the whole point is here that you can do i18n directly in your markup without having to have it in sync with your component tree. Same here. 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
Re: [Wicket-develop] localized attributes
> > how about thiswhich is probably a whole lot easier... > > > > as i see it there are two cases > > a) when raw markup has this attribute > > b) when a component has this attribute (markup with wicket:id) > > > > for case (a) we dont need the full search stack do we? it makes sense to > > only try the limited stack right? > > http://www.nabble.com/localized-attributes-tf2288202.html#a6393222 Strike that, I meant http://www.nabble.com/localized-attributes-tf2288202.html#a6394446 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
Re: [Wicket-develop] localized attributes
On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > how about thiswhich is probably a whole lot easier... > > as i see it there are two cases > a) when raw markup has this attribute > b) when a component has this attribute (markup with wicket:id) > > for case (a) we dont need the full search stack do we? it makes sense to > only try the limited stack right? http://www.nabble.com/localized-attributes-tf2288202.html#a6393222 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
Re: [Wicket-develop] localized attributes
just talked to eelco, so we want full stack for case(a) just as if it was a component? pretty crazy, that we can handle just like wicket:message works now - add an empty webmarkup container and let the icomponenttaghandler handle it just like it would a regular component.
-IgorOn 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
how about thiswhich is probably a whole lot easier...as i see it there are two casesa) when raw markup has this attributeb) when a component has this attribute (markup with wicket:id)for case (a) we dont need the full search stack do we? it makes sense to only try the limited stack right?
case (b) is where the issue is right now. i think a better hook for that is to have a pluggable componenttag handler rather then some weird render-time/markup time hooks.something like IComponentTagHandler{ void onComponentTag(Component c, ComponentTag t); }
ISomeSettings.add(IComponentTagHandler handler);this is much easier to understand because it builds on a concept that you have to know anyways.-Igor
On 9/22/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:> what do you mean inspect? the attribute modifier itself can perform the
> attribute replacement/i18n, why should this be any different then regular
> ams - excpet that this one is stateless/singleton. statelesness is a> property of the behavior.>> the reason requiredvalidator.instance() is gone is that required validator> itself is gone, there is nothing stopping you from sharing behaviors that
> are meant to be stateless across component instances.Huh? We are talking about different things here. If you read back acouple of posts you'll see Juergen say:> What if the Message markup filter (which is only executed when the
> markup is loaded) were able to add a stateless attributemodifier to> the component tag and that AM gets automatically attached to the> component at render time.I was talking about how a behavior would automatically get attached to
components. In order to achieve that, I think the render processshould somewhere inspect the tags and recognize there are behaviors tobe attached. Note the 'I *think*' part, as I was asking Juergenwhether that was what he had in mind.
Eelco-Take Surveys. Earn Cash. Influence the Future of ITJoin 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 listWicket-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
Re: [Wicket-develop] localized attributes
how about thiswhich is probably a whole lot easier...as i see it there are two casesa) when raw markup has this attributeb) when a component has this attribute (markup with wicket:id)for case (a) we dont need the full search stack do we? it makes sense to only try the limited stack right?
case (b) is where the issue is right now. i think a better hook for that is to have a pluggable componenttag handler rather then some weird render-time/markup time hooks.something like IComponentTagHandler{ void onComponentTag(Component c, ComponentTag t); }
ISomeSettings.add(IComponentTagHandler handler);this is much easier to understand because it builds on a concept that you have to know anyways.-IgorOn 9/22/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:> what do you mean inspect? the attribute modifier itself can perform the> attribute replacement/i18n, why should this be any different then regular
> ams - excpet that this one is stateless/singleton. statelesness is a> property of the behavior.>> the reason requiredvalidator.instance() is gone is that required validator> itself is gone, there is nothing stopping you from sharing behaviors that
> are meant to be stateless across component instances.Huh? We are talking about different things here. If you read back acouple of posts you'll see Juergen say:> What if the Message markup filter (which is only executed when the
> markup is loaded) were able to add a stateless attributemodifier to> the component tag and that AM gets automatically attached to the> component at render time.I was talking about how a behavior would automatically get attached to
components. In order to achieve that, I think the render processshould somewhere inspect the tags and recognize there are behaviors tobe attached. Note the 'I *think*' part, as I was asking Juergenwhether that was what he had in mind.
Eelco-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___Wicket-develop mailing listWicket-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
Re: [Wicket-develop] localized attributes
On 9/22/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > what do you mean inspect? the attribute modifier itself can perform the > attribute replacement/i18n, why should this be any different then regular > ams - excpet that this one is stateless/singleton. statelesness is a > property of the behavior. > > the reason requiredvalidator.instance() is gone is that required validator > itself is gone, there is nothing stopping you from sharing behaviors that > are meant to be stateless across component instances. Huh? We are talking about different things here. If you read back a couple of posts you'll see Juergen say: > What if the Message markup filter (which is only executed when the > markup is loaded) were able to add a stateless attributemodifier to > the component tag and that AM gets automatically attached to the > component at render time. I was talking about how a behavior would automatically get attached to components. In order to achieve that, I think the render process should somewhere inspect the tags and recognize there are behaviors to be attached. Note the 'I *think*' part, as I was asking Juergen whether that was what he had in mind. 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
Re: [Wicket-develop] localized attributes
what do you mean inspect? the attribute modifier itself can perform the attribute replacement/i18n, why should this be any different then regular ams - excpet that this one is stateless/singleton. statelesness is a property of the behavior. the reason requiredvalidator.instance() is gone is that required validator itself is gone, there is nothing stopping you from sharing behaviors that are meant to be stateless across component instances.-Igor On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: either the component or I prefer to say the render process.JuergenOn 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> So components would inspect their component tags to see whether there > are static behaviors to attach?>> Eelco>>> On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:> > I think you can still bind a component to it. What I mean with > > stateless AM is when you create (new) the AM only once and you are> > able to reuse it as often as you want. E.g. we used to have some> > RequiredValidator.getInstance() before we refactored it. > >> > Juergen> >> > On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote:> > > I think behaviours/attribute modifiers could be stateless or reused > > > as long as it doesn't do something or depends in this method:> > >> > > IBehaviourvoid bind(Component component);> > >> > > johan> > > > > >> > >> > >> > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > > > On 9/22/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > > > > What if the Message markup filter (which is only executed when the> > > > > markup is loaded) were able to add a stateless attributemodifier to > > > > > the component tag and that AM gets automatically attached to the> > > > > component at render time. That would mean basically no overhead at> > > > > runtime. > > > > > Because the very same AM gets re-used for all compent tags with> > > > > wicket:message attribute it must be stateless.> > > >> > > > That sounds awesome. As general functionality too... attaching > > > > statelss AMs. This is not something that exists today right? Or did I> > > > miss something (again)?> > > >> > > > 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 ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___Wicket-develop mailing listWicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop -
Re: [Wicket-develop] localized attributes
Sounds great. Who wants to implement? Eelco On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > either the component or I prefer to say the render process. > > Juergen > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > So components would inspect their component tags to see whether there > > are static behaviors to attach? > > > > Eelco > > > > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > I think you can still bind a component to it. What I mean with > > > stateless AM is when you create (new) the AM only once and you are > > > able to reuse it as often as you want. E.g. we used to have some > > > RequiredValidator.getInstance() before we refactored it. > > > > > > Juergen > > > > > > On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > I think behaviours/attribute modifiers could be stateless or reused > > > > as long as it doesn't do something or depends in this method: > > > > > > > > IBehaviourvoid bind(Component component); > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > > What if the Message markup filter (which is only executed when the > > > > > > markup is loaded) were able to add a stateless attributemodifier to > > > > > > the component tag and that AM gets automatically attached to the > > > > > > component at render time. That would mean basically no overhead at > > > > > > runtime. > > > > > > Because the very same AM gets re-used for all compent tags with > > > > > > wicket:message attribute it must be stateless. > > > > > > > > > > That sounds awesome. As general functionality too... attaching > > > > > statelss AMs. This is not something that exists today right? Or did I > > > > > miss something (again)? > > > > > > > > > > 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 > -
Re: [Wicket-develop] localized attributes
either the component or I prefer to say the render process. Juergen On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > So components would inspect their component tags to see whether there > are static behaviors to attach? > > Eelco > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > I think you can still bind a component to it. What I mean with > > stateless AM is when you create (new) the AM only once and you are > > able to reuse it as often as you want. E.g. we used to have some > > RequiredValidator.getInstance() before we refactored it. > > > > Juergen > > > > On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > I think behaviours/attribute modifiers could be stateless or reused > > > as long as it doesn't do something or depends in this method: > > > > > > IBehaviourvoid bind(Component component); > > > > > > johan > > > > > > > > > > > > > > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > > What if the Message markup filter (which is only executed when the > > > > > markup is loaded) were able to add a stateless attributemodifier to > > > > > the component tag and that AM gets automatically attached to the > > > > > component at render time. That would mean basically no overhead at > > > > > runtime. > > > > > Because the very same AM gets re-used for all compent tags with > > > > > wicket:message attribute it must be stateless. > > > > > > > > That sounds awesome. As general functionality too... attaching > > > > statelss AMs. This is not something that exists today right? Or did I > > > > miss something (again)? > > > > > > > > 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
Re: [Wicket-develop] localized attributes
So components would inspect their component tags to see whether there are static behaviors to attach? Eelco On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > I think you can still bind a component to it. What I mean with > stateless AM is when you create (new) the AM only once and you are > able to reuse it as often as you want. E.g. we used to have some > RequiredValidator.getInstance() before we refactored it. > > Juergen > > On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > I think behaviours/attribute modifiers could be stateless or reused > > as long as it doesn't do something or depends in this method: > > > > IBehaviourvoid bind(Component component); > > > > johan > > > > > > > > > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > What if the Message markup filter (which is only executed when the > > > > markup is loaded) were able to add a stateless attributemodifier to > > > > the component tag and that AM gets automatically attached to the > > > > component at render time. That would mean basically no overhead at > > > > runtime. > > > > Because the very same AM gets re-used for all compent tags with > > > > wicket:message attribute it must be stateless. > > > > > > That sounds awesome. As general functionality too... attaching > > > statelss AMs. This is not something that exists today right? Or did I > > > miss something (again)? > > > > > > 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
Re: [Wicket-develop] localized attributes
I think you can still bind a component to it. What I mean with stateless AM is when you create (new) the AM only once and you are able to reuse it as often as you want. E.g. we used to have some RequiredValidator.getInstance() before we refactored it. Juergen On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > I think behaviours/attribute modifiers could be stateless or reused > as long as it doesn't do something or depends in this method: > > IBehaviourvoid bind(Component component); > > johan > > > > > On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > What if the Message markup filter (which is only executed when the > > > markup is loaded) were able to add a stateless attributemodifier to > > > the component tag and that AM gets automatically attached to the > > > component at render time. That would mean basically no overhead at > > > runtime. > > > Because the very same AM gets re-used for all compent tags with > > > wicket:message attribute it must be stateless. > > > > That sounds awesome. As general functionality too... attaching > > statelss AMs. This is not something that exists today right? Or did I > > miss something (again)? > > > > 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
Re: [Wicket-develop] localized attributes
On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > What if the Message markup filter (which is only executed when the > markup is loaded) were able to add a stateless attributemodifier to > the component tag and that AM gets automatically attached to the > component at render time. That would mean basically no overhead at > runtime. > Because the very same AM gets re-used for all compent tags with > wicket:message attribute it must be stateless. That sounds awesome. As general functionality too... attaching statelss AMs. This is not something that exists today right? Or did I miss something (again)? 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
Re: [Wicket-develop] localized attributes
I think behaviours/attribute modifiers could be stateless or reusedas long as it doesn't do something or depends in this method:IBehaviour void bind(Component component);johan On 9/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:> What if the Message markup filter (which is only executed when the> markup is loaded) were able to add a stateless attributemodifier to > the component tag and that AM gets automatically attached to the> component at render time. That would mean basically no overhead at> runtime.> Because the very same AM gets re-used for all compent tags with > wicket:message attribute it must be stateless.That sounds awesome. As general functionality too... attachingstatelss AMs. This is not something that exists today right? Or did Imiss something (again)? Eelco-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___Wicket-develop mailing listWicket-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
Re: [Wicket-develop] localized attributes
The localizer is not really fast. Especially when the string is not foundor deeply nested or something. Because in the past we tried to localize all optionswe generated for the AbstractChoice:if (localizeDisplayValues())
{ display = getLocalizer().getString(displayValue, this, displayValue); }we didn't have that if around it. If you remove that if or you return true in that methodand you have pretty large combobox (50 values or something)
then the localizer popups up in the profiler.. Thats why i introduced that methodand by default it is false.johanOn 9/22/06, Juergen Donnerstag
<[EMAIL PROTECTED]> wrote:
Well I don't think it is slow. It caches all properties, they areautomatically reloaded if the properties files changes, and once inmemory it is just a question of creating keys and traversing somemaps. And btw if the key was found previously it doesn't traverse the
properties maps anymore, it gets the value from the front-line cacheright away. Can it be any faster?The attributemodifier would only be attached if a wicket:message tagwas found by the markup handler. It doesn't affect any application
which doesn't use wicket:message attributes.You do have that option already. It is trivial to add a flag toWicketMessageHandler or create different ones to control it defaultbehavior: resolve or attach AM
JuergenOn 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote:> there is one other problem> Our localizer object is not the fastest thing in the world.
> So i guess that thing will be called everytime? Because the components can> be attached> by any locale but the markup itself is also for one.>> I just would love to have an option that my messages are parsed once at
> loading of the markup> We can have other approaches if people want messages in all strange places> by doing at at render time.>> johan On 9/22/06, Juergen Donnerstag <
[EMAIL PROTECTED]> wrote:> > What if the Message markup filter (which is only executed when the> > markup is loaded) were able to add a stateless attributemodifier to
> > the component tag and that AM gets automatically attached to the> > component at render time. That would mean basically no overhead at> > runtime.> > Because the very same AM gets re-used for all compent tags with
> > wicket:message attribute it must be stateless.> >> > Juergen> >> > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > But i want a choice that i want it on markup loading time> > > i don't want the penalty for constantly looking all the resources up> when it> > > is not needed> > > So we should support both.
> > >> > >> > > johan> > >> > >> > >> > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]
> wrote:> > > > You are talking about *your* use cases, while the more complex lookup> > > > mechanism came from actual requests from people. I think resource> > > > bundles work good for many cases, and I think the fact that we're able
> > > > to do such lookups is a good selling point for Wicket. Also, again,> > > > while we should try to keep things simple in our implementations, it> > > > shouldn't be the major factor in deciding whether to support something
> > > > or not. This feature was asked for by users, and when voted on, it got> > > > quite some plusses of users that wanted it. And now that I'm writing> > > > about localization, I thought this feature, together with
> > > > is actually pretty powerful.> > > >> > > > So, if we can find a reasonable way to support this, I'd be all for> it.> > > >
> > > > Eelco> > > >> > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> > > > > what we currently do is over complex and in all my usecases i have
> > > totally> > > > > not needed> > > > > but maybe in my cases i had where real i18n was needed it was always> > > > > different> > > > > The messages where always comming from a database. Never from
> property> > > > > files.> > > > >> > > > > I think the current way of walking the hierachy and so on is> extremely> > > > > complex
> > > > > We should reduce the choices not extend them. Keep it simple> > > > >> > > > > johan> > > > >> > > > >> > > > >
> > > > > On 9/19/06, Eelco Hillenius < [EMAIL PROTECTED] > wrote:> > > > > > I would rather not support it at all if it is that limited. Like I
> > > > > > said before, we would support an advanced lookup with> > > > > > > key="foo"> but something very basic with > wicket:message="bar=foo"
> > > > > > />. I don't want to explain this to users, and I don't like the> > > > > > inconsistency. I'm for the best solution, not the easiest for us> to> > > > > > implement or maintain.
> > > > > >> > > > > > Eelco> > > > > >> > > > > >> > > > > > On 9/19/06, Johan Compagner <
[EMAIL PROTECTED]> wrote:> > > > > > > i think i still prefer the doing it once by loading the markup.> > > > > > > The maybe we loose some advanced localization but i find this
> > > > > acceptable.> > > > > > > What options do we then loose?> > > > > > >> > > > > > > If these options work the
Re: [Wicket-develop] localized attributes
Well I don't think it is slow. It caches all properties, they are automatically reloaded if the properties files changes, and once in memory it is just a question of creating keys and traversing some maps. And btw if the key was found previously it doesn't traverse the properties maps anymore, it gets the value from the front-line cache right away. Can it be any faster? The attributemodifier would only be attached if a wicket:message tag was found by the markup handler. It doesn't affect any application which doesn't use wicket:message attributes. You do have that option already. It is trivial to add a flag to WicketMessageHandler or create different ones to control it default behavior: resolve or attach AM Juergen On 9/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > there is one other problem > Our localizer object is not the fastest thing in the world. > So i guess that thing will be called everytime? Because the components can > be attached > by any locale but the markup itself is also for one. > > I just would love to have an option that my messages are parsed once at > loading of the markup > We can have other approaches if people want messages in all strange places > by doing at at render time. > > johan > > > > On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > What if the Message markup filter (which is only executed when the > > markup is loaded) were able to add a stateless attributemodifier to > > the component tag and that AM gets automatically attached to the > > component at render time. That would mean basically no overhead at > > runtime. > > Because the very same AM gets re-used for all compent tags with > > wicket:message attribute it must be stateless. > > > > Juergen > > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > But i want a choice that i want it on markup loading time > > > i don't want the penalty for constantly looking all the resources up > when it > > > is not needed > > > So we should support both. > > > > > > > > > johan > > > > > > > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > You are talking about *your* use cases, while the more complex lookup > > > > mechanism came from actual requests from people. I think resource > > > > bundles work good for many cases, and I think the fact that we're able > > > > to do such lookups is a good selling point for Wicket. Also, again, > > > > while we should try to keep things simple in our implementations, it > > > > shouldn't be the major factor in deciding whether to support something > > > > or not. This feature was asked for by users, and when voted on, it got > > > > quite some plusses of users that wanted it. And now that I'm writing > > > > about localization, I thought this feature, together with > > > > is actually pretty powerful. > > > > > > > > So, if we can find a reasonable way to support this, I'd be all for > it. > > > > > > > > Eelco > > > > > > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > what we currently do is over complex and in all my usecases i have > > > totally > > > > > not needed > > > > > but maybe in my cases i had where real i18n was needed it was always > > > > > different > > > > > The messages where always comming from a database. Never from > property > > > > > files. > > > > > > > > > > I think the current way of walking the hierachy and so on is > extremely > > > > > complex > > > > > We should reduce the choices not extend them. Keep it simple > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > On 9/19/06, Eelco Hillenius < [EMAIL PROTECTED] > wrote: > > > > > > I would rather not support it at all if it is that limited. Like I > > > > > > said before, we would support an advanced lookup with > > > > > > key="foo"> but something very basic with wicket:message="bar=foo" > > > > > > />. I don't want to explain this to users, and I don't like the > > > > > > inconsistency. I'm for the best solution, not the easiest for us > to > > > > > > implement or maintain. > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > > > i think i still prefer the doing it once by loading the markup. > > > > > > > The maybe we loose some advanced localization but i find this > > > > > acceptable. > > > > > > > What options do we then loose? > > > > > > > > > > > > > > If these options work then it is fine: > > > > > > > > > > > > > > Xxxx.html > > > > > > > gets its messages from: > > > > > > > > > > > > > > Xxxx.properties > > > > > > > > > > > > > > MyApplicaiton.properties > > > > > > > > > > > > > > and there own Localization component should be able to resolve > it by > > > key > > > > > (if > > > > > > > they are comming from a database) > > > > > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]> > > > wrote: > > > > > > > > You are mixing things here.
Re: [Wicket-develop] localized attributes
there is one other problemOur localizer object is not the fastest thing in the world.So i guess that thing will be called everytime? Because the components can be attachedby any locale but the markup itself is also for one. I just would love to have an option that my messages are parsed once at loading of the markupWe can have other approaches if people want messages in all strange places by doing at at render time.johan On 9/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: What if the Message markup filter (which is only executed when themarkup is loaded) were able to add a stateless attributemodifier tothe component tag and that AM gets automatically attached to thecomponent at render time. That would mean basically no overhead at runtime.Because the very same AM gets re-used for all compent tags withwicket:message attribute it must be stateless.JuergenOn 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> But i want a choice that i want it on markup loading time> i don't want the penalty for constantly looking all the resources up when it> is not needed> So we should support both. >>> johan On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > You are talking about *your* use cases, while the more complex lookup > > mechanism came from actual requests from people. I think resource> > bundles work good for many cases, and I think the fact that we're able> > to do such lookups is a good selling point for Wicket. Also, again, > > while we should try to keep things simple in our implementations, it> > shouldn't be the major factor in deciding whether to support something> > or not. This feature was asked for by users, and when voted on, it got > > quite some plusses of users that wanted it. And now that I'm writing> > about localization, I thought this feature, together with> > is actually pretty powerful. > >> > So, if we can find a reasonable way to support this, I'd be all for it.> >> > Eelco> >> > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> > > what we currently do is over complex and in all my usecases i have> totally> > > not needed> > > but maybe in my cases i had where real i18n was needed it was always > > > different> > > The messages where always comming from a database. Never from property> > > files.> > >> > > I think the current way of walking the hierachy and so on is extremely > > > complex> > > We should reduce the choices not extend them. Keep it simple> > >> > > johan> > >> > >> > >> > > On 9/19/06, Eelco Hillenius < [EMAIL PROTECTED] > wrote:> > > > I would rather not support it at all if it is that limited. Like I> > > > said before, we would support an advanced lookup with > > > > key="foo"> but something very basic with > > > > />. I don't want to explain this to users, and I don't like the> > > > inconsistency. I'm for the best solution, not the easiest for us to > > > > implement or maintain.> > > >> > > > Eelco> > > >> > > >> > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> > > > > i think i still prefer the doing it once by loading the markup.> > > > > The maybe we loose some advanced localization but i find this > > > acceptable.> > > > > What options do we then loose?> > > > >> > > > > If these options work then it is fine:> > > > >> > > > > Xxxx.html> > > > > gets its messages from:> > > > >> > > > > Xxxx.properties> > > > >> > > > > MyApplicaiton.properties> > > > > > > > > > and there own Localization component should be able to resolve it by> key> > > (if> > > > > they are comming from a database)> > > > > > > > > > johan> > > > >> > > > >> > > > >> > > > > On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]>> wrote:> > > > > > You are mixing things here. Markup tags become component tags if> they> > > > > > have a wicket:id. This is the only rule. because by > > > > > > default it doesn't have a wicket:id gets an id automatically> > > > > > (-xxx) assigned for the markup tag to become a component> tags.> > > > > > The same happens to autolinks, etc and it happens at markup > > > > > > load time and hence just once per component *type*.> > > > > >> > > > > > While rendering a component *instance* the resolvers are applied> and > > > > > > in case of > wicket:id="-1234"> a> > > > > > resolver could localize an attributes values. The resolver in > these> > > > > > case would actually be independent from any component type as it> would> > > > > > look for wicket:message in the current tag only and on the fly > modify> > > > > > the attribute.> > > > > >> > > > > > Juergen> > > > > >> > > > > >> > > > > > On 9/19/06, Eelco Hillenius < [EMAIL PROTECTED] > wrote:> > > > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED] >> > > wrote:> > > > > > > > We do that already in other cases. Make it an auto component> and> > > you> > > > > > > > can easily hook a resolver on it. > > > > > > >> > > > > > > That would only work for tags that are not component tags to> begin.> > > As> > > > > > > soon as you would decide to put wicket:id i
Re: [Wicket-develop] localized attributes
What if the Message markup filter (which is only executed when the markup is loaded) were able to add a stateless attributemodifier to the component tag and that AM gets automatically attached to the component at render time. That would mean basically no overhead at runtime. Because the very same AM gets re-used for all compent tags with wicket:message attribute it must be stateless. Juergen On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > But i want a choice that i want it on markup loading time > i don't want the penalty for constantly looking all the resources up when it > is not needed > So we should support both. > > > johan > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > You are talking about *your* use cases, while the more complex lookup > > mechanism came from actual requests from people. I think resource > > bundles work good for many cases, and I think the fact that we're able > > to do such lookups is a good selling point for Wicket. Also, again, > > while we should try to keep things simple in our implementations, it > > shouldn't be the major factor in deciding whether to support something > > or not. This feature was asked for by users, and when voted on, it got > > quite some plusses of users that wanted it. And now that I'm writing > > about localization, I thought this feature, together with > > is actually pretty powerful. > > > > So, if we can find a reasonable way to support this, I'd be all for it. > > > > Eelco > > > > On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > what we currently do is over complex and in all my usecases i have > totally > > > not needed > > > but maybe in my cases i had where real i18n was needed it was always > > > different > > > The messages where always comming from a database. Never from property > > > files. > > > > > > I think the current way of walking the hierachy and so on is extremely > > > complex > > > We should reduce the choices not extend them. Keep it simple > > > > > > johan > > > > > > > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote: > > > > I would rather not support it at all if it is that limited. Like I > > > > said before, we would support an advanced lookup with > > > key="foo"> but something very basic with > > > />. I don't want to explain this to users, and I don't like the > > > > inconsistency. I'm for the best solution, not the easiest for us to > > > > implement or maintain. > > > > > > > > Eelco > > > > > > > > > > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > i think i still prefer the doing it once by loading the markup. > > > > > The maybe we loose some advanced localization but i find this > > > acceptable. > > > > > What options do we then loose? > > > > > > > > > > If these options work then it is fine: > > > > > > > > > > Xxxx.html > > > > > gets its messages from: > > > > > > > > > > Xxxx.properties > > > > > > > > > > MyApplicaiton.properties > > > > > > > > > > and there own Localization component should be able to resolve it by > key > > > (if > > > > > they are comming from a database) > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]> > wrote: > > > > > > You are mixing things here. Markup tags become component tags if > they > > > > > > have a wicket:id. This is the only rule. because by > > > > > > default it doesn't have a wicket:id gets an id automatically > > > > > > (-xxx) assigned for the markup tag to become a component > tags. > > > > > > The same happens to autolinks, etc and it happens at markup > > > > > > load time and hence just once per component *type*. > > > > > > > > > > > > While rendering a component *instance* the resolvers are applied > and > > > > > > in case of wicket:id="-1234"> a > > > > > > resolver could localize an attributes values. The resolver in > these > > > > > > case would actually be independent from any component type as it > would > > > > > > look for wicket:message in the current tag only and on the fly > modify > > > > > > the attribute. > > > > > > > > > > > > Juergen > > > > > > > > > > > > > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote: > > > > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> > > > wrote: > > > > > > > > We do that already in other cases. Make it an auto component > and > > > you > > > > > > > > can easily hook a resolver on it. > > > > > > > > > > > > > > That would only work for tags that are not component tags to > begin. > > > As > > > > > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > > > > > through a component resolver and would thus not be processed, > right? > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > Take Surveys. Earn Cash. Influence the Future of IT > > > > > > > Join SourceForge.net's Techsay panel and you'll g
Re: [Wicket-develop] localized attributes
But i want a choice that i want it on markup loading timei don't want the penalty for constantly looking all the resources up when it is not neededSo we should support both.johan On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: You are talking about *your* use cases, while the more complex lookupmechanism came from actual requests from people. I think resourcebundles work good for many cases, and I think the fact that we're ableto do such lookups is a good selling point for Wicket. Also, again, while we should try to keep things simple in our implementations, itshouldn't be the major factor in deciding whether to support somethingor not. This feature was asked for by users, and when voted on, it got quite some plusses of users that wanted it. And now that I'm writingabout localization, I thought this feature, together with is actually pretty powerful.So, if we can find a reasonable way to support this, I'd be all for it. EelcoOn 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:> what we currently do is over complex and in all my usecases i have totally> not needed > but maybe in my cases i had where real i18n was needed it was always> different> The messages where always comming from a database. Never from property> files.>> I think the current way of walking the hierachy and so on is extremely > complex> We should reduce the choices not extend them. Keep it simple>> johan On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote:> > I would rather not support it at all if it is that limited. Like I> > said before, we would support an advanced lookup with > > key="foo"> but something very basic with > > />. I don't want to explain this to users, and I don't like the> > inconsistency. I'm for the best solution, not the easiest for us to> > implement or maintain.> >> > Eelco > >> >> > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> > > i think i still prefer the doing it once by loading the markup. > > > The maybe we loose some advanced localization but i find this> acceptable.> > > What options do we then loose?> > >> > > If these options work then it is fine: > > >> > > Xxxx.html> > > gets its messages from:> > >> > > Xxxx.properties> > >> > > MyApplicaiton.properties> > > > > > and there own Localization component should be able to resolve it by key> (if> > > they are comming from a database)> > >> > > johan> > >> > > > > >> > > On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > > > You are mixing things here. Markup tags become component tags if they > > > > have a wicket:id. This is the only rule. because by> > > > default it doesn't have a wicket:id gets an id automatically> > > > (-xxx) assigned for the markup tag to become a component tags. > > > > The same happens to autolinks, etc and it happens at markup> > > > load time and hence just once per component *type*.> > > >> > > > While rendering a component *instance* the resolvers are applied and > > > > in case of a> > > > resolver could localize an attributes values. The resolver in these > > > > case would actually be independent from any component type as it would> > > > look for wicket:message in the current tag only and on the fly modify> > > > the attribute. > > > >> > > > Juergen> > > >> > > >> > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote:> > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]>> wrote:> > > > > > We do that already in other cases. Make it an auto component and > you> > > > > > can easily hook a resolver on it.> > > > >> > > > > That would only work for tags that are not component tags to begin.> As> > > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > > > through a component resolver and would thus not be processed, right?> > > > >> > > > > 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://list
Re: [Wicket-develop] localized attributes
> pulic interface IOnComponentRenderListener
> {
> void onComponentRender(Component, ComponentTag)
> }
That could work. Kind of AOP-ish. It potentially breaks encapsulation,
but that's with anything AOP-ish I guess.
We should define whether the call back comes before or after the
rendering, and maybe in that respect, this interface would be more
useful:
pulic interface IOnComponentRenderListener {
void beginComponentRender(Component, ComponentTag)
void beginComponentRender(Component, ComponentTag)
}
I can see advantages in this. But we should think about it a bit
because it means opening up more. What do others think?
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
Re: [Wicket-develop] localized attributes
You are talking about *your* use cases, while the more complex lookup mechanism came from actual requests from people. I think resource bundles work good for many cases, and I think the fact that we're able to do such lookups is a good selling point for Wicket. Also, again, while we should try to keep things simple in our implementations, it shouldn't be the major factor in deciding whether to support something or not. This feature was asked for by users, and when voted on, it got quite some plusses of users that wanted it. And now that I'm writing about localization, I thought this feature, together with is actually pretty powerful. So, if we can find a reasonable way to support this, I'd be all for it. Eelco On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > what we currently do is over complex and in all my usecases i have totally > not needed > but maybe in my cases i had where real i18n was needed it was always > different > The messages where always comming from a database. Never from property > files. > > I think the current way of walking the hierachy and so on is extremely > complex > We should reduce the choices not extend them. Keep it simple > > johan > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > I would rather not support it at all if it is that limited. Like I > > said before, we would support an advanced lookup with > key="foo"> but something very basic with > />. I don't want to explain this to users, and I don't like the > > inconsistency. I'm for the best solution, not the easiest for us to > > implement or maintain. > > > > Eelco > > > > > > On 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > i think i still prefer the doing it once by loading the markup. > > > The maybe we loose some advanced localization but i find this > acceptable. > > > What options do we then loose? > > > > > > If these options work then it is fine: > > > > > > Xxxx.html > > > gets its messages from: > > > > > > Xxxx.properties > > > > > > MyApplicaiton.properties > > > > > > and there own Localization component should be able to resolve it by key > (if > > > they are comming from a database) > > > > > > johan > > > > > > > > > > > > On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > You are mixing things here. Markup tags become component tags if they > > > > have a wicket:id. This is the only rule. because by > > > > default it doesn't have a wicket:id gets an id automatically > > > > (-xxx) assigned for the markup tag to become a component tags. > > > > The same happens to autolinks, etc and it happens at markup > > > > load time and hence just once per component *type*. > > > > > > > > While rendering a component *instance* the resolvers are applied and > > > > in case of a > > > > resolver could localize an attributes values. The resolver in these > > > > case would actually be independent from any component type as it would > > > > look for wicket:message in the current tag only and on the fly modify > > > > the attribute. > > > > > > > > Juergen > > > > > > > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> > wrote: > > > > > > We do that already in other cases. Make it an auto component and > you > > > > > > can easily hook a resolver on it. > > > > > > > > > > That would only work for tags that are not component tags to begin. > As > > > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > > > through a component resolver and would thus not be processed, right? > > > > > > > > > > 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 > > > > > > > > > > > > > >
Re: [Wicket-develop] localized attributes
By the way i like to resolve the messages at load time not render time.The only drawback i see is reloading of those messages when the change.. that can be tricky.. others are only plusses. johan On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > and there own Localization component should be able to resolve it by key (if> they are comming from a database)what do mean by "and there own Localization component"? At markup loadtime you only have the component type, not the instance. It would be the localizer registered with the application to find the localizedvalue.The point Eelco was making earlier is the inconsistency between and wicket:message. The former one *is* resolved at render time and hence has all the component information at hand.wicket:message in contrast has not.JuergenOn 9/19/06, Johan Compagner <[EMAIL PROTECTED] > wrote:> i think i still prefer the doing it once by loading the markup.> The maybe we loose some advanced localization but i find this acceptable.> What options do we then loose?>> If these options work then it is fine: >> Xxxx.html> gets its messages from:>> Xxxx.properties>> MyApplicaiton.properties>> and there own Localization component should be able to resolve it by key (if > they are comming from a database)>> johan On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > You are mixing things here. Markup tags become component tags if they> > have a wicket:id. This is the only rule. because by> > default it doesn't have a wicket:id gets an id automatically > > (-xxx) assigned for the markup tag to become a component tags.> > The same happens to autolinks, etc and it happens at markup> > load time and hence just once per component *type*. > >> > While rendering a component *instance* the resolvers are applied and> > in case of a> > resolver could localize an attributes values. The resolver in these > > case would actually be independent from any component type as it would> > look for wicket:message in the current tag only and on the fly modify> > the attribute.> >> > Juergen > >> >> > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > > > We do that already in other cases. Make it an auto component and you> > > > can easily hook a resolver on it.> > >> > > That would only work for tags that are not component tags to begin. As > > > soon as you would decide to put wicket:id in it, it wouldn't go> > > through a component resolver and would thus not be processed, right?> > >> > > 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 ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___Wicket-develop mailing listWicket-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
Re: [Wicket-develop] localized attributes
with there own localization component i meant there implementation of IStringResourceLoader.It is a bit deeper away in wicket then i am used to in other frameworks (see my other post)johan On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > and there own Localization component should be able to resolve it by key (if> they are comming from a database)what do mean by "and there own Localization component"? At markup loadtime you only have the component type, not the instance. It would be the localizer registered with the application to find the localizedvalue.The point Eelco was making earlier is the inconsistency between and wicket:message. The former one *is* resolved at render time and hence has all the component information at hand.wicket:message in contrast has not.JuergenOn 9/19/06, Johan Compagner <[EMAIL PROTECTED] > wrote:> i think i still prefer the doing it once by loading the markup.> The maybe we loose some advanced localization but i find this acceptable.> What options do we then loose?>> If these options work then it is fine: >> Xxxx.html> gets its messages from:>> Xxxx.properties>> MyApplicaiton.properties>> and there own Localization component should be able to resolve it by key (if > they are comming from a database)>> johan On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > You are mixing things here. Markup tags become component tags if they> > have a wicket:id. This is the only rule. because by> > default it doesn't have a wicket:id gets an id automatically > > (-xxx) assigned for the markup tag to become a component tags.> > The same happens to autolinks, etc and it happens at markup> > load time and hence just once per component *type*. > >> > While rendering a component *instance* the resolvers are applied and> > in case of a> > resolver could localize an attributes values. The resolver in these > > case would actually be independent from any component type as it would> > look for wicket:message in the current tag only and on the fly modify> > the attribute.> >> > Juergen > >> >> > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > > > We do that already in other cases. Make it an auto component and you> > > > can easily hook a resolver on it.> > >> > > That would only work for tags that are not component tags to begin. As > > > soon as you would decide to put wicket:id in it, it wouldn't go> > > through a component resolver and would thus not be processed, right?> > >> > > 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 ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___Wicket-develop mailing listWicket-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 s
Re: [Wicket-develop] localized attributes
what we currently do is over complex and in all my usecases i have totally not neededbut maybe in my cases i had where real i18n was needed it was always differentThe messages where always comming from a database. Never from property files. I think the current way of walking the hierachy and so on is extremely complexWe should reduce the choices not extend them. Keep it simplejohanOn 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: I would rather not support it at all if it is that limited. Like Isaid before, we would support an advanced lookup with key="foo"> but something very basic with />. I don't want to explain this to users, and I don't like theinconsistency. I'm for the best solution, not the easiest for us toimplement or maintain.EelcoOn 9/19/06, Johan Compagner < [EMAIL PROTECTED]> wrote:> i think i still prefer the doing it once by loading the markup.> The maybe we loose some advanced localization but i find this acceptable. > What options do we then loose?>> If these options work then it is fine:>> Xxxx.html> gets its messages from:>> Xxxx.properties>> MyApplicaiton.properties >> and there own Localization component should be able to resolve it by key (if> they are comming from a database)>> johan On 9/19/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > You are mixing things here. Markup tags become component tags if they> > have a wicket:id. This is the only rule. because by > > default it doesn't have a wicket:id gets an id automatically> > (-xxx) assigned for the markup tag to become a component tags.> > The same happens to autolinks, etc and it happens at markup > > load time and hence just once per component *type*.> >> > While rendering a component *instance* the resolvers are applied and> > in case of a > > resolver could localize an attributes values. The resolver in these> > case would actually be independent from any component type as it would> > look for wicket:message in the current tag only and on the fly modify > > the attribute.> >> > Juergen> >> >> > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > > > We do that already in other cases. Make it an auto component and you > > > > can easily hook a resolver on it.> > >> > > That would only work for tags that are not component tags to begin. As> > > soon as you would decide to put wicket:id in it, it wouldn't go > > > through a component resolver and would thus not be processed, right?> > >> > > 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 youropinions 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.nethttps://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
Re: [Wicket-develop] localized attributes
yes you are right, the interceptor exists only for components which
are not easily found. Suggestion on how to solve it: Every component
may sublcass Component.onRender(MarkupStream) and/or
Component.onComponentTag(ComponentTag). Both methods make the current
tag available for change and actually quite some components extend
onComponentTag to make sure assumptions are met. However that is
limited to specific components and not a global listener which can be
applied to *any* component. But I think we could quite easily
accomplish that by allowing for an Application to register
implementations of of the interface below. It'd be up to the
implementation if what it wants to do is dependent on the component
type or its markup and react accordingly.
pulic interface IOnComponentRenderListener
{
void onComponentRender(Component, ComponentTag)
}
With respect to wicket:message such as listener could be registered by
default and we are done. What do you think?
Juergen
On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > You are mixing things here. Markup tags become component tags if they
> > have a wicket:id. This is the only rule. because by
> > default it doesn't have a wicket:id gets an id automatically
> > (-xxx) assigned for the markup tag to become a component tags.
> > The same happens to autolinks, etc and it happens at markup
> > load time and hence just once per component *type*.
> >
> > While rendering a component *instance* the resolvers are applied and
> > in case of a
> > resolver could localize an attributes values.
>
> Maybe I'm looking at the wrong place, but I thought we were talking
> about IComponentResolver, which is used in
> MarkupContainer.renderNext(MarkupStream) only if a component with the
> provided id could not be found.
>
> What I understand from looking at the code is this:
>
>
>
> could work, as it could be given an id, thus making it a component
> tag, but as it couldn't be resolved, it would be located by a
> component resolver. This would work perfect for our purposes. However,
> this:
>
> wicket:message="value=mykey" />
>
> Would not, as it is a regular component that would be resolved by just
> asking the container (MarkupContainer:1252). It would not go through
> any component resolving and thus would never have it's attributes
> touched by it, correct?
>
> 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
Re: [Wicket-develop] localized attributes
Another thing I found out is that my lookup thingy is not working either, as there is no page yet if the loading is done via a bookmarkable request target. Markup loading can be triggered from many places unfortunately. I'll remove that code again. Eelco On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I would rather not support it at all if it is that limited. Like I > said before, we would support an advanced lookup with key="foo"> but something very basic with />. I don't want to explain this to users, and I don't like the > inconsistency. I'm for the best solution, not the easiest for us to > implement or maintain. > > Eelco > > > On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > i think i still prefer the doing it once by loading the markup. > > The maybe we loose some advanced localization but i find this acceptable. > > What options do we then loose? > > > > If these options work then it is fine: > > > > Xxxx.html > > gets its messages from: > > > > Xxxx.properties > > > > MyApplicaiton.properties > > > > and there own Localization component should be able to resolve it by key (if > > they are comming from a database) > > > > johan > > > > > > > > On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > You are mixing things here. Markup tags become component tags if they > > > have a wicket:id. This is the only rule. because by > > > default it doesn't have a wicket:id gets an id automatically > > > (-xxx) assigned for the markup tag to become a component tags. > > > The same happens to autolinks, etc and it happens at markup > > > load time and hence just once per component *type*. > > > > > > While rendering a component *instance* the resolvers are applied and > > > in case of a > > > resolver could localize an attributes values. The resolver in these > > > case would actually be independent from any component type as it would > > > look for wicket:message in the current tag only and on the fly modify > > > the attribute. > > > > > > Juergen > > > > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > > We do that already in other cases. Make it an auto component and you > > > > > can easily hook a resolver on it. > > > > > > > > That would only work for tags that are not component tags to begin. As > > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > > through a component resolver and would thus not be processed, right? > > > > > > > > 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
Re: [Wicket-develop] localized attributes
I would rather not support it at all if it is that limited. Like I said before, we would support an advanced lookup with but something very basic with . I don't want to explain this to users, and I don't like the inconsistency. I'm for the best solution, not the easiest for us to implement or maintain. Eelco On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > i think i still prefer the doing it once by loading the markup. > The maybe we loose some advanced localization but i find this acceptable. > What options do we then loose? > > If these options work then it is fine: > > Xxxx.html > gets its messages from: > > Xxxx.properties > > MyApplicaiton.properties > > and there own Localization component should be able to resolve it by key (if > they are comming from a database) > > johan > > > > On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > You are mixing things here. Markup tags become component tags if they > > have a wicket:id. This is the only rule. because by > > default it doesn't have a wicket:id gets an id automatically > > (-xxx) assigned for the markup tag to become a component tags. > > The same happens to autolinks, etc and it happens at markup > > load time and hence just once per component *type*. > > > > While rendering a component *instance* the resolvers are applied and > > in case of a > > resolver could localize an attributes values. The resolver in these > > case would actually be independent from any component type as it would > > look for wicket:message in the current tag only and on the fly modify > > the attribute. > > > > Juergen > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > We do that already in other cases. Make it an auto component and you > > > > can easily hook a resolver on it. > > > > > > That would only work for tags that are not component tags to begin. As > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > through a component resolver and would thus not be processed, right? > > > > > > 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
Re: [Wicket-develop] localized attributes
On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > You are mixing things here. Markup tags become component tags if they > have a wicket:id. This is the only rule. because by > default it doesn't have a wicket:id gets an id automatically > (-xxx) assigned for the markup tag to become a component tags. > The same happens to autolinks, etc and it happens at markup > load time and hence just once per component *type*. > > While rendering a component *instance* the resolvers are applied and > in case of a > resolver could localize an attributes values. Maybe I'm looking at the wrong place, but I thought we were talking about IComponentResolver, which is used in MarkupContainer.renderNext(MarkupStream) only if a component with the provided id could not be found. What I understand from looking at the code is this: could work, as it could be given an id, thus making it a component tag, but as it couldn't be resolved, it would be located by a component resolver. This would work perfect for our purposes. However, this: Would not, as it is a regular component that would be resolved by just asking the container (MarkupContainer:1252). It would not go through any component resolving and thus would never have it's attributes touched by it, correct? 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
Re: [Wicket-develop] localized attributes
> and there own Localization component should be able to resolve it by key (if > they are comming from a database) what do mean by "and there own Localization component"? At markup load time you only have the component type, not the instance. It would be the localizer registered with the application to find the localized value. The point Eelco was making earlier is the inconsistency between and wicket:message. The former one *is* resolved at render time and hence has all the component information at hand. wicket:message in contrast has not. Juergen On 9/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > i think i still prefer the doing it once by loading the markup. > The maybe we loose some advanced localization but i find this acceptable. > What options do we then loose? > > If these options work then it is fine: > > Xxxx.html > gets its messages from: > > Xxxx.properties > > MyApplicaiton.properties > > and there own Localization component should be able to resolve it by key (if > they are comming from a database) > > johan > > > > On 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > You are mixing things here. Markup tags become component tags if they > > have a wicket:id. This is the only rule. because by > > default it doesn't have a wicket:id gets an id automatically > > (-xxx) assigned for the markup tag to become a component tags. > > The same happens to autolinks, etc and it happens at markup > > load time and hence just once per component *type*. > > > > While rendering a component *instance* the resolvers are applied and > > in case of a > > resolver could localize an attributes values. The resolver in these > > case would actually be independent from any component type as it would > > look for wicket:message in the current tag only and on the fly modify > > the attribute. > > > > Juergen > > > > > > On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > We do that already in other cases. Make it an auto component and you > > > > can easily hook a resolver on it. > > > > > > That would only work for tags that are not component tags to begin. As > > > soon as you would decide to put wicket:id in it, it wouldn't go > > > through a component resolver and would thus not be processed, right? > > > > > > 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
Re: [Wicket-develop] localized attributes
i think i still prefer the doing it once by loading the markup.The maybe we loose some advanced localization but i find this acceptable.What options do we then loose?If these options work then it is fine: Xxxx.htmlgets its messages from:Xxxx.propertiesMyApplicaiton.propertiesand there own Localization component should be able to resolve it by key (if they are comming from a database) johanOn 9/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: You are mixing things here. Markup tags become component tags if theyhave a wicket:id. This is the only rule. because bydefault it doesn't have a wicket:id gets an id automatically(-xxx) assigned for the markup tag to become a component tags. The same happens to autolinks, etc and it happens at markupload time and hence just once per component *type*.While rendering a component *instance* the resolvers are applied andin case of a resolver could localize an attributes values. The resolver in thesecase would actually be independent from any component type as it wouldlook for wicket:message in the current tag only and on the fly modify the attribute.JuergenOn 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:> > We do that already in other cases. Make it an auto component and you> > can easily hook a resolver on it.>> That would only work for tags that are not component tags to begin. As > soon as you would decide to put wicket:id in it, it wouldn't go> through a component resolver and would thus not be processed, right?>> 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 ITJoin SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___Wicket-develop mailing listWicket-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
Re: [Wicket-develop] localized attributes
You are mixing things here. Markup tags become component tags if they have a wicket:id. This is the only rule. because by default it doesn't have a wicket:id gets an id automatically (-xxx) assigned for the markup tag to become a component tags. The same happens to autolinks, etc and it happens at markup load time and hence just once per component *type*. While rendering a component *instance* the resolvers are applied and in case of a resolver could localize an attributes values. The resolver in these case would actually be independent from any component type as it would look for wicket:message in the current tag only and on the fly modify the attribute. Juergen On 9/19/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > On 9/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > We do that already in other cases. Make it an auto component and you > > can easily hook a resolver on it. > > That would only work for tags that are not component tags to begin. As > soon as you would decide to put wicket:id in it, it wouldn't go > through a component resolver and would thus not be processed, right? > > 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
Re: [Wicket-develop] localized attributes
On 9/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > We do that already in other cases. Make it an auto component and you > can easily hook a resolver on it. That would only work for tags that are not component tags to begin. As soon as you would decide to put wicket:id in it, it wouldn't go through a component resolver and would thus not be processed, right? 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
Re: [Wicket-develop] localized attributes
i thought you were talking about limiting tag which is on by default and im sure is used quiete often.-IgorOn 9/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: how many apps are using it? Isn't it still in experimental mode anddisabled by default.JuergenOn 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > too late now, that would break a lot of apps out there.>> -Igor On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED] > wrote:> >> May be should limit than to what wicket:message attribute> does.>> Juergen>> On 9/18/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:> > > b) wicket:message is deliberately limited in functionality to be fast> > > and simple to use. If you want more complex localization, go with any> > > of the other already available options. > >> > But I prefer consistence. It's kind of hard to explain imo, that a> > wicket:message attribute doesn't support the same messages as a> > wicket:message tag.> > > > Eelco> >> >> -> > Using Tomcat but need to do more? Need to support web services, security?> > Get stuff done quickly with pre-integrated technology to make your job > easier> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___> > Wicket-develop mailing list> > Wicket-develop@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/wicket-develop> >>> - >> Using Tomcat but need to do more? Need to support web services, security?> Get stuff done quickly with pre-integrated technology to make your job> easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___> Wicket-develop mailing list> Wicket-develop@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wicket-develop -> Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job> easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>> ___> Wicket-develop mailing list> Wicket-develop@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wicket-develop>>>- Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing listWicket-develop@lists.sourceforge.nethttps://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
Re: [Wicket-develop] localized attributes
is probably used a lot; it's really convenient. The wicket:message attribute probably not that much; you have to deliberately turn it on, and there's a big warning about it's experimental nature. Eelco On 9/18/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > how many apps are using it? Isn't it still in experimental mode and > disabled by default. > > Juergen > > On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > too late now, that would break a lot of apps out there. > > > > -Igor > > > > > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > > > May be should limit than to what wicket:message attribute > > does. > > > > Juergen > > > > On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > b) wicket:message is deliberately limited in functionality to be fast > > > > and simple to use. If you want more complex localization, go with any > > > > of the other already available options. > > > > > > But I prefer consistence. It's kind of hard to explain imo, that a > > > wicket:message attribute doesn't support the same messages as a > > > wicket:message tag. > > > > > > Eelco > > > > > > > > - > > > Using Tomcat but need to do more? Need to support web services, security? > > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ___ > > > Wicket-develop mailing list > > > Wicket-develop@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > - > > > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > - > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > > ___ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
Furthermore, now that I'm writing about it, I can actually see it is great functionality, and the complex lookup when can support on of it's biggest plusses. Eelco On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > too late now, that would break a lot of apps out there. > > -Igor > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > May be should limit than to what wicket:message attribute > does. > > > > Juergen > > > > On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > b) wicket:message is deliberately limited in functionality to be fast > > > > and simple to use. If you want more complex localization, go with any > > > > of the other already available options. > > > > > > But I prefer consistence. It's kind of hard to explain imo, that a > > > wicket:message attribute doesn't support the same messages as a > > > wicket:message tag. > > > > > > Eelco > > > > > > > - > > > Using Tomcat but need to do more? Need to support web services, > security? > > > Get stuff done quickly with pre-integrated technology to make your job > easier > > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ___ > > > Wicket-develop mailing list > > > Wicket-develop@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > - > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
how many apps are using it? Isn't it still in experimental mode and disabled by default. Juergen On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > too late now, that would break a lot of apps out there. > > -Igor > > > > On 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > May be should limit than to what wicket:message attribute > does. > > Juergen > > On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > b) wicket:message is deliberately limited in functionality to be fast > > > and simple to use. If you want more complex localization, go with any > > > of the other already available options. > > > > But I prefer consistence. It's kind of hard to explain imo, that a > > wicket:message attribute doesn't support the same messages as a > > wicket:message tag. > > > > Eelco > > > > > - > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > - > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
too late now, that would break a lot of apps out there.-IgorOn 9/18/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:May be should limit than to what wicket:message attribute does. JuergenOn 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > b) wicket:message is deliberately limited in functionality to be fast > > and simple to use. If you want more complex localization, go with any> > of the other already available options.>> But I prefer consistence. It's kind of hard to explain imo, that a > wicket:message attribute doesn't support the same messages as a> wicket:message tag.>> Eelco>> -> Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> ___> Wicket-develop mailing list> Wicket-develop@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wicket-develop>- Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing listWicket-develop@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-develop - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
May be should limit than to what wicket:message attribute does. Juergen On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > b) wicket:message is deliberately limited in functionality to be fast > > and simple to use. If you want more complex localization, go with any > > of the other already available options. > > But I prefer consistence. It's kind of hard to explain imo, that a > wicket:message attribute doesn't support the same messages as a > wicket:message tag. > > Eelco > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
> b) wicket:message is deliberately limited in functionality to be fast > and simple to use. If you want more complex localization, go with any > of the other already available options. But I prefer consistence. It's kind of hard to explain imo, that a wicket:message attribute doesn't support the same messages as a wicket:message tag. Eelco - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
We do that already in other cases. Make it an auto component and you can easily hook a resolver on it. The reason why I don't like it too much is because we a) adding even more transparent containers polluting the component hierarchy and just for a single attribute to be modified b) wicket:message is deliberately limited in functionality to be fast and simple to use. If you want more complex localization, go with any of the other already available options. Juergen On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Sounds good. > > Eelco > > On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > naah, just gen something unique > > > > the resolver can check the attributes to see if it needs to add the attrib > > modifier/create webmarkup container > > > > -Igor > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
Sounds good. Eelco On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > naah, just gen something unique > > the resolver can check the attributes to see if it needs to add the attrib > modifier/create webmarkup container > > -Igor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
naah, just gen something uniquethe resolver can check the attributes to see if it needs to add the attrib modifier/create webmarkup container-IgorOn 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Igor, you're smart as ever. We probably would need to add some specialid that can be recognized by the resolver, right?EelcoOn 9/18/06, Igor Vaynberg <[EMAIL PROTECTED] > wrote:> we might have to have the taghandler add a wicket:id attr if its not already> there, and have the resolver either create a webmarkup container and add an> attrib modifier to it, or just add an attrib modifier to the existing > component.>> -Igor On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> >> > I don't think that'll work. Remember the markup for a panel gets > > loaded only once no matter how often and where else the Panel is used.> > The component path is only true for the component which initially> > loads the markup but it is most likey wrong for all other panels of > > the same type.>> It needs to be done just once for every locale/ variant; after that> the cached markup is reused with the altered attributes, right?>> Eelco>> - > Using Tomcat but need to do more? Need to support web services, security?> Get stuff done quickly with pre-integrated technology to make your job> easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___> Wicket-develop mailing list> Wicket-develop@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wicket-develop>>> -> Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job> easier> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>> ___> Wicket-develop mailing list> Wicket-develop@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wicket-develop>>>- Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing listWicket-develop@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-develop - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
Igor, you're smart as ever. We probably would need to add some special id that can be recognized by the resolver, right? Eelco On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > we might have to have the taghandler add a wicket:id attr if its not already > there, and have the resolver either create a webmarkup container and add an > attrib modifier to it, or just add an attrib modifier to the existing > component. > > -Igor > > > > On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > I don't think that'll work. Remember the markup for a panel gets > > loaded only once no matter how often and where else the Panel is used. > > The component path is only true for the component which initially > > loads the markup but it is most likey wrong for all other panels of > > the same type. > > It needs to be done just once for every locale/ variant; after that > the cached markup is reused with the altered attributes, right? > > Eelco > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
So the other option would be to use component resolvers. Which like you said would only work for tags with wicket:id/ wicket:foo. Would it be hard to change the parsing process so that tags with wicket:message will be read as ComponentTag, even if they are not part of wrote: > > I don't think that'll work. Remember the markup for a panel gets > > loaded only once no matter how often and where else the Panel is used. > > The component path is only true for the component which initially > > loads the markup but it is most likey wrong for all other panels of > > the same type. > > It needs to be done just once for every locale/ variant; after that > the cached markup is reused with the altered attributes, right? > > Eelco > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
we might have to have the taghandler add a wicket:id attr if its not already there, and have the resolver either create a webmarkup container and add an attrib modifier to it, or just add an attrib modifier to the existing component. -IgorOn 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I don't think that'll work. Remember the markup for a panel gets> loaded only once no matter how often and where else the Panel is used.> The component path is only true for the component which initially > loads the markup but it is most likey wrong for all other panels of> the same type.It needs to be done just once for every locale/ variant; after thatthe cached markup is reused with the altered attributes, right? Eelco-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___Wicket-develop mailing listWicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
> I don't think that'll work. Remember the markup for a panel gets > loaded only once no matter how often and where else the Panel is used. > The component path is only true for the component which initially > loads the markup but it is most likey wrong for all other panels of > the same type. It needs to be done just once for every locale/ variant; after that the cached markup is reused with the altered attributes, right? Eelco - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
On 9/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > WicketMessageTaghandler didn't need (I didn't look at the new code > > yet) to know the component and the stack yet, as the properties were > > assumed to be either in the corresponding properties file or the apps > > properties file. Which is properly the limitation Eelco was talking > > about. > > Yeah, that's the limitation I'm talking about. So has > a full search stack while has not. I got > around that by finding the proper component by doing a lookup through > the component path, which I think should always succeed, as the call > to create the container info (where the path is stored) and the call > to WicketMessageTaghandler happens in the same request. It's a bit > hackish, but it seems to work and doesn't break the API. > I don't think that'll work. Remember the markup for a panel gets loaded only once no matter how often and where else the Panel is used. The component path is only true for the component which initially loads the markup but it is most likey wrong for all other panels of the same type. Juergen > Eelco > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
> WicketMessageTaghandler didn't need (I didn't look at the new code > yet) to know the component and the stack yet, as the properties were > assumed to be either in the corresponding properties file or the apps > properties file. Which is properly the limitation Eelco was talking > about. Yeah, that's the limitation I'm talking about. So has a full search stack while has not. I got around that by finding the proper component by doing a lookup through the component path, which I think should always succeed, as the call to create the container info (where the path is stored) and the call to WicketMessageTaghandler happens in the same request. It's a bit hackish, but it seems to work and doesn't break the API. Eelco - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
The markup handler are called just once when the markup is loaded. If you have 2 or more components of the same type, the markup will still only be loaded once and hence the markup handler only be called once. Markup Handlers are the wrong place to do it. In 1.2 (and 2.0) we have resolvers to do similar work, though they work on wicket:id and wicket:xxx (which means a corresponding component must exist). If neither of both is present, than the resolver won't be able to handle it. WicketMessageTaghandler didn't need (I didn't look at the new code yet) to know the component and the stack yet, as the properties were assumed to be either in the corresponding properties file or the apps properties file. Which is properly the limitation Eelco was talking about. Juergen On 9/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > it would be cool if the tag handler can somehow add an attribute modifier to > the created component, that would solve all these problems. but i guess its > not exactly how it works right now :) > > -Igor > > > > On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > WicketMessageTagHandler is pretty limited currently, with only the the > > component initiating the markup loading in the search stack. I fixed > > this for 2.0 by setting the component path and later using that > > component path to resolve the component again. I think this shouldn't > > be a problem as passing that container and filtering the content > > would be done very shortly after each other, without the possibility > > of the original component being replaced (which would result in the > > path resolving to the wrong component). But if I overlooked something, > > please tell. > > > > I'm not sure if we can do this for 1.2 though, as markup loading can > > be triggered from many locations, including during construction time, > > meaning that we wouldn't have enough information to resolve the > > component. If we don't find a solution, we should consider removing > > WicketMessageTagHandler from 1.2 altogether imo, as it is so limited. > > > > Another issue is that reloading of messagebundles have no effect. I > > guess that would be very hard to workaround for? > > > > Another thing I noticed is that when I load another version of the > > markup, e.g. when switching the locale, the filter applies the changes > > but somehow the older markup is used as long as I render the same > > component instance. Any idea how that might happen? > > > > Eelco > > > > > > On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > Ah, forget it. I just found out about the experimental tag handler > > > Juergen put committed. I'll look at that now. > > > > > > Eelco > > > > > > > > > On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > We had a discussion and a vote on localized attributes some time ago: > > > > > http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5637727 > > > > > > > > Seems that most people voted for > > > > > > > > 2) wicket:message="value:my_key"/> > > > > > > > > Though it was also mentioned we could support both cases but advertise > just one. > > > > > > > > There is no feature request for this yet and it doesn't seem to be > > > > implemented either, is that correct? > > > > > > > > I'm writing a section about localization now, so if we're gonna have > > > > this feature, and it's not too difficult to implement, I could write > > > > about it, provided it would be implemented soon (like this week). > > > > > > > > Thoughts? > > > > > > > > Eelco > > > > > > > > > > > > - > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > > Wicket-develop mailing list > > Wicket-develop@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ___ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Ap
Re: [Wicket-develop] localized attributes
it would be cool if the tag handler can somehow add an attribute modifier to the created component, that would solve all these problems. but i guess its not exactly how it works right now :)-Igor On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: WicketMessageTagHandler is pretty limited currently, with only the thecomponent initiating the markup loading in the search stack. I fixedthis for 2.0 by setting the component path and later using thatcomponent path to resolve the component again. I think this shouldn't be a problem as passing that container and filtering the contentwould be done very shortly after each other, without the possibilityof the original component being replaced (which would result in thepath resolving to the wrong component). But if I overlooked something, please tell.I'm not sure if we can do this for 1.2 though, as markup loading canbe triggered from many locations, including during construction time,meaning that we wouldn't have enough information to resolve the component. If we don't find a solution, we should consider removingWicketMessageTagHandler from 1.2 altogether imo, as it is so limited.Another issue is that reloading of messagebundles have no effect. I guess that would be very hard to workaround for?Another thing I noticed is that when I load another version of themarkup, e.g. when switching the locale, the filter applies the changesbut somehow the older markup is used as long as I render the same component instance. Any idea how that might happen?EelcoOn 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> Ah, forget it. I just found out about the experimental tag handler > Juergen put committed. I'll look at that now.>> Eelco>>> On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:> > We had a discussion and a vote on localized attributes some time ago: > > http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5637727> > > > Seems that most people voted for> >> > 2) > >> > Though it was also mentioned we could support both cases but advertise just one. > >> > There is no feature request for this yet and it doesn't seem to be> > implemented either, is that correct?> >> > I'm writing a section about localization now, so if we're gonna have > > this feature, and it's not too difficult to implement, I could write> > about it, provided it would be implemented soon (like this week).> >> > Thoughts?> >> > Eelco > >>-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___Wicket-develop mailing listWicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
WicketMessageTagHandler is pretty limited currently, with only the the component initiating the markup loading in the search stack. I fixed this for 2.0 by setting the component path and later using that component path to resolve the component again. I think this shouldn't be a problem as passing that container and filtering the content would be done very shortly after each other, without the possibility of the original component being replaced (which would result in the path resolving to the wrong component). But if I overlooked something, please tell. I'm not sure if we can do this for 1.2 though, as markup loading can be triggered from many locations, including during construction time, meaning that we wouldn't have enough information to resolve the component. If we don't find a solution, we should consider removing WicketMessageTagHandler from 1.2 altogether imo, as it is so limited. Another issue is that reloading of messagebundles have no effect. I guess that would be very hard to workaround for? Another thing I noticed is that when I load another version of the markup, e.g. when switching the locale, the filter applies the changes but somehow the older markup is used as long as I render the same component instance. Any idea how that might happen? Eelco On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Ah, forget it. I just found out about the experimental tag handler > Juergen put committed. I'll look at that now. > > Eelco > > > On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > We had a discussion and a vote on localized attributes some time ago: > > http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5637727 > > > > Seems that most people voted for > > > > 2) > wicket:message="value:my_key"/> > > > > Though it was also mentioned we could support both cases but advertise just > > one. > > > > There is no feature request for this yet and it doesn't seem to be > > implemented either, is that correct? > > > > I'm writing a section about localization now, so if we're gonna have > > this feature, and it's not too difficult to implement, I could write > > about it, provided it would be implemented soon (like this week). > > > > Thoughts? > > > > Eelco > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
Re: [Wicket-develop] localized attributes
Ah, forget it. I just found out about the experimental tag handler Juergen put committed. I'll look at that now. Eelco On 9/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > We had a discussion and a vote on localized attributes some time ago: > http://www.nabble.com/VOTE%3A-how-should-localized-attributes-work--tf2047179.html#a5637727 > > Seems that most people voted for > > 2) > > Though it was also mentioned we could support both cases but advertise just > one. > > There is no feature request for this yet and it doesn't seem to be > implemented either, is that correct? > > I'm writing a section about localization now, so if we're gonna have > this feature, and it's not too difficult to implement, I could write > about it, provided it would be implemented soon (like this week). > > Thoughts? > > Eelco > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
