struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <lau...@holoweb.net>
Subject Re: bean:message with database backed properties (was bean:write ...)
Date Thu, 02 Nov 2006 21:35:10 GMT
Adam Lipscombe wrote:
> Thanks for that, but I don't understand how it addresses the problem. 
> Maybe I am missing the point...
> 
> Say I have 2 props in a resource file:
> 
> prop1=Hello
> prop2=Hi
> 
> The bean:message tag would read <bean:message key="prop1"/>, and the 
> String "Hello" would be output
> to the page.
> 
> I want to put the props in the database ...

Which you can do by implementing a custom MessageResourcesFactory and 
registering it in struts-config.xml;

 > ... and pick them one out according
> to the value of a variable.

But that you can't, since the resource lookup mechanism isn't aware of 
anything but the locale; additional context, such as some user's 
business context, simply isn't visible from within a resource bundle.

> e.g. (pseudo code):
> 
> if (user.businessUnit == "Accounts")
>   <bean:message key="prop2"/>
> else
>   <bean:message key="prop1"/>
> 
> The requirement is simple terms is that if the user belong to "Accounts" 
> they see "Hi" while
> everyone else sees "Hello".
> 
> Is there any canonical way to do this for properties stored in the DB 
> and using the bean:message
> tag? Does it involve implementing a custom bean:message tag?

You need to seperate the concerns:

1) storing / looking up resources in a database
2) selecting resources based on app-specific criteria

Typically you'd make the decision regarding what message to show as part 
of your business logic (i.e. in the action or an underlying service 
facade), and then show that message using bean:message or equivalent.

Alternatively, if you don't mind the having the business logic for 
message selection embedded in your JSP, you could use logic:equal, c:if 
of something to in-line the message selection logic.

Implementing a custom tag based on bean:message, or using a JSP 2.0 tag 
file or something, to encapsulate your message selection logic may be a 
good idea if you need to make the same type of choice in multiple places.

L.

> TIA -Adam
> 
> Martin Gainty wrote:
>> Good Morning Adam-
>>
>> First off I would recommend viewing this article in implementing EJBs 
>> specifically establishing DTO's to handle the data components
>> http://husted.com/struts/tips/018.html
>>
>> M-
>> This e-mail communication and any attachments may contain confidential 
>> and privileged information for the use of the designated recipients 
>> named above. If you are not the intended recipient, you are hereby 
>> notified that you have received
>> this communication in error and that any review, disclosure, 
>> dissemination, distribution or copying of it or its contents
>> ----- Original Message ----- From: "Adam Lipscombe" 
>> <adam.lipscombe@expensys.com>
>> To: "Struts Users Mailing List" <user@struts.apache.org>
>> Sent: Wednesday, November 01, 2006 7:59 AM
>> Subject: bean:message with database backed properties (was bean:write 
>> ...)
>>
>>
>>> Sorry should have been bean:message
>>>
>>>
>>> Adam
>>>
>>> Adam Lipscombe wrote:
>>>> Folks,
>>>>
>>>>
>>>> I have a requirement to use a database backed properties mechanism 
>>>> rather than a simple resources text file. The property that is 
>>>> retrieved will depend on the some of the user attributes, so at 
>>>> least 1 attrib would have to passed to the lookup mech.
>>>>
>>>> I want to use the standard bean:message tag if possible.
>>>>
>>>>
>>>> It occurs that this must have been done before and there is likely 
>>>> to be a "standard" approach.
>>>>
>>>>
>>>>
>>>> Can someone please point me in the right direction?
>>>>
>>>>
>>>> TIA - Adam
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>> -- 
>>>
>>> ________________________________
>>> Adam Lipscombe
>>> Escalus Software Systems
>>> adam.lipscombe@expensys.com
>>> Tel: 01726 833777
>>> www.expensys.com
>>>
>>> This email and any files transmitted with it, including replies and
>>> forwarded copies, may contain privileged and confidential information 
>>> and
>>> is intended solely for the person or organisation to whom it is 
>>> addressed.
>>> If you have received this communication in error, please notify us by 
>>> email
>>> (Notices@Escalus.net) or telephone (+44 (0)1726 833777) and then 
>>> delete the
>>> email and any copies of it. Views or opinions expressed by an individual
>>> within this email may not necessarily reflect the views of Escalus 
>>> Software
>>> Systems Ltd.
>>>
>>> Although most emails and attachments from Escalus Software Systems 
>>> Ltd are
>>> screened, it is the responsibility of the recipient to ensure
>>> that they are virus free. Escalus Software Systems Ltd will not 
>>> accept any
>>> liability for damage caused by a virus.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message