Laurent PETIT wrote:
Hello,
On 11/9/05, Juergen Donnerstag [EMAIL PROTECTED] wrote:
You mean for tag text, correct? span wicket:message=hello.message /
What do you think about wicket:message key=../. Than it is clear
that the whole label is wicket specific,
This sounds quite
Juergen Donnerstag wrote:
I've implemented it last night. Was fairly easy. I'll commt it tonight.
wicket:message key=my-keyDefault value/wicket:message
input wicket:message=attrName=my-key type=.../
Heh, excellent, I think the above two will cover pretty much the cases
where it doesn't
Andrew Berman wrote:
I think the attribute feature should be removed. I think it is just
un-Wicket-like, and I think others agree as I read form the emails in
this thread. As I mentioned before I think when it comes to attributes,
it is best to just do it from within the component
I think maybe what we need to do is keep a list of default behaviours
in application somewhere, and those get added to every new component.
maybe not a list but a callback much like the iauthorizationpolicy does
now.
Application.initializeComponent(Component c)
that way you can add an attr
the whole idea is of this thread that we don't want to have to add all kind of components on every place
to localize youre html of all youre labels.
I do see a good reason for that (maybe you as an american don's use i18n a lot ;))
Now i have slept a night over it i think we need to keep it
Every time we're running into syntax discussions (see 'replacing OGNL') I feel
that Wicket is deviating from the Java way.
I think all the following suggestions would better be left unimplemented:
input wicket:message=value=my-key type=.../
input wicket:message=value=my-key,
[EMAIL PROTECTED] wrote:
Every time we're running into syntax discussions (see 'replacing OGNL') I feel
that Wicket is deviating from the Java way.
I think all the following suggestions would better be left unimplemented:
input wicket:message=value=my-key type=.../
input
+1
-Igor
On 11/9/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I think wicket:message key=../ would fit well with our other wicket tags, e.g wicket:panel.IMHO such an addition would be very useful.SvenYou mean for tag text, correct? span wicket:message=
hello.message /What do you think about
I've implemented it last night. Was fairly easy. I'll commt it tonight.
wicket:message key=my-keyDefault value/wicket:message
input wicket:message=attrName=my-key type=.../
As wicket core is very much pluggable, it can easily be added / removed.
Juergen
On 11/9/05, Igor Vaynberg [EMAIL
First draft version available in CVS HEAD
Juergen
On 11/10/05, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I've implemented it last night. Was fairly easy. I'll commt it tonight.
wicket:message key=my-keyDefault value/wicket:message
input wicket:message=attrName=my-key type=.../
As wicket
Jeurgen,
I think the attribute feature should be removed. I
think it is just un-Wicket-like, and I think others agree as I read
form the emails in this thread. As I mentioned before I think
when it comes to attributes, it is best to just do it from within the
component manually instead of the
I think/ agree that while Wicket's strong point lies in the fact that
we keep things clean and code-centric, having easy localized string
replacement without going through the whole requirement of having
Wicket components in a matching hierarchy is a very good exception to
the rule.
Eelco
On
I'm all for making things easier for the user.
Perhaps Wicket could have something like this:
span wicket:id=message:myLabelHere/span
I'm not sure this makes sense. wicket:id is not a text to be displayed
anywhere. It is a name which identifies a component. It definitely
won't work.
Even
Juergen Donnerstag wrote:
I'm all for making things easier for the user.
Perhaps Wicket could have something like this:
span wicket:id=message:myLabelHere/span
I'm not sure this makes sense. wicket:id is not a text to be displayed
anywhere. It is a name which identifies a component.
You mean for tag text, correct? span wicket:message=hello.message /
What do you think about wicket:message key=../. Than it is clear
that the whole label is wicket specific,
span wicket:message=key is a bit dangerous because how would we
handle span wicket:id=myLabel wicket:message=key?
Thanks for the response.
How are your questions related to i18n messages?
Sorry I missunderstood the i18n question. I read the preprocessing of the
tag-body you mentioned and thought - well the wrong thing.
Thanks,
Christian
I think wicket:message key=../ would fit well with our other wicket tags,
e.g wicket:panel.
IMHO such an addition would be very useful.
Sven
You mean for tag text, correct? span wicket:message=hello.message /
What do you think about wicket:message key=../. Than it is clear
that the whole
I like wicket:message key=../ as long as it would work how normal JSP tags currently work. In other words, I would be able to do this:input type=button value=wicket:message key='labelKey'//
orscript alert(wicket:message key='labelKey'/);/script--AndrewOn 11/9/05,
[EMAIL PROTECTED] [EMAIL
On 11/9/05, Andrew Berman [EMAIL PROTECTED] wrote:
I like wicket:message key=../ as long as it would work how normal JSP
tags currently work. In other words, I would be able to do this:
input type=button value=wicket:message key='labelKey'//
or
script
alert(wicket:message
Oh and the other nice feature would be that if you do it like this: wicket:message key=..My Text/wicket that the My Text would be the default text if the key is not found.
On 11/9/05, Andrew Berman [EMAIL PROTECTED] wrote:
Well, I guess not being able to do it in _javascript_ would be ok, but I
i can live with:
wicket:message key=..Default Text/wicket:message
and
input type=button value=message:key=my-key/
But i think the second one will be pretty hard.
Because then we have to parse the complete xml and see if in any attribute something starts with message:key
even for non wicket
wicket:message key=..Default Text/wicket:message
and
input type=button value=message:key=my-key/
But i think the second one will be pretty hard.
Because then we have to parse the complete xml and see if in any attribute
something starts with message:key
even for non wicket tags as
Hmmmwell, I do think it would provide value to have the attribute
way as well. How much slower do you think it is going to make it?
Anyone else have any suggestions?
--AndrewOn 11/9/05, Johan Compagner
[EMAIL PROTECTED] wrote:i can live with:
wicket:message key=..Default
We have different options (as explained in my first mail)
- do the replacement while loading the markup, prior to xml reading
it. The cached version will have the messages replaced
- analyze the attributes while reading xml. The cached version will
have the messages replaced for the attrbutes.
if you do the replacement at parse time.
then every html in the markup cache is specified by a locale?
(even if there is not locale in the name of the html)
To me it looks like that wicket:message can only be executed at runtime because then the locale is know
But we could store one for every
Johan Compagner wrote:
i can live with:
wicket:message key=..Default Text/wicket:message
This makes sense.
input type=button value=message:key=my-key/
I don't think this one does. It breaks the previewability of pages
which is one of Wicket's hallmarks.
How about something like
On 11/9/05, Johan Compagner [EMAIL PROTECTED] wrote:
if you do the replacement at parse time.
then every html in the markup cache is specified by a locale?
(even if there is not locale in the name of the html)
Thats already the case. The markup id includes locale style etc. But
multiple
good idea, except I would like to make a =. wicket:i18n=value=my-key
Juergen
On 11/9/05, Scott Sauyet [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
i can live with:
wicket:message key=..Default Text/wicket:message
This makes sense.
input type=button value=message:key=my-key/
I
ok then pre process and do it at markup loading time.
The only problem i see with this then that people will start to complaind that they don't
see changes when they alter there messages
So suddenly we also have to watch those??
johan
On 11/9/05, Juergen Donnerstag [EMAIL PROTECTED] wrote:
On
then call it wicket:message=value=my-key
so that
wicket:message key=..Default Text/wicket:message
and
input type=button value=My Val wicket:message=value=my-key/
uses the same kind of notation.
Als value=My Val can then be seen as the default value if the value is not found for the given
Thats an RFE already. I'm not yet sure what the best approach is. Just thinking.
Juergen
On 11/9/05, Johan Compagner [EMAIL PROTECTED] wrote:
ok then pre process and do it at markup loading time.
The only problem i see with this then that people will start to complaind
that they don't
see
yesm true. do you prefer wicket:mesage or wicket:i18n?
Juergen
On 11/9/05, Johan Compagner [EMAIL PROTECTED] wrote:
then call it wicket:message=value=my-key
so that
wicket:message key=..Default Text/wicket:message
and
input type=button value=My Val wicket:message=value=my-key/
One more idea. How about using some reserved word for wicket:id. Like this:
span wicket:id=$somereservedword$ value=message:key1 alt=message:key2/
This would create an automatic component (with a behaviour) that scans all attributes and does its magic. This could be easily extended to other
can't say i have a real preference.
Somehow wicket:message looks better because i18n looks like capitals
But that is just a feeling.
And i still don't know if it is i18n or should it be l10n? (localisation)
Because you do Localize youre page itself. But the template is maybe i18n
On 11/9/05,
Other way of handle tranlations can be take and aproach simiar to Qt ui tollkit
i try to explain it a bit
whe you localiced and application all string in html are desired to be translate
we can parser html files and assign and unique id to each string to be
translate
provide a singuel file for
Problem with that is that input type=button value=wicket:message
key='labelKey'// is not valid xml.
Eelco
On 11/9/05, Andrew Berman [EMAIL PROTECTED] wrote:
I like wicket:message key=../ as long as it would work how normal JSP
tags currently work. In other words, I would be able to do this:
Hello,
What about something like that:
Use one of the two forms (both could be allowed):
wicket:label key=my.msg.keyA text to render/wicket:label
or
wicket:labelmy.msg.key/wicket:label
Of course, this introduces a new element in the wicket namespace ...
Or something like that:
span
2005/11/9, Andrew Berman [EMAIL PROTECTED]:
Oh and the other nice feature would be that if you do it like this: wicket:message key=..My Text/wicket that the My Text would be the default text if the key is not found.
How about using the content as the key wicket:messagekeyLabel/wicket:message?
just realized its not going to work in a hierarchy of components never mind
-Igor
On 11/9/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
oh and btw, rendering the same component more then once on a page will
throw HEAD into an infinite loop while it works quiet well in 1.0 and
1.1. Should i write
You cannot really compare wicket to tapestry. Although they are both
component oriented frameworks, they have completely different
approaches. In wicket the focus is on java code not on the template.
Wicket templates are simple and limited (purposefully) where as
tapestry allows for a lot more
oh and btw, rendering the same component more then once on a page will
throw HEAD into an infinite loop while it works quiet well in 1.0 and
1.1. Should i write up a bug or is this part of someone's work in
progress?
-Igor
On 11/9/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
Hmm
isnt all this
Hmm
isnt all this already possible without having to do anything?
public class Message extends WebMarkupContainer
{
public Message(String id)
{
super(id);
}
protected void onComponentTagBody(MarkupStream markupStream, ComponentTag openTag)
{
ValueMap attrs=openTag.getAttributes();
if
Johan Compagner wrote:
then call it wicket:message=value=my-key
so that
wicket:message key=..Default Text/wicket:message
and
input type=button value=My Val wicket:message=value=my-key/
uses the same kind of notation.
I can't decide if I like this idea or not. I like the idea of having as
I think this is starting to get all out of hand and when I suggested
this whole thing I didn't think it was going to be crazy like
this. Perhaps the attribute thing is best left to doing it the
normal Wicket way. I think the only thing I really need for i18n
in terms of changing attributes is for
Most of em do, though we all have kind of our different 'expertises'.
The currently active developers are yours truly, Juergen, Johan, Igor
and Martijn, though Martijn is mainly doing site/ builds/ promotion
etc. Gwyn is the man for Wiki. Jonathan is not really active, but does
some work in the
45 matches
Mail list logo
