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"
<[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
________________________________
Adam Lipscombe
Escalus Software Systems
[EMAIL PROTECTED]
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
([EMAIL PROTECTED]) 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
