I think that this would be very useful, as we are trying to use a single app
with different "skins", which could potentially involve very different page
layouts for essentially the same info...

Cheers,

nick

-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 16, 2002 7:28 AM
To: Struts Developers List
Subject: Re: i18n Forwards


Yunfeng Hou wrote:
>
> Yes, you can get it from request.
>
> And, comitters, what's your opinion about i18n
> forwards?
> Because sometimes i18n enabled message can only solve
> part of the problem to build a multi-language site, it
> may require totally different layout for different
> language, so if we have i18n forwards will be a big
> help.
>

What I was thinking of originally was an approach to creating dynamic
forwards, which could help with several things, including i18n, browser
detection, multiple platforms, et cetera.

I'm also thinking it can help with bookmarking and some circumstances
where there is a "base forward" that needs some additional information
at runtime. This could be a path to an alternate page (i18n, browser
platform) or it could be something like a record number (bookmark).

I'm doing things like this now by hand, but it would be better to
generalize into the forward object. For example, I wanted to create a
common control that would search various tables by "name" or "number"
but the actual field names varied from table to table.

In the HTML control, I used "forward" as a switch to select the table,
and "name" for the HTTP parameter/form bean property where they put in
the search string.

<html:form action="/search/Name">
<tr bgcolor="#FFFFFF">
<td nowrap>Find by name: </td>
<td nowrap>
<select size="1" name="forward"
onchange="document.forms[1].elements[1].focus()">
<option value="done">-- select --</option>
<option value="prospect">Prospect</option>
<option value="donor">Donor</option>
<option value="item">Item</option>
<option value="script">Script</option>
</select>
<input type="text" name="name" size="10" maxlength="30">
<html:submit>GO</html:submit>
</td>
</tr>
</html:form>

in the struts-config, I setup a forwarding action like this:

   <action
        path="/search/Name"
        type="app.Parameter"
        name="searchForm"
        scope="request"
        validate="false"
        parameter="name">
        <forward
            name="prospect"
            path="/do/prospect/SearchName?fullName="/>
        <forward
            name="item"
            path="/do/item/SearchName?name="/>
        <forward
            name="donor"
            path="/do/donor/SearchName?fullName="/>
        <forward
            name="script"
            path="/do/script/SearchTitle?title="/>
        <forward
            name="done"
            path="/do/Menu?name="/>
    </action>

and then sent it over to an Action like this:

     public ActionForward perform(
         ActionMapping mapping,
         ActionForm form,
         HttpServletRequest request,
         HttpServletResponse response) {

            // Get "forward" parameter
        String parameter = request.getParameter(Tokens.FORWARD);
            // Get parameter name for this mapping
        String paramName = mapping.getParameter();

        StringBuffer path = new StringBuffer(64);

            // Get stub URI from mapping (/do/whatever?paramName=)
        path.append(mapping.findForward(parameter).getPath());
            // Append the value passed
(/do/whatever?paramName=paramProperty)
        path.append(request.getParameter(paramName));

            // Return a new forward based on stub+value
        return new ActionForward(path.toString());

    }

People go through gymnastics like this all the time. So I'm thinking an
generalized solution to i18n, platform, and runtime customization is a
"dynamic" or "smart" forward, that can merge a forward with runtime
data.


-------- Original Message --------
Subject: Re: i18n Forwards
Date: Fri, 14 Dec 2001 16:05:20 -0800 (PST)
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>

On Fri, 14 Dec 2001, Ted Husted wrote:

> Date: Fri, 14 Dec 2001 18:18:18 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: i18n Forwards
>
> Have we ever talked about a standard subclass for ActionForward that
> would automatically expand a path based on the user's locale. I'm pretty
> sure this has come up on the user list, where people were changing the
> forward dynamically in the Action. But maybe we should have a standard
> ActionForward subclass so that you could do like
>
> <forward name="whatever" path="\pages\{*}\whatever.jsp" locale="true"/>
>
> and have it expand to
>
> \pages\es\whatever.jsp or
> \pages\en\whatever.jsp
>
> at runtime.
>
> Or is that too application specific?
>
> The message resources are great for cobbling together messages, but I
> doubt that it would be a good solution for larger sites.
>
> But then, what do I know about i18n projects ;-)
>

I like the idea.

I think the Apache pattern is to add a Locale suffix
(/pages/whatever.jsp
--> /pages/whatever.jsp.es).  This would probably not work well when JSP
pages are extension mapped, but using a replacement pattern lets the
user
configure this to match their own environment.

I would suggest the following as implementation considerations:

* We can just make the existing ActionForward class smarter by adding
  a Locale property that defaults to "false".

* IMHO, the existing "path" property getter method should continue to
  return the pattern itself.

* We would add new getPath(Locale locale) method (or some such) that
  performs the replacement if locale is true, or the value of getPath()
  if locale is false.

* Perhaps the replacement code in the pattern should be {0} so that it
  acts like internationalized message strings in resource bundles?

Craig

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to