You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Kare Nuorteva <ka...@satama.com> on 2000/12/13 14:11:45 UTC
i18n and
Hello,
I encountered little bug in <form:html> tag. When a user loads the front
page of a localised application (has loaded it directly, not via
controller servlet) then the default locale is used.
I would be quote trivial to copy+paste the logic from
ActionServlet.processLocale(HttpServletRequest) to HtmlTag. Thought,
better solution could be to move processLocale(HttpServletRequest) to
class org.apache.struts.util.LocaleUtils.
This way, the ActionServlet and HtmlTag could share the same business
logic.
Cheers,
Kare 8^)
--
Kare Nuorteva, Software Engineer
Satama UK Ltd
mobile +44 7989 852 865
http://www.satama.co.uk/
Re: i18n and
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Kare,
Have a look at Craig's response to my "When locale negociation should
occur?" post, yesterday for a first solution.
> I encountered little bug in <form:html> tag. When a user loads the front
> page of a localised application (has loaded it directly, not via
> controller servlet) then the default locale is used.
>
> I would be quote trivial to copy+paste the logic from
> ActionServlet.processLocale(HttpServletRequest) to HtmlTag. Thought,
> better solution could be to move processLocale(HttpServletRequest) to
> class org.apache.struts.util.LocaleUtils.
> This way, the ActionServlet and HtmlTag could share the same business
> logic.
Pierre Métras
Re: i18n and
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Craig,
> And saying:
>
> <%@ taglib uri="/WEB-INF/struts-form.tld" prefix="form" %>
> <form:html locale="true">
>
> ... my localized content that does not include a form ...
>
> </form:html>
>
> does what you want, no?
>
> All that is directly rendered is the usual <html> tag at the top, and
</html>
> tag at the bottom -- the side effect is that Locale processing (from the
request
> headers) is done in the same way that the controller servlet would have
done
> it. There is no HTML <form> tag involved.
It was late yesterday night, and I missed <form:html> for <form:form>. Yes,
your solution is what we need.
Pierre Métras
Re: i18n and
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Pierre Métras wrote:
> Hi Craig,
>
> >
> > Isn't the current implementation a variation on your second suggestion
> already?
> > I chose to make it an attribute of a tag (<form:html>) that you are
> probably
> > using already, instead of an additional tag that needs to be remembered.
> >
> > It seems like overkill to add the logic to every tag that might need it,
> when
> > you can limit the overhead to once per page by using a tag that is only
> used
> > once. And that is clearly the case for the <form:html> tag.
>
> You can have pages where you don't have forms.
> For instance, my application first page is a graphical menu and I don't want
> to include a form only to allow the user to bookmark that page and have the
> right locale selected.
>
Agreed.
And saying:
<%@ taglib uri="/WEB-INF/struts-form.tld" prefix="form" %>
<form:html locale="true">
... my localized content that does not include a form ...
</form:html>
does what you want, no?
All that is directly rendered is the usual <html> tag at the top, and </html>
tag at the bottom -- the side effect is that Locale processing (from the request
headers) is done in the same way that the controller servlet would have done
it. There is no HTML <form> tag involved.
The net result is that you can get the correct language (based on the user's
configured preferences) even if they bookmark a JSP page rather than a URL that
goes through the controller.
>
> Pierre Métras
Craig
Re: i18n and (change it!)
Posted by Michael Westbay <we...@seaple.icc.ne.jp>.
Compagner-san wrote:
> Change it!
> Got my vote!
>
> 2 options are still open for me:
>
> struts-forms: Only form specifiek and struts-html: other besides form.
> or
> struts-html: All including forms.
I agree, now is the time.
I would lean toward the second option as it would make porting easier. And as
McClanahan-san mentioned, it would leave struts-form open to something else like
XForm. (But then again, why not struts-xform for that?)
The major benifit from the first option, a separate form-centric taglib would be
to distinguish those things that can ONLY be found within <form:form>...
</form:form> tags from the rest of the HTML tags - which can go anywhere. (But
then again, if you break the tags up that far, would you go to breaking up
header-centric, body-centric, and frame-centric tags into other libraries as
well?)
Hmm. I contridict myself twice in one message. After due deliberation with
myself, I think that now I'm agreeing more with Compagner-san, struts-html AND
struts-forms, even with the additional porting task, would be the best bet.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re: i18n and (change it!)
Posted by Johan Compagner <jc...@j-com.nl>.
Change it!
Got my vote!
2 options are still open for me:
struts-forms: Only form specifiek and struts-html: other besides form.
or
struts-html: All including forms.
The first approache is in my eyes slightly better but if you think struts-forms can
be used better for something else then use the second one.
Johan
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Wednesday, December 27, 2000 7:07 PM
Subject: Re: i18n and <form:html>
> Johan Compagner wrote:
>
> > The naming convention is a bit strange the form tag lib that has also other things
> > that can be used besides forms. Maybe there should be a html tag lib for link/img/html ect ect.
> > and the form tag lib contains only tag's about forms.
> >
>
> Yah, I've been thinking about this bit of ugliness quite a bit.
>
> In retrospect, it would have been better to call this tag library "struts-html" instead of
> "struts-form", because nearly all of the rendering tags are HTML-specific. It would also leave the
> name "struts-form" open for potential use with a library that is totally devoted to XForms or
> something like that.
>
> There is still time to make that change before 1.0 -- and if we are ever going to, now is
> definitely the time.
>
> What do you think?
>
> >
> > johan
>
> Craig
>
>
>
Re: i18n and
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Johan Compagner wrote:
> The naming convention is a bit strange the form tag lib that has also other things
> that can be used besides forms. Maybe there should be a html tag lib for link/img/html ect ect.
> and the form tag lib contains only tag's about forms.
>
Yah, I've been thinking about this bit of ugliness quite a bit.
In retrospect, it would have been better to call this tag library "struts-html" instead of
"struts-form", because nearly all of the rendering tags are HTML-specific. It would also leave the
name "struts-form" open for potential use with a library that is totally devoted to XForms or
something like that.
There is still time to make that change before 1.0 -- and if we are ever going to, now is
definitely the time.
What do you think?
>
> johan
Craig
Re: i18n and
Posted by Johan Compagner <jc...@j-com.nl>.
> > Isn't the current implementation a variation on your second suggestion
> already?
> > I chose to make it an attribute of a tag (<form:html>) that you are
> probably
> > using already, instead of an additional tag that needs to be remembered.
> >
> > It seems like overkill to add the logic to every tag that might need it,
> when
> > you can limit the overhead to once per page by using a tag that is only
> used
> > once. And that is clearly the case for the <form:html> tag.
>
> You can have pages where you don't have forms.
> For instance, my application first page is a graphical menu and I don't want
> to include a form only to allow the user to bookmark that page and have the
> right locale selected.
But you can use <form:html> tag in a jsp page that doesn't have forms.
the form tags lib has more of those: like link
The naming convention is a bit strange the form tag lib that has also other things
that can be used besides forms. Maybe there should be a html tag lib for link/img/html ect ect.
and the form tag lib contains only tag's about forms.
johan
Re: i18n and
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Craig,
>
> Isn't the current implementation a variation on your second suggestion
already?
> I chose to make it an attribute of a tag (<form:html>) that you are
probably
> using already, instead of an additional tag that needs to be remembered.
>
> It seems like overkill to add the logic to every tag that might need it,
when
> you can limit the overhead to once per page by using a tag that is only
used
> once. And that is clearly the case for the <form:html> tag.
You can have pages where you don't have forms.
For instance, my application first page is a graphical menu and I don't want
to include a form only to allow the user to bookmark that page and have the
right locale selected.
Pierre Métras
Re: i18n and
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Pierre Métras wrote:
> Hi Craig,
>
> I'm not sure that this solution is a good one. It should be implemented in
> every Struts tag that can depend on a locale, such as <bean:message />,
> because you can have a user bookmark a page without a form but with
> messages.
>
> So either you add the "locale" attribute in every tag whose output depend on
> the locale (but it would generate a locale check in every tag of the page),
> else you extract that attribute from the <form:form> and you put it in a
> specialized tag, for instance <i18n:locale key="org.apache.struts.LOCALE" />
> that can be used in pages where you want to support locale change.
>
Isn't the current implementation a variation on your second suggestion already?
I chose to make it an attribute of a tag (<form:html>) that you are probably
using already, instead of an additional tag that needs to be remembered.
It seems like overkill to add the logic to every tag that might need it, when
you can limit the overhead to once per page by using a tag that is only used
once. And that is clearly the case for the <form:html> tag.
>
> Pierre Métras
>
Craig
>
> > I just committed a patch to implement this. Now you can say
> >
> > <form:html locale="true">
> > ...
> > </form:html>
> >
> > and have the Locale set (if necessary), even if the user starts at a JSP
> page
> > instead of going through the controller servlet.
> >
> > Craig
> >
> >
> > Kare Nuorteva wrote:
> >
> > > Hello,
> > >
> > > I encountered little bug in <form:html> tag. When a user loads the front
> > > page of a localised application (has loaded it directly, not via
> > > controller servlet) then the default locale is used.
> > >
> > > I would be quote trivial to copy+paste the logic from
> > > ActionServlet.processLocale(HttpServletRequest) to HtmlTag. Thought,
> > > better solution could be to move processLocale(HttpServletRequest) to
> > > class org.apache.struts.util.LocaleUtils.
> > > This way, the ActionServlet and HtmlTag could share the same business
> > > logic.
> > >
> > > Cheers,
> > > Kare 8^)
> > >
> > > --
> > > Kare Nuorteva, Software Engineer
> > > Satama UK Ltd
> > > mobile +44 7989 852 865
> > > http://www.satama.co.uk/
> >
> >
Re: i18n and
Posted by Pierre Métras <ge...@sympatico.ca>.
Hi Craig,
I'm not sure that this solution is a good one. It should be implemented in
every Struts tag that can depend on a locale, such as <bean:message />,
because you can have a user bookmark a page without a form but with
messages.
So either you add the "locale" attribute in every tag whose output depend on
the locale (but it would generate a locale check in every tag of the page),
else you extract that attribute from the <form:form> and you put it in a
specialized tag, for instance <i18n:locale key="org.apache.struts.LOCALE" />
that can be used in pages where you want to support locale change.
Pierre Métras
> I just committed a patch to implement this. Now you can say
>
> <form:html locale="true">
> ...
> </form:html>
>
> and have the Locale set (if necessary), even if the user starts at a JSP
page
> instead of going through the controller servlet.
>
> Craig
>
>
> Kare Nuorteva wrote:
>
> > Hello,
> >
> > I encountered little bug in <form:html> tag. When a user loads the front
> > page of a localised application (has loaded it directly, not via
> > controller servlet) then the default locale is used.
> >
> > I would be quote trivial to copy+paste the logic from
> > ActionServlet.processLocale(HttpServletRequest) to HtmlTag. Thought,
> > better solution could be to move processLocale(HttpServletRequest) to
> > class org.apache.struts.util.LocaleUtils.
> > This way, the ActionServlet and HtmlTag could share the same business
> > logic.
> >
> > Cheers,
> > Kare 8^)
> >
> > --
> > Kare Nuorteva, Software Engineer
> > Satama UK Ltd
> > mobile +44 7989 852 865
> > http://www.satama.co.uk/
>
>
Re: i18n and
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
I just committed a patch to implement this. Now you can say
<form:html locale="true">
...
</form:html>
and have the Locale set (if necessary), even if the user starts at a JSP page
instead of going through the controller servlet.
Craig
Kare Nuorteva wrote:
> Hello,
>
> I encountered little bug in <form:html> tag. When a user loads the front
> page of a localised application (has loaded it directly, not via
> controller servlet) then the default locale is used.
>
> I would be quote trivial to copy+paste the logic from
> ActionServlet.processLocale(HttpServletRequest) to HtmlTag. Thought,
> better solution could be to move processLocale(HttpServletRequest) to
> class org.apache.struts.util.LocaleUtils.
> This way, the ActionServlet and HtmlTag could share the same business
> logic.
>
> Cheers,
> Kare 8^)
>
> --
> Kare Nuorteva, Software Engineer
> Satama UK Ltd
> mobile +44 7989 852 865
> http://www.satama.co.uk/