Rick,
I would say that the concept you propose is VERY interesting to me
except that in order to work for us would need to allow for:
@ResouceBundle( "MyResourceBundleName" )
@UrlBinding( "/${bundleKey}/${event}/{$id} )
Notice NO "/m" on the UrlBinding i.e. that the root URI prefix is not
required to be fixed.
The other thing to note is that the above annotation structure might
apply to other things like "groups", "forums", etc... as such this would
mean that unless there is additional differentiation embedded in the
resource bundles you would need to define separate resource bundles for
each ActionBean. The only problem with the latter is that there you
would have M X N resource bundles to manage were M is #ActionBeans and N
is #Languages... which can be unwieldy.
Now using the example you gave I wonder if the following would work:
MyResourceBundleName_es_MX.properties
--------------------------------------------------------------------------------------------------------------------
MemberActionBean.bundleKey={miembro=member}
MemberActionBean.event={ver=view | enregistrar=save}
GroupActionBean.bundleKey={groupo=group}
GroupActionBean.event={ver=view | enregistrar=save}
Lastly, it would be nice to have the localized values from the resource
bundle available to the bean for formulating redirect responses e.g.
bundleKey=miembro
Most frameworks today only provide a minimal localization solution i.e.
the part that deals with messsages and resource bundles... it would
really be great if Stripes could provide a complete localization
solution and that involves URLs as well b/c lets face it full or
complete localization does not assume just the content of the responses
/ pages are localized but also the requests / URLs... .
--Nikolaos
Rick Grashel wrote:
I really think including localization use cases in the UrlBinding is
bad. However, if it absolutely must be done, then it should be done
according to appropriate Java standards. Hardcoding localization
strings in compiled code is really not appropriate.
If it absolutely had to be done, then the following would be much more
appropriate:
First, a new "special" value (like ${event}) should be created which
indicates that the passed value should be used as a key to look up in
a resource bundle. For example, ${bundleKey}.
Second, a new annotation should be provided at the ActionBean level to
allow the developer to specify what resource bundle the ActionBean
should use for lookups.
Then, you would end up with the following at the top of an action bean:
@ResouceBundle( "MyResourceBundleName" )
@UrlBinding( "/m/${bundleKey}/${event}/{$id} )
And then you could have a resource bundle as follows:
MyResourceBundleName_es_MX.properties
--------------------------------------------------------------------------------------------------------------------
miembro=member
ver=view
You could actually create a new class called "LocalizedResolution"
that worked off of the same concept. This would do everything
necessary and all that would be provided is a resource bundle.
But personally, there are other things I'd rather see done in Stripes
before this. This can be solved in several other ways that are fairly
effective.
-- Rick
On Thu, May 6, 2010 at 8:37 AM, KR <k-no-s...@a4consulting.nl
<mailto:k-no-s...@a4consulting.nl>> wrote:
Ben,
Is this not just a problem of limiting the possibilities of URL
bindings for
an action bean? We could limit those binding by adding extra
UrlBinding
constraints. For example:
@UrlBinding("/{$member}/{$event}/{$id}")
@UrlBindingParamRange("member", {"member", "miembro", "membro"})
The URL generation is then the same as always, you just need to
add the
correct parameters when generating an URL.
Kind regards,
Karen
"Ben Gunter" <gunter...@gmail.com <mailto:gunter...@gmail.com>>
wrote in
message
news:r2l885e877b1005040550j9d0039ebi7024ad376d288...@mail.gmail.com...
> Stripes has to map an ActionBean to a URL whenever <s:url> or
<s:link> or
> <s:form> or RedirectResolution(Class) or various other
constructs are
> used.
> It is required a lot.
>
> While it would be quite simple just to use the first URL
specified, that
> wouldn't be a complete solution, and then we'd have to have a
conversation
> about why we chose to halfway implement this new feature and how
somebody
> needs to be able to specify which URL they want to link to. If
we're going
> to do it, it needs to be done right.
>
> Besides, one of your complaints about using the URL rewrite
filter was
> that
> you wouldn't be able to specify which URL you want to use during a
> redirect.
> It wouldn't solve your problem if we just used the first URL
specified for
> every forward, redirect or link.
>
> -Ben
>
> On Mon, May 3, 2010 at 11:51 PM, Nikolaos Giannopoulos <
> nikol...@brightminds.org <mailto:nikol...@brightminds.org>> wrote:
>
>> Ben,
>>
>> Comments in-line....
>>
>>
>> Ben Gunter wrote:
>>
>> True, that would be a change we could make that would retain
backwards
>> compatibility.
>>
>> OK.
>>
>> The problem with adding multiple URL bindings, though, isn't with
>> resolving a URL to an ActionBean; it's doing the reverse. The
Stripes
>> UrlBuilder class and the JSP tags that use it depend on a
one-to-one
>> association of ActionBean to URL. Currently there is no way to
specify
>> which
>> of multiple URLs one would like to build for an ActionBean.
>>
>> Sorry - perhaps I am missing something - multiple URLs can map to a
>> single
>> ActionBean. OK. That ActionBean makes a decision as the
controller -
>> using
>> the underlying model - and either forwards or redirects to a
view known
>> by
>> the ActionBean.
>>
>> I'm sure there is a reason for what you are saying but under
what cases
>> would one need to map an ActionBean to a URL?
>>
>> Better yet looking at the member example what would happen if
"say" the
>> reverse mapping defaulted to using the 1st UrlBinding URL?
i.e. consider
>> the first array listed URL to be like the default URL or
something. What
>> would break? What would be the issue?
>>
>> Thanks,
>>
>> --Nikolaos
>>
>>
>> As many times as this has been discussed, we've never come up
with a
>> satisfactory solution to that problem.
>>
>> -Ben
>>
>> On Mon, May 3, 2010 at 6:28 PM, Aaron Porter
>> <aa...@mongus.com <mailto:aa...@mongus.com>> wrote:
>>
>>> Hi Nikolaos,
>>> If it was me I'd probably change @UrlBinding to take String[]
value
>>> instead of String value. Then you could do
>>>
>>> @UrlBinding({
>>>
>>> "/member/{$event}/{id}",
>>> "/miembro/{$event}/{id}",
>>> "/membre/{$event}/{id}",
>>> "/membro/{$event}/{id}"})
>>>
>>>
>>> That shouldn't be a very big change but Ben Gunter would have
a better
>>> idea than I would.
>>>
>>> Aaron
>>>
>>> On 05/03/2010 10:10 AM, Nikolaos Giannopoulos wrote:
>>> > Hi,
>>> >
>>> > We are building a large site that initially supports 2
languages but
>>> > will quickly grow 5+. The site has country specific
"virtualized"
>>> > sub-domains i.e. the underlying plumbing is just one site
that accepts
>>> > any language based on country specific site or user preferences.
>>> >
>>> > I really like Clean URLs however our MemberActionBean must
accept ANY
>>> > of
>>> > the following URLs:
>>> >
>>> > /member/{$event}/{id}
>>> > /miembro/{$event}/{id}
>>> > /membre/{$event}/{id}
>>> > /membro/{$event}/{id}
>>> >
>>> > Unfortunately the following is not allowed:
>>> >
>>> > @UrlBinding("/member/{$event}/{id}")
>>> > @UrlBinding("/miembro/{$event}/{id}")
>>> > @UrlBinding("/membre/{$event}/{id}")
>>> > @UrlBinding("/membro/{$event}/{id}")
>>> > public class MemberActionBean extends BaseActionBean {
>>> >
>>> > Any ideas on how to get something like this to work? We
will have at
>>> > least a dozen other action beans just like this.
>>> >
>>> > --Nikolaos
>>> >
>>> >
>>>
------------------------------------------------------------------------------
>>> > _______________________________________________
>>> > Stripes-users mailing list
>>> > Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
>>> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>>> >
>>> >
>>>
>>>
>>>
>>>
------------------------------------------------------------------------------
>>> _______________________________________________
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>
>> ------------------------------
>>
>>
------------------------------------------------------------------------------
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Stripes-users mailing
>>
liststripes-us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/stripes-users
<http://lists.sourceforge.net/lists/listinfo/stripes-users>
>>
>>
>>
>> --
>> Nikolaos Giannopoulos
>> Director, BrightMinds Software Inc.
>> e. nikol...@brightminds.org <mailto:nikol...@brightminds.org>
>> w. www.brightminds.org <http://www.brightminds.org>
>> t. 1.613.822.1700
>> c. 1.613.797.0036
>> f. 1.613.822.1915
>>
>>
>>
>>
------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
<mailto:Stripes-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
