subject:"Re\: \[Wicket\-user\] Localization"


It will not be previeable any more.

Juergen

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:

why not a format like this

input type=submit value=wicket:i18n:buttons.save/

or

input type=submit value=wi18n:buttons.save/

-Igor



On 5/8/06, Andrew Berman [EMAIL PROTECTED] wrote:

 Hey Guys,

 I think adding something to support localized attributes would be a big
plus.  I know that when Wicket added wicket:message it really saved a lot of
extra Java code on my part.  I think the same thing would happen if we came
up with something to do it in attributes.  AttributeModifiers obviously
work, but when you have a lot of things you want to localize on the same
page it's a lot of extra Java code that needs to be written to support this
because you need to add the specific Component and add an AttributeModifier.

 What about a compromise?  I think the experimental stuff in
WicketMessageTagHandler is cumbersome to add to the HTML, so what if we
created a component whose sole purpose is to add attributes to some HTML
element.  Or can this already be done like this:

 Java:
 add(new WebComponent(imageAlt).add(new
AttributeModifier(alt, true, new ResourceModel(my.key;

 HTML:
 img wicket:id=imageAlt src=mySrc /

 I haven't tested if this works, but if not, maybe some kind of Component
could be created which allows something like this.  It will allow for
multiple attributes to be replaced as well.

 Thoughts?


 --Andrew



 On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED] wrote:
  On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
   Hi Juergen,
  
please see WicketMessageTagHandler.java. It is experimental only and
disabled by default. Reason: it is realy ugly to have something like
wicket:example=tag=key. AttributeModifier are much more convinent
and far less ugly, IMO.
   if you have a page with like, say, 20 labels with static text (like
   you have sometimes in complex forms for explaining things) I don't see
   something to win by adding AttributeModifiers to the component tree. I
   see localization of static text as markup issue because there is
   almost no logic to define there. The format you described is rather
   ugly, that's right: What about:
   div wicket:message=blaLabelbla/div (if you want
to go the
   message as text between the tags)
 
  this is wicket:message
value=xxxdefault/wicket:message and
  already available.
 
   input type=submit wicket:message:value=Do something/ (for
   localizing the attribute value, probably the second : is not valid xml
   any more, but another separation char like _ or  maybe no separation
   char at all could be used)
  
 
  It is all not realy nice, isn't it? That is what we struggled with. We
  didn't find a syntax which we realy liked and which is standards
  compliant (e.g. XML namespace, schema).
 
   This would be very helpful for quick  easy localization of static
   content in pages, something that's missing at the moment from my point
   of view. Tell me what you think, if I have time I would like to
   implement this and contribute it...
  
 
  your help is very much appreciated but the syntax should be right.
 
That is default. Localizer implements a search hierarchy up the
component tree. You only need one properties files per language per
Panel which contains X number of component. Thinking ... That is not
your question, isn't it? Like Application.properties is the last
resort for all messages, you ask for one per java package, right?
So,
in addition to the my.pkg.MyPanel.properties it should look in
my/pkg/Wicket.properties as well (may be Wicket.properties is not
the
best name).
   That's what I want to do and it would be a nice feature if such a
   lookup strategy could be added by just setting an option and defining
   a name for the property file. I tried to do it quick myself but
   stopped after finding out that the property file name is quite tightly
   coupled to some class name for the moment...
  
 
  It is fairly easy to add. Please see
Settings.addStringResourceLoader,
  Application.getResourceStreamLocator and
  CompoundResourceStreamLocator.java
 
  Let me know if you need any more help
 
  Juergen
 
   Regards,
   Ralf
  
  
  
---
   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?cmdlnkkid0709bid3057dat1642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
  ---
  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

Re: [Wicket-user] Localization

2006-05-09 Thread Martijn Dashorst

This component is already there:new WebMarkupContainer(imageAlt).add(new AttributeModifier(alt, true, new Resource...):-)MartijnOn 5/9/06,
Andrew Berman [EMAIL PROTECTED] wrote:
Hey Guys,I think adding something to support localized attributes would be a big plus. I know that when Wicket added wicket:message it really saved a lot of extra Java code on my part. I think the same thing would happen if we came up with something to do it in attributes. AttributeModifiers obviously work, but when you have a lot of things you want to localize on the same page it's a lot of extra Java code that needs to be written to support this because you need to add the specific Component and add an AttributeModifier.
What about a compromise? I think the experimental stuff in WicketMessageTagHandler is cumbersome to add to the HTML, so what if we created a component whose sole purpose is to add attributes to some HTML element. Or can this already be done like this:
Java:add(new WebComponent(imageAlt).add(new AttributeModifier(alt, true, new ResourceModel(my.key;HTML:img wicket:id=imageAlt src="" /
I haven't tested if this works, but if not, maybe some kind of Component could be created which allows something like this. It will allow for multiple attributes to be replaced as well.Thoughts?
--Andrew
On 5/4/06, Juergen Donnerstag
[EMAIL PROTECTED] wrote:
On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote: Hi Juergen, please see
WicketMessageTagHandler.java. It is experimental only and disabled by default. Reason: it is realy ugly to have something like
wicket:example=tag=key. AttributeModifier are much more convinent and far less ugly, IMO. if you have a page with like, say, 20 labels with static text (like you have sometimes in complex forms for explaining things) I don't see
something to win by adding AttributeModifiers to the component tree. I see localization of static text as markup issue because there is almost no logic to define there. The format you described is rather
ugly, that's right: What about: div wicket:message=blaLabelbla/div (if you want to go the message as text between the tags)this is wicket:message value=xxxdefault/wicket:message and
already available. input type=submit wicket:message:value=Do something/ (for localizing the attribute value, probably the second : is not valid xml any more, but another separation char like _ ormaybe no separation
char at all could be used)It is all not realy nice, isn't it? That is what we struggled with. Wedidn't find a syntax which we realy liked and which is standardscompliant (e.g. XML namespace, schema).
This would be very helpful for quick easy localization of static content in pages, something that's missing at the moment from my point of view. Tell me what you think, if I have time I would like to
implement this and contribute it...your help is very much appreciated but the syntax should be right. That is default. Localizer implements a search hierarchy up the component tree. You only need one properties files per language per
Panel which contains X number of component. Thinking ... That is not your question, isn't it? Like Application.properties is the last resort for all messages, you ask for one per java package, right? So,
in addition to the my.pkg.MyPanel.properties it should look in my/pkg/Wicket.properties as well (may be Wicket.properties is not the best name). That's what I want to do and it would be a nice feature if such a
lookup strategy could be added by just setting an option and defining a name for the property file. I tried to do it quick myself but stopped after finding out that the property file name is quite tightly
coupled to some class name for the moment...It is fairly easy to add. Please see Settings.addStringResourceLoader,Application.getResourceStreamLocator andCompoundResourceStreamLocator.java

Let me know if you need any more helpJuergen Regards, Ralf --- 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?cmdlnkkid0709bid3057dat1642 ___ Wicket-user mailing list

Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
---
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?cmdlnkkid0709bid3057dat1642
___
Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-- Wicket 1.2 is coming! Write Ajax applications without

Re: [Wicket-user] Localization

why not? in a preview you would get a button with text wicket:i18n:buttons.savethats good for preview since you can see the key!-IgorOn 5/8/06,
Juergen Donnerstag [EMAIL PROTECTED] wrote:
It will not be previeable any more.JuergenOn 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: why not a format like this input type=submit value=wicket:i18n:
buttons.save/ or input type=submit value=wi18n:buttons.save/ -Igor On 5/8/06, Andrew Berman
[EMAIL PROTECTED] wrote: Hey Guys, I think adding something to support localized attributes would be a big plus.I know that when Wicket added wicket:message it really saved a lot of
extra Java code on my part.I think the same thing would happen if we came up with something to do it in attributes.AttributeModifiers obviously work, but when you have a lot of things you want to localize on the same
page it's a lot of extra Java code that needs to be written to support this because you need to add the specific Component and add an AttributeModifier. What about a compromise?I think the experimental stuff in
WicketMessageTagHandler is cumbersome to add to the HTML, so what if we created a component whose sole purpose is to add attributes to some HTML element.Or can this already be done like this:
Java: add(new WebComponent(imageAlt).add(new AttributeModifier(alt, true, new ResourceModel(my.key; HTML: img wicket:id=imageAlt src="" /
I haven't tested if this works, but if not, maybe some kind of Component could be created which allows something like this.It will allow for multiple attributes to be replaced as well.
Thoughts?--Andrew On 5/4/06, Juergen Donnerstag [EMAIL PROTECTED]
wrote: On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:Hi Juergen,please see
WicketMessageTagHandler.java. It is experimental only and disabled by default. Reason: it is realy ugly to have something like wicket:example=tag=key. AttributeModifier are much more convinent
and far less ugly, IMO.if you have a page with like, say, 20 labels with static text (likeyou have sometimes in complex forms for explaining things) I don't see
something to win by adding AttributeModifiers to the component tree. Isee localization of static text as markup issue because there isalmost no logic to define there. The format you described is rather
ugly, that's right: What about:div wicket:message=blaLabelbla/div (if you want to go themessage as text between the tags)
this is wicket:message value=xxxdefault/wicket:message and already available. input type=submit wicket:message:value=Do something/ (for
localizing the attribute value, probably the second : is not valid xmlany more, but another separation char like _ ormaybe no separationchar at all could be used)
It is all not realy nice, isn't it? That is what we struggled with. We didn't find a syntax which we realy liked and which is standards compliant (
e.g. XML namespace, schema). This would be very helpful for quick easy localization of staticcontent in pages, something that's missing at the moment from my point
of view. Tell me what you think, if I have time I would like toimplement this and contribute it...your help is very much appreciated but the syntax should be right.
That is default. Localizer implements a search hierarchy up the component tree. You only need one properties files per language per Panel which contains X number of component. Thinking ... That is not
your question, isn't it? Like Application.properties is the last resort for all messages, you ask for one per java package, right? So, in addition to the
my.pkg.MyPanel.properties it should look in my/pkg/Wicket.properties as well (may be Wicket.properties is not the best name).That's what I want to do and it would be a nice feature if such a
lookup strategy could be added by just setting an option and defininga name for the property file. I tried to do it quick myself butstopped after finding out that the property file name is quite tightly
coupled to some class name for the moment...It is fairly easy to add. Please see Settings.addStringResourceLoader,
Application.getResourceStreamLocator and CompoundResourceStreamLocator.java Let me know if you need any more help Juergen
Regards,Ralf ---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?cmdlnkkid0709bid3057dat1642___
Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


I guess it depends on what job you are in. It is nice for the person
who has to maintain the properties. If I were a html designer I'd
rather prefer a default text like save or whatever, which btw
applies if no property is found.

Juergen

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:

why not? in a preview you would get a button with text
wicket:i18n:buttons.save

thats good for preview since you can see the key!

-Igor



On 5/8/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
 It will not be previeable any more.

 Juergen

 On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
  why not a format like this
 
  input type=submit value=wicket:i18n: buttons.save/
 
  or
 
  input type=submit value=wi18n:buttons.save/
 
  -Igor
 
 
 
  On 5/8/06, Andrew Berman  [EMAIL PROTECTED] wrote:
  
   Hey Guys,
  
   I think adding something to support localized attributes would be a
big
  plus.  I know that when Wicket added wicket:message it really saved a
lot of
  extra Java code on my part.  I think the same thing would happen if we
came
  up with something to do it in attributes.  AttributeModifiers obviously
  work, but when you have a lot of things you want to localize on the same
  page it's a lot of extra Java code that needs to be written to support
this
  because you need to add the specific Component and add an
AttributeModifier.
  
   What about a compromise?  I think the experimental stuff in
  WicketMessageTagHandler is cumbersome to add to the HTML, so what if we
  created a component whose sole purpose is to add attributes to some HTML
  element.  Or can this already be done like this:
  
   Java:
   add(new WebComponent(imageAlt).add(new
  AttributeModifier(alt, true, new ResourceModel(my.key;
  
   HTML:
   img wicket:id=imageAlt src=mySrc /
  
   I haven't tested if this works, but if not, maybe some kind of
Component
  could be created which allows something like this.  It will allow for
  multiple attributes to be replaced as well.
  
   Thoughts?
  
  
   --Andrew
  
  
  
   On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED]  wrote:
On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
 Hi Juergen,

  please see WicketMessageTagHandler.java. It is experimental only
and
  disabled by default. Reason: it is realy ugly to have something
like
  wicket:example=tag=key. AttributeModifier are much more
convinent
  and far less ugly, IMO.
 if you have a page with like, say, 20 labels with static text
(like
 you have sometimes in complex forms for explaining things) I don't
see
 something to win by adding AttributeModifiers to the component
tree. I
 see localization of static text as markup issue because there is
 almost no logic to define there. The format you described is
rather
 ugly, that's right: What about:
 div wicket:message=blaLabelbla/div (if you
want
  to go the
 message as text between the tags)
   
this is wicket:message
  value=xxxdefault/wicket:message and
already available.
   
 input type=submit wicket:message:value=Do something/ (for
 localizing the attribute value, probably the second : is not valid
xml
 any more, but another separation char like _ or  maybe no
separation
 char at all could be used)

   
It is all not realy nice, isn't it? That is what we struggled with.
We
didn't find a syntax which we realy liked and which is standards
compliant ( e.g. XML namespace, schema).
   
 This would be very helpful for quick  easy localization of static
 content in pages, something that's missing at the moment from my
point
 of view. Tell me what you think, if I have time I would like to
 implement this and contribute it...

   
your help is very much appreciated but the syntax should be right.
   
  That is default. Localizer implements a search hierarchy up the
  component tree. You only need one properties files per language
per
  Panel which contains X number of component. Thinking ... That is
not
  your question, isn't it? Like Application.properties is the last
  resort for all messages, you ask for one per java package,
right?
  So,
  in addition to the my.pkg.MyPanel.properties it should look in
  my/pkg/Wicket.properties as well (may be Wicket.properties is
not
  the
  best name).
 That's what I want to do and it would be a nice feature if such a
 lookup strategy could be added by just setting an option and
defining
 a name for the property file. I tried to do it quick myself but
 stopped after finding out that the property file name is quite
tightly
 coupled to some class name for the moment...

   
It is fairly easy to add. Please see
  Settings.addStringResourceLoader,
Application.getResourceStreamLocator and
CompoundResourceStreamLocator.java
   
Let me know if you need any more help
   
Juergen
   
 Regards,
 Ralf

Re: [Wicket-user] Localization


It'll give people choice though. Not everyone cares about
previewability in the same fashion.

Eelco


On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:

I guess it depends on what job you are in. It is nice for the person
who has to maintain the properties. If I were a html designer I'd
rather prefer a default text like save or whatever, which btw
applies if no property is found.

Juergen

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
 why not? in a preview you would get a button with text
 wicket:i18n:buttons.save

 thats good for preview since you can see the key!

 -Igor



 On 5/8/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
  It will not be previeable any more.
 
  Juergen
 
  On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
   why not a format like this
  
   input type=submit value=wicket:i18n: buttons.save/
  
   or
  
   input type=submit value=wi18n:buttons.save/
  
   -Igor
  
  
  
   On 5/8/06, Andrew Berman  [EMAIL PROTECTED] wrote:
   
Hey Guys,
   
I think adding something to support localized attributes would be a
 big
   plus.  I know that when Wicket added wicket:message it really saved a
 lot of
   extra Java code on my part.  I think the same thing would happen if we
 came
   up with something to do it in attributes.  AttributeModifiers obviously
   work, but when you have a lot of things you want to localize on the same
   page it's a lot of extra Java code that needs to be written to support
 this
   because you need to add the specific Component and add an
 AttributeModifier.
   
What about a compromise?  I think the experimental stuff in
   WicketMessageTagHandler is cumbersome to add to the HTML, so what if we
   created a component whose sole purpose is to add attributes to some HTML
   element.  Or can this already be done like this:
   
Java:
add(new WebComponent(imageAlt).add(new
   AttributeModifier(alt, true, new ResourceModel(my.key;
   
HTML:
img wicket:id=imageAlt src=mySrc /
   
I haven't tested if this works, but if not, maybe some kind of
 Component
   could be created which allows something like this.  It will allow for
   multiple attributes to be replaced as well.
   
Thoughts?
   
   
--Andrew
   
   
   
On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED]  wrote:
 On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
  Hi Juergen,
 
   please see WicketMessageTagHandler.java. It is experimental only
 and
   disabled by default. Reason: it is realy ugly to have something
 like
   wicket:example=tag=key. AttributeModifier are much more
 convinent
   and far less ugly, IMO.
  if you have a page with like, say, 20 labels with static text
 (like
  you have sometimes in complex forms for explaining things) I don't
 see
  something to win by adding AttributeModifiers to the component
 tree. I
  see localization of static text as markup issue because there is
  almost no logic to define there. The format you described is
 rather
  ugly, that's right: What about:
  div wicket:message=blaLabelbla/div (if you
 want
   to go the
  message as text between the tags)

 this is wicket:message
   value=xxxdefault/wicket:message and
 already available.

  input type=submit wicket:message:value=Do something/ (for
  localizing the attribute value, probably the second : is not valid
 xml
  any more, but another separation char like _ or  maybe no
 separation
  char at all could be used)
 

 It is all not realy nice, isn't it? That is what we struggled with.
 We
 didn't find a syntax which we realy liked and which is standards
 compliant ( e.g. XML namespace, schema).

  This would be very helpful for quick  easy localization of static
  content in pages, something that's missing at the moment from my
 point
  of view. Tell me what you think, if I have time I would like to
  implement this and contribute it...
 

 your help is very much appreciated but the syntax should be right.

   That is default. Localizer implements a search hierarchy up the
   component tree. You only need one properties files per language
 per
   Panel which contains X number of component. Thinking ... That is
 not
   your question, isn't it? Like Application.properties is the last
   resort for all messages, you ask for one per java package,
 right?
   So,
   in addition to the my.pkg.MyPanel.properties it should look in
   my/pkg/Wicket.properties as well (may be Wicket.properties is
 not
   the
   best name).
  That's what I want to do and it would be a nice feature if such a
  lookup strategy could be added by just setting an option and
 defining
  a name for the property file. I tried to do it quick myself but
  stopped after finding out that the property file name is quite
 tightly
  coupled to some class name for the moment...
 

 It is fairly

Re: [Wicket-user] Localization

the problem i see is are we going to check every tag's attribute (wicket component or not) for such a thing? And if it is not a wicket component we make it a special (none raw markup) tag?and if it is a wicket component already we just put a special object in the tags attributes?
johanOn 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It'll give people choice though. Not everyone cares aboutpreviewability in the same fashion.EelcoOn 5/9/06, Juergen Donnerstag [EMAIL PROTECTED]
wrote: I guess it depends on what job you are in. It is nice for the person who has to maintain the properties. If I were a html designer I'd rather prefer a default text like save or whatever, which btw
applies if no property is found. Juergen On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: why not? in a preview you would get a button with text
wicket:i18n:buttons.save thats good for preview since you can see the key! -Igor On 5/8/06, Juergen Donnerstag
[EMAIL PROTECTED] wrote: It will not be previeable any more. Juergen On 5/9/06, Igor Vaynberg
[EMAIL PROTECTED] wrote:why not a format like this input type=submit value=wicket:i18n:
buttons.save/ or input type=submit value=wi18n:buttons.save/
-Igor On 5/8/06, Andrew Berman [EMAIL PROTECTED] wrote:
Hey Guys, I think adding something to support localized attributes would be a bigplus.I know that when Wicket added wicket:message it really saved a
lot ofextra Java code on my part.I think the same thing would happen if we cameup with something to do it in attributes.AttributeModifiers obviously
work, but when you have a lot of things you want to localize on the samepage it's a lot of extra Java code that needs to be written to support thisbecause you need to add the specific Component and add an
AttributeModifier. What about a compromise?I think the experimental stuff inWicketMessageTagHandler is cumbersome to add to the HTML, so what if we
created a component whose sole purpose is to add attributes to some HTMLelement.Or can this already be done like this: Java:
add(new WebComponent(imageAlt).add(newAttributeModifier(alt, true, new ResourceModel(my.key; HTML:
img wicket:id=imageAlt src="" / I haven't tested if this works, but if not, maybe some kind of Component
could be created which allows something like this.It will allow formultiple attributes to be replaced as well. Thoughts?
--Andrew On 5/4/06, Juergen Donnerstag
[EMAIL PROTECTED] wrote: On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
Hi Juergen, please see WicketMessageTagHandler.java. It is experimental only anddisabled by default. Reason: it is realy ugly to have something
likewicket:example=tag=key. AttributeModifier are much more convinentand far less ugly, IMO.
if you have a page with like, say, 20 labels with static text (like you have sometimes in complex forms for explaining things) I don't
see something to win by adding AttributeModifiers to the component tree. I see localization of static text as markup issue because there is
almost no logic to define there. The format you described is rather ugly, that's right: What about: div wicket:message=blaLabelbla/div (if you
wantto go the message as text between the tags) this is wicket:messagevalue=xxxdefault/wicket:message and
already available.input type=submit wicket:message:value=Do something/ (for localizing the attribute value, probably the second : is not valid
xml any more, but another separation char like _ ormaybe no separation char at all could be used)
It is all not realy nice, isn't it? That is what we struggled with. We didn't find a syntax which we realy liked and which is standards
compliant ( e.g. XML namespace, schema).This would be very helpful for quick easy localization of static content in pages, something that's missing at the moment from my
point of view. Tell me what you think, if I have time I would like to implement this and contribute it...
your help is very much appreciated but the syntax should be right. That is default. Localizer implements a search hierarchy up the
component tree. You only need one properties files per language perPanel which contains X number of component. Thinking ... That is
notyour question, isn't it? Like Application.properties is the lastresort for all messages, you ask for one per java package,
right?So,in addition to the my.pkg.MyPanel.properties it should look inmy/pkg/Wicket.properties as well (may be
Wicket.properties is notthebest name). That's what I want to do

Re: [Wicket-user] Localization


Or we use one of these post-processing filters. That way components
might even clear them or insert new ones, and only the resulting
markup will be processed.

Eelco


On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:

the problem i see is are we going to check every tag's attribute (wicket
component or not) for such a thing?

And if it is not a wicket component we make it a special (none raw markup)
tag?
and if it is a wicket component already we just put a special object in the
tags attributes?

johan



On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 It'll give people choice though. Not everyone cares about
 previewability in the same fashion.

 Eelco


 On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED]  wrote:
  I guess it depends on what job you are in. It is nice for the person
  who has to maintain the properties. If I were a html designer I'd
  rather prefer a default text like save or whatever, which btw
  applies if no property is found.
 
  Juergen
 
  On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
   why not? in a preview you would get a button with text
   wicket:i18n:buttons.save
  
   thats good for preview since you can see the key!
  
   -Igor
  
  
  
   On 5/8/06, Juergen Donnerstag  [EMAIL PROTECTED] wrote:
It will not be previeable any more.
   
Juergen
   
On 5/9/06, Igor Vaynberg  [EMAIL PROTECTED] wrote:
 why not a format like this

 input type=submit value=wicket:i18n: buttons.save/

 or

 input type=submit value=wi18n:buttons.save/

 -Igor



 On 5/8/06, Andrew Berman  [EMAIL PROTECTED] wrote:
 
  Hey Guys,
 
  I think adding something to support localized attributes would
be a
   big
 plus.  I know that when Wicket added wicket:message it really
saved a
   lot of
 extra Java code on my part.  I think the same thing would happen
if we
   came
 up with something to do it in attributes.  AttributeModifiers
obviously
 work, but when you have a lot of things you want to localize on
the same
 page it's a lot of extra Java code that needs to be written to
support
   this
 because you need to add the specific Component and add an
   AttributeModifier.
 
  What about a compromise?  I think the experimental stuff in
 WicketMessageTagHandler is cumbersome to add to the HTML, so what
if we
 created a component whose sole purpose is to add attributes to
some HTML
 element.  Or can this already be done like this:
 
  Java:
  add(new WebComponent(imageAlt).add(new
 AttributeModifier(alt, true, new ResourceModel(my.key;
 
  HTML:
  img wicket:id=imageAlt src=mySrc /
 
  I haven't tested if this works, but if not, maybe some kind of
   Component
 could be created which allows something like this.  It will allow
for
 multiple attributes to be replaced as well.
 
  Thoughts?
 
 
  --Andrew
 
 
 
  On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED] 
wrote:
   On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
Hi Juergen,
   
 please see WicketMessageTagHandler.java. It is
experimental only
   and
 disabled by default. Reason: it is realy ugly to have
something
   like
 wicket:example=tag=key. AttributeModifier are much more
   convinent
 and far less ugly, IMO.
if you have a page with like, say, 20 labels with static
text
   (like
you have sometimes in complex forms for explaining things) I
don't
   see
something to win by adding AttributeModifiers to the
component
   tree. I
see localization of static text as markup issue because
there is
almost no logic to define there. The format you described is
   rather
ugly, that's right: What about:
div wicket:message=blaLabelbla/div
(if you
   want
 to go the
message as text between the tags)
  
   this is wicket:message
 value=xxxdefault/wicket:message and
   already available.
  
input type=submit wicket:message:value=Do something/
(for
localizing the attribute value, probably the second : is not
valid
   xml
any more, but another separation char like _ or  maybe no
   separation
char at all could be used)
   
  
   It is all not realy nice, isn't it? That is what we struggled
with.
   We
   didn't find a syntax which we realy liked and which is
standards
   compliant ( e.g. XML namespace, schema).
  
This would be very helpful for quick  easy localization of
static
content in pages, something that's missing at the moment
from my
   point
of view. Tell me what you think, if I have time I would like
to
implement this and contribute it...
   
  
   your help is very much appreciated but the syntax should be
right.
  
 That is default. Localizer implements a search hierarchy
up the
 component tree.

Re: [Wicket-user] Localization


We do something similar for autolinks already. Actually I think there
at least 3 solutions:
1) If no wicket:id is present than replace the attribute on the fly
and add it to the markup stream as if it were RawMarkup. Con: changes
to the properties at runtime are not taken into account. Tags with
wicket:id are treated as below.
2) Automatically create a WebMarkupContainer for all tags without
wicket:id but with such attributes and auto-attach an
AttributeModifier. If wicket:id already exists, than auto-attach the
AttributeModifier to the already existing component. Con: you
auto-create plenty more Containers and the debug page is filled with
automatically created components.
3) A 3rd option could by an OutputTransformer kind of
Component/Behavior which simply ignores the html/xml structure and
search  replaces the attributes in the output string. Something like
s/w18n:([w+\.])/${getString($1)/g  (pseudo code only). The
properties file of course could only be with the the transformer or
any container up the hierarchy. Currently I like this idea most. In
most scenarios (RESPONSE_BUFFER) we cache the output string already.
We'd simply kind of post process the output. Might as well be more
efficient (performance and memory) than any of the other solutions.

Juergen

On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:

the problem i see is are we going to check every tag's attribute (wicket
component or not) for such a thing?

And if it is not a wicket component we make it a special (none raw markup)
tag?
and if it is a wicket component already we just put a special object in the
tags attributes?

johan



On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 It'll give people choice though. Not everyone cares about
 previewability in the same fashion.

 Eelco


 On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED]  wrote:
  I guess it depends on what job you are in. It is nice for the person
  who has to maintain the properties. If I were a html designer I'd
  rather prefer a default text like save or whatever, which btw
  applies if no property is found.
 
  Juergen
 
  On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
   why not? in a preview you would get a button with text
   wicket:i18n:buttons.save
  
   thats good for preview since you can see the key!
  
   -Igor
  
  
  
   On 5/8/06, Juergen Donnerstag  [EMAIL PROTECTED] wrote:
It will not be previeable any more.
   
Juergen
   
On 5/9/06, Igor Vaynberg  [EMAIL PROTECTED] wrote:
 why not a format like this

 input type=submit value=wicket:i18n: buttons.save/

 or

 input type=submit value=wi18n:buttons.save/

 -Igor



 On 5/8/06, Andrew Berman  [EMAIL PROTECTED] wrote:
 
  Hey Guys,
 
  I think adding something to support localized attributes would
be a
   big
 plus.  I know that when Wicket added wicket:message it really
saved a
   lot of
 extra Java code on my part.  I think the same thing would happen
if we
   came
 up with something to do it in attributes.  AttributeModifiers
obviously
 work, but when you have a lot of things you want to localize on
the same
 page it's a lot of extra Java code that needs to be written to
support
   this
 because you need to add the specific Component and add an
   AttributeModifier.
 
  What about a compromise?  I think the experimental stuff in
 WicketMessageTagHandler is cumbersome to add to the HTML, so what
if we
 created a component whose sole purpose is to add attributes to
some HTML
 element.  Or can this already be done like this:
 
  Java:
  add(new WebComponent(imageAlt).add(new
 AttributeModifier(alt, true, new ResourceModel(my.key;
 
  HTML:
  img wicket:id=imageAlt src=mySrc /
 
  I haven't tested if this works, but if not, maybe some kind of
   Component
 could be created which allows something like this.  It will allow
for
 multiple attributes to be replaced as well.
 
  Thoughts?
 
 
  --Andrew
 
 
 
  On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED] 
wrote:
   On 5/4/06, Ralf Ebert [EMAIL PROTECTED] wrote:
Hi Juergen,
   
 please see WicketMessageTagHandler.java. It is
experimental only
   and
 disabled by default. Reason: it is realy ugly to have
something
   like
 wicket:example=tag=key. AttributeModifier are much more
   convinent
 and far less ugly, IMO.
if you have a page with like, say, 20 labels with static
text
   (like
you have sometimes in complex forms for explaining things) I
don't
   see
something to win by adding AttributeModifiers to the
component
   tree. I
see localization of static text as markup issue because
there is
almost no logic to define there. The format you described is
   rather
ugly, that's right: What about:
div wicket:message=blaLabelbla/div
(if you
   want

Re: [Wicket-user] Localization

I think 1 is much more performant when it isn't a wicket componentbecause then the markup is stored under a locale and that markup is preparsed for everything.Can't be faster then that.3 is by far the worst when it comes done to performance. Because we have to do it everytime for every request
even if there isn't a tag like that.. And if it is then we have to manipulate (string concatting and copying) the bufferAnd it can only be done when the person does buffer the response...If we store the markup under the locale and the markup is parsed for that locale and all resources are inserted into
the markup. Then it doesn't matter if it is a wicket component tag or not. Just set the right attribute value into the Component tag attribute. (if a developer alters that again it is his doing) Then we only parse once and we have the right markup file per locale.
The problem with resources changes can be fixed if we monitor resource changes and just delete the markup then(as a whole or maybe a part if we can make the links)johan
On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
We do something similar for autolinks already. Actually I think thereat least 3 solutions:1) If no wicket:id is present than replace the attribute on the flyand add it to the markup stream as if it were RawMarkup. Con: changes
to the properties at runtime are not taken into account. Tags withwicket:id are treated as below.2) Automatically create a WebMarkupContainer for all tags withoutwicket:id but with such attributes and auto-attach an
AttributeModifier. If wicket:id already exists, than auto-attach theAttributeModifier to the already existing component. Con: youauto-create plenty more Containers and the debug page is filled withautomatically created components.
3) A 3rd option could by an OutputTransformer kind ofComponent/Behavior which simply ignores the html/xml structure andsearch replaces the attributes in the output string. Something likes/w18n:([w+\.])/${getString($1)/g(pseudo code only). The
properties file of course could only be with the the transformer orany container up the hierarchy. Currently I like this idea most. Inmost scenarios (RESPONSE_BUFFER) we cache the output string already.We'd simply kind of post process the output. Might as well be more
efficient (performance and memory) than any of the other solutions.JuergenOn 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote: the problem i see is are we going to check every tag's attribute (wicket
component or not) for such a thing? And if it is not a wicket component we make it a special (none raw markup) tag? and if it is a wicket component already we just put a special object in the
tags attributes? johan On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: It'll give people choice though. Not everyone cares about
previewability in the same fashion. EelcoOn 5/9/06, Juergen Donnerstag [EMAIL PROTECTED]
wrote: I guess it depends on what job you are in. It is nice for the person who has to maintain the properties. If I were a html designer I'd rather prefer a default text like save or whatever, which btw
applies if no property is found. Juergen On 5/9/06, Igor Vaynberg [EMAIL PROTECTED]
wrote:why not? in a preview you would get a button with textwicket:i18n:buttons.save thats good for preview since you can see the key!
-Igor On 5/8/06, Juergen Donnerstag
[EMAIL PROTECTED] wrote: It will not be previeable any more. Juergen On 5/9/06, Igor Vaynberg
[EMAIL PROTECTED] wrote: why not a format like this input type=submit value=wicket:i18n:
buttons.save/ or input type=submit value=wi18n:buttons.save
/ -Igor On 5/8/06, Andrew Berman
[EMAIL PROTECTED] wrote: Hey Guys, I think adding something to support localized attributes would
be abig plus.I know that when Wicket added wicket:message it really saved alot of extra Java code on my part.I think the same thing would happen
if wecame up with something to do it in attributes.AttributeModifiers obviously work, but when you have a lot of things you want to localize on
the same page it's a lot of extra Java code that needs to be written to supportthis because you need to add the specific Component and add an
AttributeModifier. What about a compromise?I think the experimental stuff in WicketMessageTagHandler is cumbersome to add to the HTML, so what
if we created a component whose sole purpose is to add attributes to some HTML element.Or can this already be done like this:
Java: add(new WebComponent(imageAlt).add(new AttributeModifier(alt, true, new ResourceModel(
my.key; HTML: img wicket:id=imageAlt src="" /
I haven't tested if this works, but if not, maybe some kind ofComponent could be created which allows

Re: [Wicket-user] Localization


On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:

I think 1 is much more performant when it isn't a wicket component
because then the markup is stored under a locale and that markup is
preparsed for everything.
Can't be faster then that.


That is how WicketMessageTagHandler works today. It merely replaces
the attribute's value. But contrary to what I wrote we don't need to
create AMs for tags with wicket:id. It actually doesn't matter if
wicket:id exists or not. We simply change the attributes value.



3 is by far the worst when it comes done to performance. Because we have to
do it everytime for every request
even if there isn't a tag like that.. And if it is then we have to
manipulate (string concatting and copying) the buffer
And it can only be done when the person does buffer the response...



I don't think the performance is that much worse.
Yes we have to do it for all requests, but only than you can change
your properties on the fly. Else you'd have to remove the entry from
the markup cache to force markup reloading.
String manipulation I'd guess is about the same in all 3 scenarios.
Your last point is wrong. Transformers are independent from the
RESPONSE_BUFFER settings.


If we store the markup under the locale and the markup is parsed for that
locale and all resources are inserted into
the markup. Then it doesn't matter if it is a wicket component tag or not.
Just set the right attribute value into the
Component tag attribute. (if a developer alters that again it is his doing)
Then we only parse once and we have the right markup file per locale.



true, see above.
Hot deplyoment of properties files would require clearing the cache
(not true, but everything else seems far to complicated)


The problem with resources changes can be fixed if we monitor resource
changes and just delete the markup then
(as a whole or maybe a part if we can make the links)



you need to remove all markups which make use of the properties files
and that could potentially be every child component. Even worse, the
algorithm would be tied to the logic we use to find properties. That
logic however will become even more flexible in 1.2 meaning that you
can not rely on it all to remove the markup cache entries. IMO it'd be
sufficient to clear the whole cache and avoid these troubles all
together.

Juergen


johan



On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:

We do something similar for autolinks already. Actually I think there
at least 3 solutions:
1) If no wicket:id is present than replace the attribute on the fly
and add it to the markup stream as if it were RawMarkup. Con: changes
to the properties at runtime are not taken into account. Tags with
wicket:id are treated as below.
2) Automatically create a WebMarkupContainer for all tags without
wicket:id but with such attributes and auto-attach an
AttributeModifier. If wicket:id already exists, than auto-attach the
AttributeModifier to the already existing component. Con: you
auto-create plenty more Containers and the debug page is filled with
automatically created components.
3) A 3rd option could by an OutputTransformer kind of
Component/Behavior which simply ignores the html/xml structure and
search  replaces the attributes in the output string. Something like
s/w18n:([w+\.])/${getString($1)/g  (pseudo code only).
The
properties file of course could only be with the the transformer or
any container up the hierarchy. Currently I like this idea most. In
most scenarios (RESPONSE_BUFFER) we cache the output string already.
We'd simply kind of post process the output. Might as well be more
efficient (performance and memory) than any of the other solutions.

Juergen

On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
 the problem i see is are we going to check every tag's attribute (wicket
 component or not) for such a thing?

 And if it is not a wicket component we make it a special (none raw markup)
 tag?
 and if it is a wicket component already we just put a special object in
the
 tags attributes?

 johan



 On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
  It'll give people choice though. Not everyone cares about
  previewability in the same fashion.
 
  Eelco
 
 
  On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED]  wrote:
   I guess it depends on what job you are in. It is nice for the person
   who has to maintain the properties. If I were a html designer I'd
   rather prefer a default text like save or whatever, which btw
   applies if no property is found.
  
   Juergen
  
   On 5/9/06, Igor Vaynberg [EMAIL PROTECTED]  wrote:
why not? in a preview you would get a button with text
wicket:i18n:buttons.save
   
thats good for preview since you can see the key!
   
-Igor
   
   
   
On 5/8/06, Juergen Donnerstag  [EMAIL PROTECTED] wrote:
 It will not be previeable any more.

 Juergen

 On 5/9/06, Igor Vaynberg  [EMAIL PROTECTED] wrote:
  why not a format like this
 
  input type=submit

Re: [Wicket-user] Localization

 3 is by far the worst when it comes done to performance. Because we have to
 do it everytime for every request even if there isn't a tag like that.. And if it is then we have to manipulate (string concatting and copying) the buffer And it can only be done when the person does buffer the response...
I don't think the performance is that much worse.i think it will. Because you have to scan really every output everytime for to find if it has toreplace something. And if it has to replace something then it concats and copies
large strings (pages can become easily 25 100KB)That generates a lot of garbage We could optimze it a bit by using our AppendingStringBuffer for manipulation outputSo we just alter the internal string array by giving that class replace(String toSearch, String replaceString) methods 
then we search for the toSearch string and we alter the internal array with the replace string 
Yes we have to do it for all requests, but only than you can changeyour properties on the fly. Else you'd have to remove the entry fromthe markup cache to force markup reloading.String manipulation I'd guess is about the same in all 3 scenarios.
Your last point is wrong. Transformers are independent from theRESPONSE_BUFFER settings.I wasn't talking about transformers. I was talking about Filters. Filters runover the complete output of the page after it is rendered.
And if you use a transformer for that over the completel page.. Then that is the sameas the Response_Buffer setting...Because you do buffer then completely.by the way we really should depricate this:public abstract CharSequence transform(final Component component, final String output)
and make it:public abstract CharSequence transform(final Component component, final CharSequence output)orpublic abstract AppendingStringBuffer transform(final Component component, final AppendingStringBuffer output)
Because when no transformation happens then the toString() is a wasteand the transform method can do the alterations in the appendingstringbuffer itself.
 If we store the markup under the locale and the markup is parsed for that locale and all resources are inserted into the markup. Then it doesn't matter if it is a wicket component tag or not. Just set the right attribute value into the
 Component tag attribute. (if a developer alters that again it is his doing) Then we only parse once and we have the right markup file per locale.true, see above.Hot deplyoment of properties files would require clearing the cache
(not true, but everything else seems far to complicated)yes i agree clear the cache completely. It is most of the time developerment mode only.I want speed and performance when i am in production.
Ofcourse also then we could have properties comming from a database that should be reflected on a page..But somehow something must be reloaded then and that can clear the cache.johan

Re: [Wicket-user] Localization


I solved this some time ago with own preprocessor that replaces
${key} with the value from property files.

I know this is not very wicket-like, but the markup looks much simpler 
with ${key} then with wicket:message key=key/wicket:message


-Matej

Igor Vaynberg wrote:
why not? in a preview you would get a button with text 
wicket:i18n:buttons.save


thats good for preview since you can see the key!

-Igor


On 5/8/06, * Juergen Donnerstag* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


It will not be previeable any more.

Juergen

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  why not a format like this
 
  input type=submit value=wicket:i18n: buttons.save/
 
  or
 
  input type=submit value=wi18n:buttons.save/
 
  -Igor
 
 
 
  On 5/8/06, Andrew Berman  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  
   Hey Guys,
  
   I think adding something to support localized attributes would
be a big
  plus.  I know that when Wicket added wicket:message it really
saved a lot of
  extra Java code on my part.  I think the same thing would happen
if we came
  up with something to do it in attributes.  AttributeModifiers
obviously
  work, but when you have a lot of things you want to localize on
the same
  page it's a lot of extra Java code that needs to be written to
support this
  because you need to add the specific Component and add an
AttributeModifier.
  
   What about a compromise?  I think the experimental stuff in
  WicketMessageTagHandler is cumbersome to add to the HTML, so what
if we
  created a component whose sole purpose is to add attributes to
some HTML
  element.  Or can this already be done like this:
  
   Java:
   add(new WebComponent(imageAlt).add(new
  AttributeModifier(alt, true, new ResourceModel(my.key;
  
   HTML:
   img wicket:id=imageAlt src=mySrc /
  
   I haven't tested if this works, but if not, maybe some kind of
Component
  could be created which allows something like this.  It will allow for
  multiple attributes to be replaced as well.
  
   Thoughts?
  
  
   --Andrew
  
  
  
   On 5/4/06, Juergen Donnerstag  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On 5/4/06, Ralf Ebert [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
 Hi Juergen,

  please see WicketMessageTagHandler.java. It is
experimental only and
  disabled by default. Reason: it is realy ugly to have
something like
  wicket:example=tag=key. AttributeModifier are much more
convinent
  and far less ugly, IMO.
 if you have a page with like, say, 20 labels with static
text (like
 you have sometimes in complex forms for explaining things)
I don't see
 something to win by adding AttributeModifiers to the
component tree. I
 see localization of static text as markup issue because
there is
 almost no logic to define there. The format you described
is rather
 ugly, that's right: What about:
 div wicket:message=blaLabelbla/div (if you want
  to go the
 message as text between the tags)
   
this is wicket:message
  value=xxxdefault/wicket:message and
already available.
   
 input type=submit wicket:message:value=Do something/
(for
 localizing the attribute value, probably the second : is
not valid xml
 any more, but another separation char like _ or  maybe no
separation
 char at all could be used)

   
It is all not realy nice, isn't it? That is what we struggled
with. We
didn't find a syntax which we realy liked and which is standards
compliant ( e.g. XML namespace, schema).
   
 This would be very helpful for quick  easy localization of
static
 content in pages, something that's missing at the moment
from my point
 of view. Tell me what you think, if I have time I would like to
 implement this and contribute it...

   
your help is very much appreciated but the syntax should be
right.
   
  That is default. Localizer implements a search hierarchy
up the
  component tree. You only need one properties files per
language per
  Panel which contains X number of component. Thinking ...
That is not
  your question, isn't it? Like Application.properties is
the last
  resort for all messages, you ask for one per java
package, right?
  So,
  in addition to the my.pkg.MyPanel.properties it should
look in
  my/pkg/Wicket.properties as well (may be
Wicket.properties is not
  the
  best name).

Re: [Wicket-user] Localization

That is also a possibiltyThat we pre process the markup even before the markup parser handles it.Then we just replace all wicket:i18n:key:XX (or whatever we call it) and then parse the markup.johan
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
I solved this some time ago with own preprocessor that replaces${key} with the value from property files.I know this is not very wicket-like, but the markup looks much simplerwith ${key} then with wicket:message key=key/wicket:message
-MatejIgor Vaynberg wrote: why not? in a preview you would get a button with text wicket:i18n:buttons.save thats good for preview since you can see the key!
-Igor On 5/8/06, * Juergen Donnerstag* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote: It will not be previeable any more. Juergen On 5/9/06, Igor Vaynberg [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote: why not a format like this input type=submit value=wicket:i18n:
buttons.save/ or input type=submit value=wi18n:buttons.save/ -Igor
On 5/8/06, Andrew Berman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote: Hey Guys, I think adding something to support localized attributes would be a big plus.I know that when Wicket added wicket:message it really
saved a lot of extra Java code on my part.I think the same thing would happen if we came up with something to do it in attributes.AttributeModifiers obviously
work, but when you have a lot of things you want to localize on the same page it's a lot of extra Java code that needs to be written to support this because you need to add the specific Component and add an
AttributeModifier. What about a compromise?I think the experimental stuff in WicketMessageTagHandler is cumbersome to add to the HTML, so what
if we created a component whose sole purpose is to add attributes to some HTML element.Or can this already be done like this: Java:
add(new WebComponent(imageAlt).add(new AttributeModifier(alt, true, new ResourceModel(my.key; HTML:
img wicket:id=imageAlt src="" / I haven't tested if this works, but if not, maybe some kind of Component
could be created which allows something like this.It will allow for multiple attributes to be replaced as well. Thoughts?
--Andrew On 5/4/06, Juergen Donnerstag
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 5/4/06, Ralf Ebert
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:Hi Juergen,please see
WicketMessageTagHandler.java. It is experimental only and disabled by default. Reason: it is realy ugly to have something like wicket:example=tag=key. AttributeModifier are much more
convinent and far less ugly, IMO.if you have a page with like, say, 20 labels with static text (likeyou have sometimes in complex forms for explaining things)
I don't seesomething to win by adding AttributeModifiers to the component tree. Isee localization of static text as markup issue because
there isalmost no logic to define there. The format you described is ratherugly, that's right: What about:div wicket:message=blaLabelbla/div (if you want
to go themessage as text between the tags) this is wicket:message value=xxxdefault/wicket:message and
already available. input type=submit wicket:message:value=Do something/ (forlocalizing the attribute value, probably the second : is
not valid xmlany more, but another separation char like _ ormaybe no separationchar at all could be used)
It is all not realy nice, isn't it? That is what we struggled with. We didn't find a syntax which we realy liked and which is standards
compliant ( e.g. XML namespace, schema). This would be very helpful for quick easy localization of staticcontent in pages, something that's missing at the moment
from my pointof view. Tell me what you think, if I have time I would like toimplement this and contribute it...
your help is very much appreciated but the syntax should be right. That is default. Localizer implements a search hierarchy
up the component tree. You only need one properties files per language per Panel which contains X number of component. Thinking ...
That is not your question, isn't it? Like Application.properties is the last resort for all messages, you ask for one per java
package, right? So, in addition to the my.pkg.MyPanel.properties it should look in my/pkg/Wicket.properties as well (may be
Wicket.properties is not the best name).That's what I want to do and it would be a nice feature if such a
lookup strategy could be added by just setting an option and defininga name for the property file. I tried to do it quick myself butstopped after finding out that the property file name is
quite tightlycoupled to some class name for the moment...It is fairly easy to add. Please see
Settings.addStringResourceLoader, Application.getResourceStreamLocator and CompoundResourceStreamLocator.java Let me know

Re: [Wicket-user] Localization


So far I can say it works well for me.
The only problematic (or cumbersome) thing was that I had to make my own 
 ResourceStreamLocator and ResourceStream to have this done.

Having some kind of preprocessing filters (with methods like

   String processString(String)   or

   InputStream processStream(Input Stream)

would be enough);

-Matej


Johan Compagner wrote:

That is also a possibilty
That we pre process the markup even before the markup parser handles it.
Then we just replace all wicket:i18n:key:XX (or whatever we call it) 
and then parse the markup.


johan


On 5/9/06, *Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

I solved this some time ago with own preprocessor that replaces
${key} with the value from property files.

I know this is not very wicket-like, but the markup looks much simpler
with ${key} then with wicket:message key=key/wicket:message

-Matej

Igor Vaynberg wrote:
  why not? in a preview you would get a button with text
  wicket:i18n:buttons.save
 
  thats good for preview since you can see the key!
 
  -Igor
 
 
  On 5/8/06, * Juergen Donnerstag* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
 
  It will not be previeable any more.
 
  Juergen
 
  On 5/9/06, Igor Vaynberg [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
why not a format like this
   
input type=submit value=wicket:i18n: buttons.save/
   
or
   
input type=submit value=wi18n:buttons.save/
   
-Igor
   
   
   
On 5/8/06, Andrew Berman  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

 Hey Guys,

 I think adding something to support localized attributes
would
  be a big
plus.  I know that when Wicket added wicket:message it really
  saved a lot of
extra Java code on my part.  I think the same thing would
happen
  if we came
up with something to do it in attributes.  AttributeModifiers
  obviously
work, but when you have a lot of things you want to
localize on
  the same
page it's a lot of extra Java code that needs to be written to
  support this
because you need to add the specific Component and add an
  AttributeModifier.

 What about a compromise?  I think the experimental stuff in
WicketMessageTagHandler is cumbersome to add to the HTML,
so what
  if we
created a component whose sole purpose is to add attributes to
  some HTML
element.  Or can this already be done like this:

 Java:
 add(new WebComponent(imageAlt).add(new
AttributeModifier(alt, true, new ResourceModel(my.key;

 HTML:
 img wicket:id=imageAlt src=mySrc /

 I haven't tested if this works, but if not, maybe some
kind of
  Component
could be created which allows something like this.  It
will allow for
multiple attributes to be replaced as well.

 Thoughts?


 --Andrew



 On 5/4/06, Juergen Donnerstag 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  On 5/4/06, Ralf Ebert  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
   Hi Juergen,
  
please see WicketMessageTagHandler.java. It is
  experimental only and
disabled by default. Reason: it is realy ugly to have
  something like
wicket:example=tag=key. AttributeModifier are
much more
  convinent
and far less ugly, IMO.
   if you have a page with like, say, 20 labels with static
  text (like
   you have sometimes in complex forms for explaining
things)
  I don't see
   something to win by adding AttributeModifiers to the
  component tree. I
   see localization of static text as markup issue
because
  there is
   almost no logic to define there. The format you
described
  is rather
   ugly, that's right: What about:
   div wicket:message=blaLabelbla/div (if you want
to go the
   message as text between the tags)

Re: [Wicket-user] Localization

2006-05-09 Thread Bruno Borges

Sure it works, but... if Wicket is going to have ${key}... ${something} in htmls, let's go back to JSP 2.0 and use EL... just a thoughtOn 5/9/06, Matej Knopp
 [EMAIL PROTECTED] wrote:So far I can say it works well for me.
The only problematic (or cumbersome) thing was that I had to make my ownResourceStreamLocator and ResourceStream to have this done.Having some kind of preprocessing filters (with methods likeString processString(String) or
InputStream processStream(Input Stream)would be enough);-MatejJohan Compagner wrote: That is also a possibilty That we pre process the markup even before the markup parser handles it.
 Then we just replace all wicket:i18n:key:XX (or whatever we call it) and then parse the markup. johan On 5/9/06, *Matej Knopp* 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I solved this some time ago with own preprocessor that replaces ${key} with the value from property files.
 I know this is not very wicket-like, but the markup looks much simpler with ${key} then with wicket:message key=key/wicket:message -Matej
 Igor Vaynberg wrote: why not? in a preview you would get a button with text wicket:i18n:buttons.save thats good for preview since you can see the key!
 -Igor On 5/8/06, * Juergen Donnerstag* [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: It will not be previeable any more. Juergen On 5/9/06, Igor Vaynberg 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: why not a format like this
 input type=submit value=wicket:i18n: buttons.save/ or input type=submit value=wi18n:
buttons.save/ -Igor On 5/8/06, Andrew Berman  
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:   Hey Guys,   I think adding something to support localized attributes
 would be a big plus.I know that when Wicket added wicket:message it really saved a lot of extra Java code on my part.I think the same thing would
 happen if we came up with something to do it in attributes.AttributeModifiers obviously work, but when you have a lot of things you want to
 localize on the same page it's a lot of extra Java code that needs to be written to support this because you need to add the specific Component and add an
 AttributeModifier.   What about a compromise?I think the experimental stuff in WicketMessageTagHandler is cumbersome to add to the HTML,
 so what if we created a component whose sole purpose is to add attributes to some HTML element.Or can this already be done like this:
   Java:  add(new WebComponent(imageAlt).add(new AttributeModifier(alt, true, new ResourceModel(
my.key;   HTML:  img wicket:id=imageAlt src="" / 
  I haven't tested if this works, but if not, maybe some kind of Component could be created which allows something like this.It
 will allow for multiple attributes to be replaced as well.   Thoughts?  
  --Andrew On 5/4/06, Juergen Donnerstag  
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:   On 5/4/06, Ralf Ebert  
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote:Hi Juergen,please see 
WicketMessageTagHandler.java. It is experimental only and disabled by default. Reason: it is realy ugly to have something like
 wicket:example=tag=key. AttributeModifier are much more convinent and far less ugly, IMO.
if you have a page with like, say, 20 labels with static text (likeyou have sometimes in complex forms for explaining
 things) I don't seesomething to win by adding AttributeModifiers to the component tree. Isee localization of static text as markup issue
 because there isalmost no logic to define there. The format you described is ratherugly, that's right: What about:
div wicket:message=blaLabelbla/div (if you want to go themessage as text between the tags)
 this is wicket:message value=xxxdefault/wicket:message and   already available.
  input type=submit wicket:message:value=Do something/ (forlocalizing the attribute value, probably the second
 : is not valid xmlany more, but another separation char like _ ormaybe no separationchar at all could be used)
It is all not realy nice, isn't it? That is what we struggled with. We
   didn't find a syntax which we realy liked and which is standards   compliant ( e.g. XML namespace, schema).  
This would be very helpful for quick  easy localization of staticcontent in pages, something that's missing at the
 moment from my pointof view. Tell me what you think, if I have time I would like toimplement this and contribute it...
your help is very much appreciated but the syntax should be right.
   That is default. Localizer implements a search hierarchy up the component tree. You only need one properties files per
 language per Panel which contains X number of component.

Re: [Wicket-user] Localization


Bruno Borges wrote:
This is completely different. ${key} is simply replaced by a string from 
property file. No EL, no expressions, no ognl, nothing. Just a simple 
string.


Comparing wicket:message key=key/wicket:message
to${key}

which one is simpler?

-Matej

Sure it works, but... if Wicket is going to have ${key}... ${something} 
in htmls, let's go back to JSP 2.0 and use EL... just a thought




On 5/9/06, *Matej Knopp * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

So far I can say it works well for me.
The only problematic (or cumbersome) thing was that I had to make my own
  ResourceStreamLocator and ResourceStream to have this done.
Having some kind of preprocessing filters (with methods like

String processString(String)   or

InputStream processStream(Input Stream)

would be enough);

-Matej


Johan Compagner wrote:
  That is also a possibilty
  That we pre process the markup even before the markup parser
handles it.
  Then we just replace all wicket:i18n:key:XX (or whatever we
call it)
  and then parse the markup.
 
  johan
 
 
  On 5/9/06, *Matej Knopp*  [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
 
  I solved this some time ago with own preprocessor that replaces
  ${key} with the value from property files.
 
  I know this is not very wicket-like, but the markup looks
much simpler
  with ${key} then with wicket:message key=key/wicket:message
 
  -Matej
 
  Igor Vaynberg wrote:
why not? in a preview you would get a button with text
wicket:i18n:buttons.save
   
thats good for preview since you can see the key!
   
-Igor
   
   
On 5/8/06, * Juergen Donnerstag*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
   
It will not be previeable any more.
   
Juergen
   
On 5/9/06, Igor Vaynberg  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  why not a format like this
 
  input type=submit value=wicket:i18n:
buttons.save/
 
  or
 
  input type=submit value=wi18n: buttons.save/
 
  -Igor
 
 
 
  On 5/8/06, Andrew Berman  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
  
   Hey Guys,
  
   I think adding something to support localized
attributes
  would
be a big
  plus.  I know that when Wicket added wicket:message
it really
saved a lot of
  extra Java code on my part.  I think the same thing
would
  happen
if we came
  up with something to do it in
attributes.  AttributeModifiers
obviously
  work, but when you have a lot of things you want to
  localize on
the same
  page it's a lot of extra Java code that needs to be
written to
support this
  because you need to add the specific Component and
add an
AttributeModifier.
  
   What about a compromise?  I think the
experimental stuff in
  WicketMessageTagHandler is cumbersome to add to the
HTML,
  so what
if we
  created a component whose sole purpose is to add
attributes to
some HTML
  element.  Or can this already be done like this:
  
   Java:
   add(new WebComponent(imageAlt).add(new
  AttributeModifier(alt, true, new ResourceModel(
my.key;
  
   HTML:
   img wicket:id=imageAlt src=mySrc /
  
   I haven't tested if this works, but if not, maybe
some
  kind of
Component
  could be created which allows something like this.  It

Re: [Wicket-user] Localization


$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more 
interested in clean and simple preprocessing filters, something wicket 
lacks currently.


-Matej

Bruno Borges wrote:

And how should I write if I want to literally output ${key} to the user?

On 5/9/06, *Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

Bruno Borges wrote:
This is completely different. ${key} is simply replaced by a string
from
property file. No EL, no expressions, no ognl, nothing. Just a simple
string.

Comparing wicket:message key=key/wicket:message
to${key}

which one is simpler?

-Matej

  Sure it works, but... if Wicket is going to have ${key}...
${something}
  in htmls, let's go back to JSP 2.0 and use EL... just a thought
 
 
 
  On 5/9/06, *Matej Knopp *  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
 
  So far I can say it works well for me.
  The only problematic (or cumbersome) thing was that I had to
make my own
ResourceStreamLocator and ResourceStream to have this done.
  Having some kind of preprocessing filters (with methods like
 
  String processString(String)   or
 
  InputStream processStream(Input Stream)
 
  would be enough);
 
  -Matej
 
 
  Johan Compagner wrote:
That is also a possibilty
That we pre process the markup even before the markup parser
  handles it.
Then we just replace all wicket:i18n:key:XX (or
whatever we
  call it)
and then parse the markup.
   
johan
   
   
On 5/9/06, *Matej Knopp*  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL 
PROTECTED]
  mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
   
I solved this some time ago with own preprocessor
that replaces
${key} with the value from property files.
   
I know this is not very wicket-like, but the markup looks
  much simpler
with ${key} then with wicket:message
key=key/wicket:message
   
-Matej
   
Igor Vaynberg wrote:
  why not? in a preview you would get a button with text
  wicket:i18n: buttons.save
 
  thats good for preview since you can see the key!
 
  -Igor
 
 
  On 5/8/06, * Juergen Donnerstag*
  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]  wrote:
 
  It will not be previeable any more.
 
  Juergen
 
  On 5/9/06, Igor Vaynberg 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
why not a format like this
   
input type=submit value=wicket:i18n:
  buttons.save/
   
or
   
input type=submit value=wi18n:
buttons.save/
   
-Igor
   
   
   
On 5/8/06, Andrew Berman 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

Re: [Wicket-user] Localization


On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.



That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.

Juergen


---
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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


Juergen Donnerstag wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.

Unfortunately IMarkupFilter does not seem to be capable of replacing 
things in RawMarkup elements, does it? So it seems not to be able to 
replace ${key} to localized value, or am I missing anything here?


?xml encoding=.. does complicate things a bit, but not much. What 
about load the ?xml line, determine encoding and loat the rest of the 
file as string. Then let the preprocessor process it and then send it to 
MarkupParser? (Just a thoght).


-Matej


That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.

Juergen


---
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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


I haven't looked into it deeper, but it sounds to me that we could
make it slightly easier. We already have post processing filters, so
personally I would think we would be consistent to have pre processing
filters too. I know the functionality to do this is there already, but
we might come up with something that makes it easier and more
consistant with the postprocessing filters.

Eelco

On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
 $${key}? Or whatever you want.
 I don't need this behavior to be in wicket core. I'm much more
 interested in clean and simple preprocessing filters, something wicket
 lacks currently.


That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.

Juergen


---
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?cmdlnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




---
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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


Matej Knopp wrote:

Juergen Donnerstag wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.

Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was 
evaluating this and it was not possible back then.


Anyway, it seems that markup filter should be enough.

Unfortunately IMarkupFilter does not seem to be capable of replacing 
things in RawMarkup elements, does it? So it seems not to be able to 
replace ${key} to localized value, or am I missing anything here?


?xml encoding=.. does complicate things a bit, but not much. What 
about load the ?xml line, determine encoding and loat the rest of the 
file as string. Then let the preprocessor process it and then send it to 
MarkupParser? (Just a thoght).


-Matej


That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.

Juergen


---
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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.

-Matej


Yeah, that sounds like a good idea. If we have that pluggable, users
can decide for themselves what they want, while we don't have to
officially support a certain syntax of which the danger may be that
sooner or later people will want to ask OGNL or JSP like features.

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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


Martijn is writing about localization for Wicket In Action now. I'm
sure he'd appreciate it if someone would write up some notes about how
to do this on the WIKI.

Eelco


On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

Matej Knopp wrote:
 Juergen Donnerstag wrote:
 On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
 $${key}? Or whatever you want.
 I don't need this behavior to be in wicket core. I'm much more
 interested in clean and simple preprocessing filters, something wicket
 lacks currently.

Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was
evaluating this and it was not possible back then.

Anyway, it seems that markup filter should be enough.

 Unfortunately IMarkupFilter does not seem to be capable of replacing
 things in RawMarkup elements, does it? So it seems not to be able to
 replace ${key} to localized value, or am I missing anything here?

 ?xml encoding=.. does complicate things a bit, but not much. What
 about load the ?xml line, determine encoding and loat the rest of the
 file as string. Then let the preprocessor process it and then send it to
 MarkupParser? (Just a thoght).

 -Matej

 That is true, we don't have something that allow to pre-processor the
 plain input string and IMO it is not needed and when I think about
 ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
 similar function but are already aware of the xml structure, the
 encoding, etc.. And it is trivial to register them with the
 application.

 Juergen


 ---
 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=kkid0709bid3057dat1642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




 ---
 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=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




---
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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

2006-05-09 Thread Andrew Berman

So are we saying that there is going to be some MarkupFilter to replace whatever the developer decides to use for a localization demarcator?I had another idea. What if wicket:message was enhanced? Would something like this work:
wicket:message key=myKey applyTo=value input type=submit value=Previewable Value//wicket:messageThis way we could still have the previewability of the HTML page and have the localization applied at runtime.
--AndrewOn 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Martijn is writing about localization for Wicket In Action now. I'msure he'd appreciate it if someone would write up some notes about howto do this on the WIKI.EelcoOn 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote: Matej Knopp wrote: Juergen Donnerstag wrote: On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote: $${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more interested in clean and simple preprocessing filters, something wicket lacks currently.
Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was evaluating this and it was not possible back then. Anyway, it seems that markup filter should be enough.
Unfortunately IMarkupFilter does not seem to be capable of replacing things in RawMarkup elements, does it? So it seems not to be able to replace ${key} to localized value, or am I missing anything here?
?xml encoding=.. does complicate things a bit, but not much. What about load the ?xml line, determine encoding and loat the rest of the file as string. Then let the preprocessor process it and then send it to
MarkupParser? (Just a thoght). -Matej That is true, we don't have something that allow to pre-processor the plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a similar function but are already aware of the xml structure, the encoding, etc.. And it is trivial to register them with the
application. Juergen--- 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=kkid0709bid3057dat1642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user --- 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=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user ---
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=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---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?cmdlnkkid0709bid3057dat1642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


What I definitively like about the pre-processor/ filter is that it is
very efficient. Only for static messages though, but that's the whole
idea on these special tags/ attributes anyway.

I don't know. If we can reach a consensus on the best way, I'd be okay
with adopting something that works out-of-the-box. If not, it's better
to provide the means to customize Wicket so that it works like you
want.

Eelco


On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:

So are we saying that there is going to be some MarkupFilter to replace
whatever the developer decides to use for a localization demarcator?

I had another idea.  What if wicket:message was enhanced?  Would something
like this work:

wicket:message key=myKey applyTo=value
  input type=submit value=Previewable Value/
/wicket:message

This way we could still have the previewability of the HTML page and have
the localization applied at runtime.

--Andrew


On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:

 Martijn is writing about localization for Wicket In Action now. I'm
sure he'd appreciate it if someone would write up some notes about how
to do this on the WIKI.

Eelco


On 5/9/06, Matej Knopp  [EMAIL PROTECTED] wrote:
 Matej Knopp wrote:
  Juergen Donnerstag wrote:
  On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
  $${key}? Or whatever you want.
  I don't need this behavior to be in wicket core. I'm much more
  interested in clean and simple preprocessing filters, something wicket
  lacks currently.
 
 Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was
 evaluating this and it was not possible back then.

 Anyway, it seems that markup filter should be enough.

   Unfortunately IMarkupFilter does not seem to be capable of replacing
  things in RawMarkup elements, does it? So it seems not to be able to
  replace ${key} to localized value, or am I missing anything here?
 
  ?xml encoding=.. does complicate things a bit, but not much. What
  about load the ?xml line, determine encoding and loat the rest of the
  file as string. Then let the preprocessor process it and then send it to
  MarkupParser? (Just a thoght).
 
  -Matej
 
  That is true, we don't have something that allow to pre-processor the
  plain input string and IMO it is not needed and when I think about
  ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
  similar function but are already aware of the xml structure, the
  encoding, etc.. And it is trivial to register them with the
  application.
 
  Juergen
 
 
 
---
  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=kkid0709bid3057dat1642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
  ---
  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=lnkkid=120709bid=263057dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
https://lists.sourceforge.net/lists/listinfo/wicket-user
 



 ---
 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=lnkkid=120709bid=263057dat=121642
  ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



---
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?cmdlnkkid0709bid3057dat1642

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid0709bid3057dat1642

Re: [Wicket-user] Localization


On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:

What I definitively like about the pre-processor/ filter is that it is
very efficient. Only for static messages though, but that's the whole
idea on these special tags/ attributes anyway.



But it realy shouldn't be a quick fix. IMO we should first improve the
general resource chain. Additional an text based filter in between
would be very easy than.

Juergen


I don't know. If we can reach a consensus on the best way, I'd be okay
with adopting something that works out-of-the-box. If not, it's better
to provide the means to customize Wicket so that it works like you
want.

Eelco


On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:
 So are we saying that there is going to be some MarkupFilter to replace
 whatever the developer decides to use for a localization demarcator?

 I had another idea.  What if wicket:message was enhanced?  Would something
 like this work:

 wicket:message key=myKey applyTo=value
   input type=submit value=Previewable Value/
 /wicket:message

 This way we could still have the previewability of the HTML page and have
 the localization applied at runtime.

 --Andrew


 On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 
  Martijn is writing about localization for Wicket In Action now. I'm
 sure he'd appreciate it if someone would write up some notes about how
 to do this on the WIKI.

 Eelco


 On 5/9/06, Matej Knopp  [EMAIL PROTECTED] wrote:
  Matej Knopp wrote:
   Juergen Donnerstag wrote:
   On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
   $${key}? Or whatever you want.
   I don't need this behavior to be in wicket core. I'm much more
   interested in clean and simple preprocessing filters, something wicket
   lacks currently.
  
  Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was
  evaluating this and it was not possible back then.
 
  Anyway, it seems that markup filter should be enough.
 
Unfortunately IMarkupFilter does not seem to be capable of replacing
   things in RawMarkup elements, does it? So it seems not to be able to
   replace ${key} to localized value, or am I missing anything here?
  
   ?xml encoding=.. does complicate things a bit, but not much. What
   about load the ?xml line, determine encoding and loat the rest of the
   file as string. Then let the preprocessor process it and then send it to
   MarkupParser? (Just a thoght).
  
   -Matej
  
   That is true, we don't have something that allow to pre-processor the
   plain input string and IMO it is not needed and when I think about
   ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
   similar function but are already aware of the xml structure, the
   encoding, etc.. And it is trivial to register them with the
   application.
  
   Juergen
  
  
  
 ---
   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=kkid0709bid3057dat1642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
  
   ---
   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=lnkkid=120709bid=263057dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
 
  ---
  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=lnkkid=120709bid=263057dat=121642
   ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 ---
 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?cmdlnkkid0709bid3057dat1642

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


But it realy shouldn't be a quick fix. IMO we should first improve the
general resource chain. Additional an text based filter in between
would be very easy than.

Juergen



Well, we consider you being the markup masta :) I'm certainly not in
favor of a quick fix anytime, anywhere in Wicket. Quick fixes always
come back to bite you later. However, I'm quite attracted to the idea
of pre-processing (be that through markup loading mech or not) and the
efficiency gain is probably that great that I don't consider it a
quick fix.

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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

2006-05-09 Thread Justin Lee

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Personally, I find the concept of any sort of templating/text
substitution a little distasteful.  Things would start looking like
velocity or JSP and I can't afford the alcohol to make that livable...

Juergen Donnerstag wrote:
 On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 What I definitively like about the pre-processor/ filter is that it is
 very efficient. Only for static messages though, but that's the whole
 idea on these special tags/ attributes anyway.

 
 But it realy shouldn't be a quick fix. IMO we should first improve the
 general resource chain. Additional an text based filter in between
 would be very easy than.
 
 Juergen
 
 I don't know. If we can reach a consensus on the best way, I'd be okay
 with adopting something that works out-of-the-box. If not, it's better
 to provide the means to customize Wicket so that it works like you
 want.

 Eelco


 On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:
  So are we saying that there is going to be some MarkupFilter to replace
  whatever the developer decides to use for a localization demarcator?
 
  I had another idea.  What if wicket:message was enhanced?  Would
 something
  like this work:
 
  wicket:message key=myKey applyTo=value
input type=submit value=Previewable Value/
  /wicket:message
 
  This way we could still have the previewability of the HTML page and
 have
  the localization applied at runtime.
 
  --Andrew
 
 
  On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
  
   Martijn is writing about localization for Wicket In Action now. I'm
  sure he'd appreciate it if someone would write up some notes about how
  to do this on the WIKI.
 
  Eelco
 
 
  On 5/9/06, Matej Knopp  [EMAIL PROTECTED] wrote:
   Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters,
 something wicket
lacks currently.
   
   Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess
 I was
   evaluating this and it was not possible back then.
  
   Anyway, it seems that markup filter should be enough.
  
 Unfortunately IMarkupFilter does not seem to be capable of
 replacing
things in RawMarkup elements, does it? So it seems not to be
 able to
replace ${key} to localized value, or am I missing anything here?
   
?xml encoding=.. does complicate things a bit, but not much.
 What
about load the ?xml line, determine encoding and loat the rest
 of the
file as string. Then let the preprocessor process it and then
 send it to
MarkupParser? (Just a thoght).
   
-Matej
   
That is true, we don't have something that allow to
 pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.
   
Juergen
   
   
   
  ---
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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
  
   ---
   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=lnkkid=120709bid=263057dat=121642
___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 
  ---
  Using Tomcat but need to do more? Need to support web services,

Re: [Wicket-user] Localization


What would be your suggestion on how to localize HTML which contains
plenty of text which needs to be localized?

Juergen

On 5/9/06, Justin Lee [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Personally, I find the concept of any sort of templating/text
substitution a little distasteful.  Things would start looking like
velocity or JSP and I can't afford the alcohol to make that livable...

Juergen Donnerstag wrote:
 On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
 What I definitively like about the pre-processor/ filter is that it is
 very efficient. Only for static messages though, but that's the whole
 idea on these special tags/ attributes anyway.


 But it realy shouldn't be a quick fix. IMO we should first improve the
 general resource chain. Additional an text based filter in between
 would be very easy than.

 Juergen

 I don't know. If we can reach a consensus on the best way, I'd be okay
 with adopting something that works out-of-the-box. If not, it's better
 to provide the means to customize Wicket so that it works like you
 want.

 Eelco


 On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:
  So are we saying that there is going to be some MarkupFilter to replace
  whatever the developer decides to use for a localization demarcator?
 
  I had another idea.  What if wicket:message was enhanced?  Would
 something
  like this work:
 
  wicket:message key=myKey applyTo=value
input type=submit value=Previewable Value/
  /wicket:message
 
  This way we could still have the previewability of the HTML page and
 have
  the localization applied at runtime.
 
  --Andrew
 
 
  On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
  
   Martijn is writing about localization for Wicket In Action now. I'm
  sure he'd appreciate it if someone would write up some notes about how
  to do this on the WIKI.
 
  Eelco
 
 
  On 5/9/06, Matej Knopp  [EMAIL PROTECTED] wrote:
   Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters,
 something wicket
lacks currently.
   
   Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess
 I was
   evaluating this and it was not possible back then.
  
   Anyway, it seems that markup filter should be enough.
  
 Unfortunately IMarkupFilter does not seem to be capable of
 replacing
things in RawMarkup elements, does it? So it seems not to be
 able to
replace ${key} to localized value, or am I missing anything here?
   
?xml encoding=.. does complicate things a bit, but not much.
 What
about load the ?xml line, determine encoding and loat the rest
 of the
file as string. Then let the preprocessor process it and then
 send it to
MarkupParser? (Just a thoght).
   
-Matej
   
That is true, we don't have something that allow to
 pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.
   
Juergen
   
   
   
  ---
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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
  https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
  
   ---
   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=lnkkid=120709bid=263057dat=121642
___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net

Re: [Wicket-user] Localization


I think this kind of substition is fine. A slippery slope, but as long
as we resist substituting anything else than just static text, we'll
be fine.

Eelco

On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:

What would be your suggestion on how to localize HTML which contains
plenty of text which needs to be localized?

Juergen

On 5/9/06, Justin Lee [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: RIPEMD160

 Personally, I find the concept of any sort of templating/text
 substitution a little distasteful.  Things would start looking like
 velocity or JSP and I can't afford the alcohol to make that livable...

 Juergen Donnerstag wrote:
  On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
  What I definitively like about the pre-processor/ filter is that it is
  very efficient. Only for static messages though, but that's the whole
  idea on these special tags/ attributes anyway.
 
 
  But it realy shouldn't be a quick fix. IMO we should first improve the
  general resource chain. Additional an text based filter in between
  would be very easy than.
 
  Juergen
 
  I don't know. If we can reach a consensus on the best way, I'd be okay
  with adopting something that works out-of-the-box. If not, it's better
  to provide the means to customize Wicket so that it works like you
  want.
 
  Eelco
 
 
  On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:
   So are we saying that there is going to be some MarkupFilter to replace
   whatever the developer decides to use for a localization demarcator?
  
   I had another idea.  What if wicket:message was enhanced?  Would
  something
   like this work:
  
   wicket:message key=myKey applyTo=value
 input type=submit value=Previewable Value/
   /wicket:message
  
   This way we could still have the previewability of the HTML page and
  have
   the localization applied at runtime.
  
   --Andrew
  
  
   On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
   
Martijn is writing about localization for Wicket In Action now. I'm
   sure he'd appreciate it if someone would write up some notes about how
   to do this on the WIKI.
  
   Eelco
  
  
   On 5/9/06, Matej Knopp  [EMAIL PROTECTED] wrote:
Matej Knopp wrote:
 Juergen Donnerstag wrote:
 On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
 $${key}? Or whatever you want.
 I don't need this behavior to be in wicket core. I'm much more
 interested in clean and simple preprocessing filters,
  something wicket
 lacks currently.

Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess
  I was
evaluating this and it was not possible back then.
   
Anyway, it seems that markup filter should be enough.
   
  Unfortunately IMarkupFilter does not seem to be capable of
  replacing
 things in RawMarkup elements, does it? So it seems not to be
  able to
 replace ${key} to localized value, or am I missing anything here?

 ?xml encoding=.. does complicate things a bit, but not much.
  What
 about load the ?xml line, determine encoding and loat the rest
  of the
 file as string. Then let the preprocessor process it and then
  send it to
 MarkupParser? (Just a thoght).

 -Matej

 That is true, we don't have something that allow to
  pre-processor the
 plain input string and IMO it is not needed and when I think about
 ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
 similar function but are already aware of the xml structure, the
 encoding, etc.. And it is trivial to register them with the
 application.

 Juergen



   ---
 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=kkid0709bid3057dat1642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

   https://lists.sourceforge.net/lists/listinfo/wicket-user




 ---
 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=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net

   https://lists.sourceforge.net/lists/listinfo/wicket-user

   
   
   
---
Using Tomcat but need to do more? Need to support web services,
  security?
Get stuff done quickly

Re: [Wicket-user] Localization

+1 or juergen can come up with a nice way to do it in our Tags introducing a special MessageTag that is just handles like the RawInputTag for tagsthat only consist of a i18n key. And append auto something in the Wicket Component Tag
attribute if it is a wicket component that also has a i18n attribute.I am not in favor a post processing this kind of stuff.So pre or inline processing is fine. And maybe inline is better for property changes...
johanOn 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I think this kind of substition is fine. A slippery slope, but as longas we resist substituting anything else than just static text, we'llbe fine.EelcoOn 5/9/06, Juergen Donnerstag
[EMAIL PROTECTED] wrote: What would be your suggestion on how to localize HTML which contains plenty of text which needs to be localized? Juergen On 5/9/06, Justin Lee
[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Personally, I find the concept of any sort of templating/text
substitution a little distasteful.Things would start looking like velocity or JSP and I can't afford the alcohol to make that livable... Juergen Donnerstag wrote:
On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: What I definitively like about the pre-processor/ filter is that it is
very efficient. Only for static messages though, but that's the whole idea on these special tags/ attributes anyway. But it realy shouldn't be a quick fix. IMO we should first improve the
general resource chain. Additional an text based filter in between would be very easy than. Juergen I don't know. If we can reach a consensus on the best way, I'd be okay
with adopting something that works out-of-the-box. If not, it's better to provide the means to customize Wicket so that it works like you want.
Eelco On 5/9/06, Andrew Berman [EMAIL PROTECTED] wrote:So are we saying that there is going to be some MarkupFilter to replace
whatever the developer decides to use for a localization demarcator? I had another idea.What if wicket:message was enhanced?Would something
like this work: wicket:message key=myKey applyTo=valueinput type=submit value=Previewable Value/
/wicket:message This way we could still have the previewability of the HTML page and havethe localization applied at runtime.
--Andrew On 5/9/06, Eelco Hillenius [EMAIL PROTECTED]
wrote: Martijn is writing about localization for Wicket In Action now. I'msure he'd appreciate it if someone would write up some notes about how
to do this on the WIKI. Eelco On 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote: Matej Knopp wrote: Juergen Donnerstag wrote: On 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote: $${key}? Or whatever you want. I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket lacks currently.
Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was evaluating this and it was not possible back then.
Anyway, it seems that markup filter should be enough. Unfortunately IMarkupFilter does not seem to be capable of replacing
things in RawMarkup elements, does it? So it seems not to be able to replace ${key} to localized value, or am I missing anything here?
?xml encoding=.. does complicate things a bit, but not much. What about load the ?xml line, determine encoding and loat the rest
of the file as string. Then let the preprocessor process it and then send it to MarkupParser? (Just a thoght).
-Matej That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the encoding, etc.. And it is trivial to register them with the application.
Juergen ---
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=kkid0709bid3057dat1642
___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
---
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

Re: [Wicket-user] Localization


Well, it looks that this is not as easy as it seemed to be.

I've made a MarkupFilter that translates the string. But I need
to give it ContainerInfo of current markup resource (same as 
WicketMessageTagHandler gets). The problem is that I can't touch markup 
(or markup.getResource) in my LocalizedMarkupParser#initFilterChain 
method (I derived my own parser from MarkupParser).


At least protected Markup MarkupParser.getMarkup() would help.

-Matej

Matej Knopp wrote:

Matej Knopp wrote:

Juergen Donnerstag wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.

Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was 
evaluating this and it was not possible back then.


Anyway, it seems that markup filter should be enough.

Unfortunately IMarkupFilter does not seem to be capable of replacing 
things in RawMarkup elements, does it? So it seems not to be able to 
replace ${key} to localized value, or am I missing anything here?


?xml encoding=.. does complicate things a bit, but not much. What 
about load the ?xml line, determine encoding and loat the rest of the 
file as string. Then let the preprocessor process it and then send it 
to MarkupParser? (Just a thoght).


-Matej


That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about
?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the
application.

Juergen


---
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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

this was never meant to be postprocessedusers are not meant to output wicket:i18n:key to the attribute using an attribute modifier and expect it to work.this was only meant as a preprocessing step toloading the markup. after that users are on their own.
of course then we need to figure out where the properties come from because you dont have the hierarchy yet? maybe this can wait until 2.0.-IgorOn 5/9/06,
Matej Knopp [EMAIL PROTECTED] wrote:Well, it looks that this is not as easy as it seemed to be.
I've made a MarkupFilter that translates the string. But I needto give it ContainerInfo of current markup resource (same asWicketMessageTagHandler gets). The problem is that I can't touch markup(or markup.getResource
) in my LocalizedMarkupParser#initFilterChainmethod (I derived my own parser from MarkupParser).At least protected Markup MarkupParser.getMarkup() would help.-MatejMatej Knopp wrote: Matej Knopp wrote:
Juergen Donnerstag wrote: On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote: $${key}? Or whatever you want. I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket lacks currently. Oh, stupid me. It is possible. Was it possible in 1.1 too? I guess I was
evaluating this and it was not possible back then. Anyway, it seems that markup filter should be enough. Unfortunately IMarkupFilter does not seem to be capable of replacing
things in RawMarkup elements, does it? So it seems not to be able to replace ${key} to localized value, or am I missing anything here? ?xml encoding=.. does complicate things a bit, but not much. What
about load the ?xml line, determine encoding and loat the rest of the file as string. Then let the preprocessor process it and then send it to MarkupParser? (Just a thoght).
-Matej That is true, we don't have something that allow to pre-processor the plain input string and IMO it is not needed and when I think about ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
similar function but are already aware of the xml structure, the encoding, etc.. And it is trivial to register them with the application. Juergen
--- 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=kkid0709bid3057dat1642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- 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=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user ---
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=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---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=lnkkid=120709bid=263057dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

If WicketMessageTagHandler can get resource.getContainerInfo(), why my 
filter can't?


There's something about this that doesn't make me feel entirely good. 
Why can't my filter get this information? Or even better, why can't my 
MarkupParser get this information? Is it /that/ internal?


IMHO sometimes wicket is being way too overprotective. Quite often when 
I want to implement something with wicket that is not common I get into 
this kind of situation. And sometimes it can be little bit frustrating.


-Matej

Igor Vaynberg wrote:

this was never meant to be postprocessed

users are not meant to output wicket:i18n:key to the attribute using an 
attribute modifier and expect it to work.


this was only meant as a preprocessing step toloading the markup. after 
that users are on their own.


of course then we need to figure out where the properties come from 
because you dont have the hierarchy yet? maybe this can wait until 2.0.


-Igor


On 5/9/06, * Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

Well, it looks that this is not as easy as it seemed to be.

I've made a MarkupFilter that translates the string. But I need
to give it ContainerInfo of current markup resource (same as
WicketMessageTagHandler gets). The problem is that I can't touch markup
(or markup.getResource ) in my LocalizedMarkupParser#initFilterChain
method (I derived my own parser from MarkupParser).

At least protected Markup MarkupParser.getMarkup() would help.

-Matej

Matej Knopp wrote:
  Matej Knopp wrote:
  Juergen Donnerstag wrote:
  On 5/9/06, Matej Knopp [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
  $${key}? Or whatever you want.
  I don't need this behavior to be in wicket core. I'm much more
  interested in clean and simple preprocessing filters,
something wicket
  lacks currently.
 
  Oh, stupid me. It is possible. Was it possible in 1.1 too? I
guess I was
  evaluating this and it was not possible back then.
 
  Anyway, it seems that markup filter should be enough.
 
  Unfortunately IMarkupFilter does not seem to be capable of replacing
  things in RawMarkup elements, does it? So it seems not to be able to
  replace ${key} to localized value, or am I missing anything here?
 
  ?xml encoding=.. does complicate things a bit, but not much.
What
  about load the ?xml line, determine encoding and loat the rest
of the
  file as string. Then let the preprocessor process it and then
send it
  to MarkupParser? (Just a thoght).
 
  -Matej
 
  That is true, we don't have something that allow to
pre-processor the
  plain input string and IMO it is not needed and when I think about
  ?xml encoding=..? it could be dangerous. IMarkupFilter serve a
  similar function but are already aware of the xml structure, the
  encoding, etc.. And it is trivial to register them with the
  application.
 
  Juergen
 
 
  ---
  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=kkid0709bid3057dat1642
http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
  ---
  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=lnkkid=120709bid=263057dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 
  ---
  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=lnkkid=120709bid=263057dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642

Re: [Wicket-user] Localization

the flipside is of course that we were able to refactor a ton without breaking too much api. you can argue that 1.2 has a lot of api breaks, but if you compare code in 1.2 to 1.1 they can almost be different frameworks.
-IgorOn 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
If WicketMessageTagHandler can get resource.getContainerInfo(), why myfilter can't?There's something about this that doesn't make me feel entirely good.Why can't my filter get this information? Or even better, why can't my
MarkupParser get this information? Is it /that/ internal?IMHO sometimes wicket is being way too overprotective. Quite often whenI want to implement something with wicket that is not common I get intothis kind of situation. And sometimes it can be little bit frustrating.
-MatejIgor Vaynberg wrote: this was never meant to be postprocessed users are not meant to output wicket:i18n:key to the attribute using an attribute modifier and expect it to work.
this was only meant as a preprocessing step toloading the markup. after that users are on their own. of course then we need to figure out where the properties come from because you dont have the hierarchy yet? maybe this can wait until
2.0. -Igor On 5/9/06, * Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Well, it looks that this is not as easy as it seemed to be.
I've made a MarkupFilter that translates the string. But I need to give it ContainerInfo of current markup resource (same as WicketMessageTagHandler gets). The problem is that I can't touch markup
(or markup.getResource ) in my LocalizedMarkupParser#initFilterChain method (I derived my own parser from MarkupParser). At least protected Markup MarkupParser.getMarkup() would help.
-Matej Matej Knopp wrote: Matej Knopp wrote: Juergen Donnerstag wrote: On 5/9/06, Matej Knopp
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: $${key}? Or whatever you want. I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket lacks currently. Oh, stupid me. It is possible. Was it possible in
1.1 too? I guess I was evaluating this and it was not possible back then. Anyway, it seems that markup filter should be enough. Unfortunately IMarkupFilter does not seem to be capable of replacing
things in RawMarkup elements, does it? So it seems not to be able to replace ${key} to localized value, or am I missing anything here? ?xml encoding=.. does complicate things a bit, but not much.
What about load the ?xml line, determine encoding and loat the rest of the file as string. Then let the preprocessor process it and then send it
to MarkupParser? (Just a thoght). -Matej That is true, we don't have something that allow to pre-processor the
plain input string and IMO it is not needed and when I think about ?xml encoding=..? it could be dangerous. IMarkupFilter serve a similar function but are already aware of the xml structure, the
encoding, etc.. And it is trivial to register them with the application. Juergen
--- 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=kkid0709bid3057dat1642 http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- 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=lnkkid=120709bid=263057dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- 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=lnkkid=120709bid=263057dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- Using Tomcat but need to do

Re: [Wicket-user] Localization


Yeah, Wicket is not perfect and neither are we. That's why we discuss
here and see whether we can reach common ground. Then everyone will be
happy! :)

Eelco

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:

the flipside is of course that we were able to refactor a ton without
breaking too much api. you can argue that 1.2 has a lot of api breaks, but
if you compare code in 1.2 to 1.1 they can almost be different frameworks.

-Igor



On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
 If WicketMessageTagHandler can get resource.getContainerInfo(), why my
 filter can't?

 There's something about this that doesn't make me feel entirely good.
 Why can't my filter get this information? Or even better, why can't my
 MarkupParser get this information? Is it /that/ internal?

 IMHO sometimes wicket is being way too overprotective. Quite often when
 I want to implement something with wicket that is not common I get into
 this kind of situation. And sometimes it can be little bit frustrating.

 -Matej

 Igor Vaynberg wrote:
  this was never meant to be postprocessed
 
  users are not meant to output wicket:i18n:key to the attribute using an
  attribute modifier and expect it to work.
 
  this was only meant as a preprocessing step toloading the markup. after
  that users are on their own.
 
  of course then we need to figure out where the properties come from
  because you dont have the hierarchy yet? maybe this can wait until 2.0.
 
  -Igor
 
 
  On 5/9/06, * Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
 
  Well, it looks that this is not as easy as it seemed to be.
 
  I've made a MarkupFilter that translates the string. But I need
  to give it ContainerInfo of current markup resource (same as
  WicketMessageTagHandler gets). The problem is that I can't touch
markup
  (or markup.getResource ) in my
LocalizedMarkupParser#initFilterChain
  method (I derived my own parser from MarkupParser).
 
  At least protected Markup MarkupParser.getMarkup() would help.
 
  -Matej
 
  Matej Knopp wrote:
Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters,
  something wicket
lacks currently.
   
Oh, stupid me. It is possible. Was it possible in 1.1 too? I
  guess I was
evaluating this and it was not possible back then.
   
Anyway, it seems that markup filter should be enough.
   
Unfortunately IMarkupFilter does not seem to be capable of
replacing
things in RawMarkup elements, does it? So it seems not to be
able to
replace ${key} to localized value, or am I missing anything
here?
   
?xml encoding=.. does complicate things a bit, but not much.
  What
about load the ?xml line, determine encoding and loat the rest
  of the
file as string. Then let the preprocessor process it and then
  send it
to MarkupParser? (Just a thoght).
   
-Matej
   
That is true, we don't have something that allow to
  pre-processor the
plain input string and IMO it is not needed and when I think
about
?xml encoding=..? it could be dangerous. IMarkupFilter
serve a
similar function but are already aware of the xml structure,
the
encoding, etc.. And it is trivial to register them with the
application.
   
Juergen
   
   
   
---
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=kkid0709bid3057dat1642
 
http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642

   
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
   
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
   
---
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=lnkkid=120709bid=263057dat=121642
 
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list

Re: [Wicket-user] Localization


Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part 
of Stable API, I take the risk of having to change my code when wicket 
version changes. I really don't mind.


What I do mind is the (occasional) lack of flexibility and things that 
keep me from extending the framework the way I want.


The truth is that this kind of protection doesn't work very well. When 
I was porting my application from 1.0 to 1.1, there were couple of 
things that didn't work and had to be redone. When porting the 
application from 1.1 to 1.2 things were even worse. The whole parsing 
process was changed and my code didn't work anymore (I had my own 
XMLPullParser that wrapped wicket default one). And I didn't touch any 
internal stuff.



-Matej

the flipside is of course that we were able to refactor a ton without 
breaking too much api. you can argue that 1.2 has a lot of api breaks, 
but if you compare code in 1.2 to 1.1 they can almost be different 
frameworks.


-Igor


On 5/9/06, *Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

If WicketMessageTagHandler can get resource.getContainerInfo(), why my
filter can't?

There's something about this that doesn't make me feel entirely good.
Why can't my filter get this information? Or even better, why can't my
MarkupParser get this information? Is it /that/ internal?

IMHO sometimes wicket is being way too overprotective. Quite often when
I want to implement something with wicket that is not common I get into
this kind of situation. And sometimes it can be little bit frustrating.

-Matej

Igor Vaynberg wrote:
  this was never meant to be postprocessed
 
  users are not meant to output wicket:i18n:key to the attribute
using an
  attribute modifier and expect it to work.
 
  this was only meant as a preprocessing step toloading the markup.
after
  that users are on their own.
 
  of course then we need to figure out where the properties come from
  because you dont have the hierarchy yet? maybe this can wait
until 2.0.
 
  -Igor
 
 
  On 5/9/06, * Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
 
  Well, it looks that this is not as easy as it seemed to be.
 
  I've made a MarkupFilter that translates the string. But I need
  to give it ContainerInfo of current markup resource (same as
  WicketMessageTagHandler gets). The problem is that I can't
touch markup
  (or markup.getResource ) in my
LocalizedMarkupParser#initFilterChain
  method (I derived my own parser from MarkupParser).
 
  At least protected Markup MarkupParser.getMarkup() would help.
 
  -Matej
 
  Matej Knopp wrote:
Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL 
PROTECTED]
  wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm
much more
interested in clean and simple preprocessing filters,
  something wicket
lacks currently.
   
Oh, stupid me. It is possible. Was it possible in 1.1 too? I
  guess I was
evaluating this and it was not possible back then.
   
Anyway, it seems that markup filter should be enough.
   
Unfortunately IMarkupFilter does not seem to be capable
of replacing
things in RawMarkup elements, does it? So it seems not to
be able to
replace ${key} to localized value, or am I missing
anything here?
   
?xml encoding=.. does complicate things a bit, but not
much.
  What
about load the ?xml line, determine encoding and loat
the rest
  of the
file as string. Then let the preprocessor process it and then
  send it
to MarkupParser? (Just a thoght).
   
-Matej
   
That is true, we don't have something that allow to
  pre-processor the
plain input string and IMO it is not needed and when I
think about
?xml encoding=..? it could be dangerous.
IMarkupFilter serve a
similar function but are already aware of the xml
structure, the
encoding, etc.. And it is trivial to register them with the
application.
   
Juergen
   
   
---
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

Re: [Wicket-user] Localization


Wicket really isn't perfect. But it's really getting closer and closer :)

-Matej

Eelco Hillenius wrote:

Yeah, Wicket is not perfect and neither are we. That's why we discuss
here and see whether we can reach common ground. Then everyone will be
happy! :)

Eelco

On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:

the flipside is of course that we were able to refactor a ton without
breaking too much api. you can argue that 1.2 has a lot of api breaks, 
but
if you compare code in 1.2 to 1.1 they can almost be different 
frameworks.


-Igor



On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
 If WicketMessageTagHandler can get resource.getContainerInfo(), why my
 filter can't?

 There's something about this that doesn't make me feel entirely good.
 Why can't my filter get this information? Or even better, why can't my
 MarkupParser get this information? Is it /that/ internal?

 IMHO sometimes wicket is being way too overprotective. Quite often when
 I want to implement something with wicket that is not common I get into
 this kind of situation. And sometimes it can be little bit frustrating.

 -Matej

 Igor Vaynberg wrote:
  this was never meant to be postprocessed
 
  users are not meant to output wicket:i18n:key to the attribute 
using an

  attribute modifier and expect it to work.
 
  this was only meant as a preprocessing step toloading the markup. 
after

  that users are on their own.
 
  of course then we need to figure out where the properties come from
  because you dont have the hierarchy yet? maybe this can wait until 
2.0.

 
  -Igor
 
 
  On 5/9/06, * Matej Knopp* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
 
  Well, it looks that this is not as easy as it seemed to be.
 
  I've made a MarkupFilter that translates the string. But I need
  to give it ContainerInfo of current markup resource (same as
  WicketMessageTagHandler gets). The problem is that I can't touch
markup
  (or markup.getResource ) in my
LocalizedMarkupParser#initFilterChain
  method (I derived my own parser from MarkupParser).
 
  At least protected Markup MarkupParser.getMarkup() would help.
 
  -Matej
 
  Matej Knopp wrote:
Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm 
much more

interested in clean and simple preprocessing filters,
  something wicket
lacks currently.
   
Oh, stupid me. It is possible. Was it possible in 1.1 too? I
  guess I was
evaluating this and it was not possible back then.
   
Anyway, it seems that markup filter should be enough.
   
Unfortunately IMarkupFilter does not seem to be capable of
replacing
things in RawMarkup elements, does it? So it seems not to be
able to
replace ${key} to localized value, or am I missing anything
here?
   
?xml encoding=.. does complicate things a bit, but not 
much.

  What
about load the ?xml line, determine encoding and loat the 
rest

  of the
file as string. Then let the preprocessor process it and then
  send it
to MarkupParser? (Just a thoght).
   
-Matej
   
That is true, we don't have something that allow to
  pre-processor the
plain input string and IMO it is not needed and when I think
about
?xml encoding=..? it could be dangerous. IMarkupFilter
serve a
similar function but are already aware of the xml structure,
the
encoding, etc.. And it is trivial to register them with the
application.
   
Juergen
   
   
   
---
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=kkid0709bid3057dat1642
 
http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642

   
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
  mailto:Wicket-user@lists.sourceforge.net
   
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
   
   
---
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=lnkkid=120709bid=263057dat=121642

Re: [Wicket-user] Localization


On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.


Well, not everyone agrees with you. Some people started to be
seriously grumpy about it the last two months.




- Hide quoted text -

What I do mind is the (occasional) lack of flexibility and things that
keep me from extending the framework the way I want.


The only thing that will not happen is if we know beforehand what that'll be.


The truth is that this kind of protection doesn't work very well. When
I was porting my application from 1.0 to 1.1, there were couple of
things that didn't work and had to be redone. When porting the
application from 1.1 to 1.2 things were even worse. The whole parsing
process was changed and my code didn't work anymore (I had my own
XMLPullParser that wrapped wicket default one). And I didn't touch any
internal stuff.


Imagine what it would have been like if we didn't protect so much.
Seriously, there would be no beginning to it as you probably would
have 'customized' it so much that there wouldn't be a start.

Furthermore - and I feel this is very important - the fact that we
have guys like you complaining about features and extension points you
miss, tells us (and the rest of the readers here) what kind of use
cases there may be and the discussion hopefully concludes in something
really usefull. It has been like that many times, and if we opened up
prematurely, you might have been able to profit from it from time to
time, but Wicket wouldn't have been as good.

So, I think we're doing just fine. We should look for something that
works good out of the box on top of extension points that are useful.

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=lnkkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization


Eelco Hillenius wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.


Well, not everyone agrees with you. Some people started to be
seriously grumpy about it the last two months.

Yeah, I can imagine. That was my opinion only.





- Hide quoted text -

What I do mind is the (occasional) lack of flexibility and things that
keep me from extending the framework the way I want.


The only thing that will not happen is if we know beforehand what 
that'll be.



The truth is that this kind of protection doesn't work very well. When
I was porting my application from 1.0 to 1.1, there were couple of
things that didn't work and had to be redone. When porting the
application from 1.1 to 1.2 things were even worse. The whole parsing
process was changed and my code didn't work anymore (I had my own
XMLPullParser that wrapped wicket default one). And I didn't touch any
internal stuff.


Imagine what it would have been like if we didn't protect so much.
Seriously, there would be no beginning to it as you probably would
have 'customized' it so much that there wouldn't be a start.
I don't think protection is entirely bad idea. I just think that 
sometimes the protection is taken too far.


Furthermore - and I feel this is very important - the fact that we
have guys like you complaining about features and extension points you
miss, tells us (and the rest of the readers here) what kind of use
cases there may be and the discussion hopefully concludes in something
really usefull. It has been like that many times, and if we opened up
prematurely, you might have been able to profit from it from time to
time, but Wicket wouldn't have been as good.
I can second this, I know that you don't ignore the feedback. It's just 
that sometimes I'd rather take the risk of being forced to redo 
something even if the minor version changes, rather than not be able to 
do the thing at all.


So, I think we're doing just fine. We should look for something that
works good out of the box on top of extension points that are useful.

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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

Anyway, I don't want to sound grumpy or bitter. I really do appreciate 
all the hard work you guys do on Wicket. Wicket has made an incredible 
progress and I really like the way it's heading.


I'm using wicket for almost year and half now and it seems that I'm not 
going to abandon it any soon :)


-Matej

Matej Knopp wrote:

Eelco Hillenius wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.


Well, not everyone agrees with you. Some people started to be
seriously grumpy about it the last two months.

Yeah, I can imagine. That was my opinion only.





- Hide quoted text -

What I do mind is the (occasional) lack of flexibility and things that
keep me from extending the framework the way I want.


The only thing that will not happen is if we know beforehand what 
that'll be.



The truth is that this kind of protection doesn't work very well. When
I was porting my application from 1.0 to 1.1, there were couple of
things that didn't work and had to be redone. When porting the
application from 1.1 to 1.2 things were even worse. The whole parsing
process was changed and my code didn't work anymore (I had my own
XMLPullParser that wrapped wicket default one). And I didn't touch any
internal stuff.


Imagine what it would have been like if we didn't protect so much.
Seriously, there would be no beginning to it as you probably would
have 'customized' it so much that there wouldn't be a start.
I don't think protection is entirely bad idea. I just think that 
sometimes the protection is taken too far.


Furthermore - and I feel this is very important - the fact that we
have guys like you complaining about features and extension points you
miss, tells us (and the rest of the readers here) what kind of use
cases there may be and the discussion hopefully concludes in something
really usefull. It has been like that many times, and if we opened up
prematurely, you might have been able to profit from it from time to
time, but Wicket wouldn't have been as good.
I can second this, I know that you don't ignore the feedback. It's just 
that sometimes I'd rather take the risk of being forced to redo 
something even if the minor version changes, rather than not be able to 
do the thing at all.


So, I think we're doing just fine. We should look for something that
works good out of the box on top of extension points that are useful.

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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization

Eelco Hillenius wrote: On 5/9/06, Matej Knopp 
[EMAIL PROTECTED] wrote: Igor Vaynberg wrote: I don't mind API breaks. Not at all. If I touch code that is not a part of Stable API, I take the risk of having to change my code when wicket
 version changes. I really don't mind.hey!! i didnt write that!!-Igor

Re: [Wicket-user] Localization

2006-05-09 Thread Ittay Dror




Eelco Hillenius wrote:

On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.


Well, not everyone agrees with you. Some people started to be
seriously grumpy about it the last two months.


for what it's worth, as a user, i *would* like API to change, if it means a 
more natural API and functionality. wicket is great, but i feel the 
API/functionality is not mature, in the sense that when i look in the code, 
some things feel hackish.

can't refactoring tools help? maybe provide a wicket-compatability package 
(jar)?






- Hide quoted text -

What I do mind is the (occasional) lack of flexibility and things that
keep me from extending the framework the way I want.


The only thing that will not happen is if we know beforehand what 
that'll be.



The truth is that this kind of protection doesn't work very well. When
I was porting my application from 1.0 to 1.1, there were couple of
things that didn't work and had to be redone. When porting the
application from 1.1 to 1.2 things were even worse. The whole parsing
process was changed and my code didn't work anymore (I had my own
XMLPullParser that wrapped wicket default one). And I didn't touch any
internal stuff.


Imagine what it would have been like if we didn't protect so much.
Seriously, there would be no beginning to it as you probably would
have 'customized' it so much that there wouldn't be a start.

Furthermore - and I feel this is very important - the fact that we
have guys like you complaining about features and extension points you
miss, tells us (and the rest of the readers here) what kind of use
cases there may be and the discussion hopefully concludes in something
really usefull. It has been like that many times, and if we opened up
prematurely, you might have been able to profit from it from time to
time, but Wicket wouldn't have been as good.

So, I think we're doing just fine. We should look for something that
works good out of the box on top of extension points that are useful.

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=kkid0709bid3057dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




--
===
Ittay Dror 
Chief architect, openQRM TL, 
RD, Qlusters Inc.

[EMAIL PROTECTED]
+972-3-6081994 Fax: +972-3-6081841

http://www.openQRM.org
- Keeps your Data-Center Up and Running


---
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=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Localization