[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1262) Should be able to customize Hibernate validation messages based on context (by page, or role like Seam component scopes)
by Nathaniel Stoddard (JIRA)
Should be able to customize Hibernate validation messages based on context (by page, or role like Seam component scopes)
------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-1262
URL: http://jira.jboss.com/jira/browse/JBSEAM-1262
Project: JBoss Seam
Issue Type: Feature Request
Affects Versions: 1.2.1.GA
Reporter: Nathaniel Stoddard
Currently, each validation specified a single message resource to be used as the error message. It would be helpful if there was some way to customize the error messages to be used such that in one case "Contact address is required." is displayed, while in others "Billing address is required", for example. Annotating model classes with validation rules limits the reuse of those classes since the validation messages offer limited flexibility.
Since validated fields in the domain classes aren't necessarily associated with a UIInput on a page, it would be helpful to have more flexible annotations, such as:
@MaxLength(messages = {@Message(role='contactForm', value='contact.too_long'), @Message(role='billingForm', value='billing.too_long')})
private String field;
Also needed would be some way of indicated to the UIView which 'role' should be used when validation takes place.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2121) Support for an SMPC per nested conversation
by Jacob Orshalick (JIRA)
Support for an SMPC per nested conversation
-------------------------------------------
Key: JBSEAM-2121
URL: http://jira.jboss.com/jira/browse/JBSEAM-2121
Project: JBoss Seam
Issue Type: Feature Request
Affects Versions: 2.0.0.CR2
Reporter: Jacob Orshalick
Currently an open issue and ongoing discussion with respect to the existing nested conversation implementation is master-details editing. If a Seam-managed Persistence Context (SMPC) is shared between the outer and nested conversation, any changes made in the nested conversation will be flushed by the SMPC in the outer conversation and vice versa if a flush is initiated. Support for initialization of a new SMPC within a nested conversation would allow state changes in the nested conversation to be confined to that conversation, thus resolving this issue. Perhaps something like the following could be supported:
<persistence:managed-persistence-context name="bookingDatabase"
auto-create="true"
per-nested-conversation-"true"
persistence-unit-jndi-name="java:/EntityManagerFactories/bookingData"/>
It would also be nice to be able to use annotations (i.e. something similar to @PerNestedConversation).
For further information on this approach please see the forum posting. Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1009) optionally login-require in a more specific page should be able to override a wildcard login-require
by Leo Baschy (JIRA)
optionally login-require in a more specific page should be able to override a wildcard login-require
----------------------------------------------------------------------------------------------------
Key: JBSEAM-1009
URL: http://jira.jboss.com/jira/browse/JBSEAM-1009
Project: JBoss Seam
Issue Type: Patch
Components: Security
Affects Versions: 1.2.0.GA
Environment: all
Reporter: Leo Baschy
This should be optional to switch on, so no one's existing expectations of security get broken.
The point is about having a generic wildcard <page view-id="*" scheme="http" login-required="true"> to secure the whole site, and then allowing specific pages or specific wildcards to have login-required="false". E.g. for a registration (with preview) section as one cannot be logged in if one isn't registered yet.
Some may suggest instead forcing pages into dedicated secure and not-secure directories, but in reality if there are multiple reasons to force pages into directories different ways (security, hyperlink management, publishability of URLs, etc.), one cannot serve all of them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2133) inline EL in component property value not properly detected
by Dan Allen (JIRA)
inline EL in component property value not properly detected
-----------------------------------------------------------
Key: JBSEAM-2133
URL: http://jira.jboss.com/jira/browse/JBSEAM-2133
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.CR2
Reporter: Dan Allen
Assigned To: Dan Allen
Priority: Critical
Fix For: 2.0.1.GA
Currently, the EL notation in a property is only being evaluated if the property starts with "#{". There are two problems with this assumption.
1. Inline EL can only be used if the property starts with an expression (i.e. <property name="message">#{applicationName} is a cool application</property>)
2. There is no way to escape EL so that is is evaluated by the property accepting the string (rather than when the value is assigned).
The correct behavior would be to treat the property value as a value expression if it CONTAINS "#{". The benefits are two fold:
1. A property value can use inline EL that is evaluated when the property value is set (see above)
2. The resolved value of the property can be EL (delayed EL) that is to be interpreted by the component as needed. This is done by escaping the EL per the unified EL spec (i.e. <property name="created-message">The user \#{user.name} has been created!</property)
Surprisingly, everything is already in place. All that needs to happen is the check for EL needs to change from "startsWith" to "contains".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months