JSPWiki
  1. JSPWiki
  2. JSPWIKI-351

Incorrect bundles specified in JSPs

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8
    • Fix Version/s: 3.0
    • Component/s: Default template
    • Labels:
      None
    • Environment:

      All

      Description

      i18n strings are improperly stored in CoreResources_.properties, when they should have been specified in templates/default_.properties. The comments at the top of CoreResources specifies that messages are for "JSPWiki internal code, the so-called core code." But these JSPs all look up and use message strings from CoreResources:

      • Comment.jsp
      • Install.jsp
      • LostPassword.jsp
      • NewGroup.jsp
      • Rename.jsp

      Example:

      // Weepy tears and hankies all 'round.
      if( wikiSession.isAuthenticated() )

      { response.sendError( HttpServletResponse.SC_FORBIDDEN, rb.getString("login.error.noaccess") ); return; }

      This is clearly a template/JSP-level error message, NOT an internal error. And similar kinds of code are sprinked all over the other JSPs.

      I recommend we consolidate default.properties and CoreResources.properties. The easiest way would simply be to concatenate the files. Then, in WikiContext.getBundle(), any requests for "CoreResources" could be simply diverted to default.properties.

        Activity

        Hide
        Janne Jalkanen added a comment -

        CoreResources is meant for properties which do not vary from one template to another, and also for strings which are used inside jspwiki main classes (just look them up; auth classes and the lot use coreresources).

        Default.properties is meant for strings used by the default template. Another template would use a separate set of strings. This separation makes it possible for template developers to deploy a separate template with a separate localization without mucking around in the jspwiki internals.

        As the top-level JSP files do not vary from template to template, their resources belong to CoreResources. In the future, when their functionality becomes a part of the Stripes ActionBeans, it would be very odd to have the resources located in default.properties. that would mean that a template developer would need to "guess" which of the resource keys are not used by the template, and which are required by the core code.

        -1 from me.

        Show
        Janne Jalkanen added a comment - CoreResources is meant for properties which do not vary from one template to another, and also for strings which are used inside jspwiki main classes (just look them up; auth classes and the lot use coreresources). Default.properties is meant for strings used by the default template. Another template would use a separate set of strings. This separation makes it possible for template developers to deploy a separate template with a separate localization without mucking around in the jspwiki internals. As the top-level JSP files do not vary from template to template, their resources belong to CoreResources. In the future, when their functionality becomes a part of the Stripes ActionBeans, it would be very odd to have the resources located in default.properties. that would mean that a template developer would need to "guess" which of the resource keys are not used by the template, and which are required by the core code. -1 from me.
        Hide
        Andrew Jaquith added a comment -

        Indeed, when we get to Stripes, developers (and Stripes) should not guess where the strings are located. I filed this bug precisely because of that fact. TODAY, developers need to guess. And tomorrow, Stripes will have to.

        In theory, we distinguish between top-level JSPs (which provide business logic and field validation) and template *Content JSPs (which present the UI). Whether something is in CoreResources versus default.props seems to depend on whether we've shipped it something as opposed to a third party customization.

        But this has led to some slightly weird conventions. For example, the method that validates the input for new user profiles (in UserManager.validateProfile) uses the CoreResources bundle for generating errors – but the presentation markup on ProfileContent.jsp uses the "default" bundle. Why? Is there something intrinsic about validation that makes it a "core" feature rather than a "custom template" feature? Why look up field names in two places?

        The key problem, in my view, is that in "core" we have mixed presentation-tier messages (for example, JSP form field validation) in with core class messages that have nothing to do with the presentation tier. I would suggest to you that this is the wrong distinction. The key point of separation (assuming we need one at all!) is not who (us v. someone els) WROTE the message strings, but what TIER the messages apply to.

        For example, I've mixed together the various "login" properties from CoreResources and the default bundle. Can you tell which belongs to which? I sure can't.

        login.tab=Login
        login.title=Login
        login.heading.login=Sign in to

        {0}
        login.help=Please sign in with your login name and password.
        login.errorprefix=Error: 
        login.error.capslock=Invalid login (please check your Caps Lock key) #obsolete
        login.error.password=Not a valid login.
        login.error.noaccess=It seems you don't have access to that. Sorry.
        login.login=Login
        login.password=Password
        login.lostpw=Lost your password?
        login.lostpw.reset.login={0}

        to log in once you retrieve your new password.
        login.register.tab=Register New User

        Having a single set of bundles for the JSP tier is critical for Stripes. Stripes relies on being able to locate a standard resource bundle for looking up validation error strings, field labels and the like. In the servlet configuration, you can tell Stripes where to find these strings by setting the "StripesResources" servlet init param. (You can actually configure two different bundles, one for errors and one for field names, but that's a minor point.) The point is, Stripes has no knowledge of what a JSPWiki "default template" is versus a "core resource"; it just wants a predictable place to find message strings.

        For example, let's look at what happens in a typical Stripes ActionBean custom validation method.

        @ValidationMethod( on = "save", when = ValidationState.ALWAYS )
        public void validatePasswords( ValidationErrors errors )
        {
        // If a password was supplied, the same value must also have been passed
        // to passwordAgain
        if( m_profile.getPassword() != null )
        {
        if( !m_profile.getPassword().equals( m_passwordAgain ) )

        { errors.add( "profile.password", new LocalizableError( "security.error.passwordnomatch" ) ); }

        }
        }

        This method fires before the save() event handler executes, and it makes sure the two password fields match. The ValidationErrors object contains the set of errors for this particular submitted form. If we add a LocalizableError (constructed with a message key), it will look in the bundle we've configured Stripes to use. You could argue, in this case, that Stripes should obviously use CoreResources, and in this case I would agree. In case we wanted to use the template's bundle, we could supply a "SimpleError" type instead, and look up and supply as hard-coded text the localized string we want, from the bundle we want. Ok, fine.

        But, of course, we won't always have as much control over which message bundle we use. Consider a setFullname() setter method on the ActionBean with a @Validate annotation:

        @Validate( field = "fullname", maxlength = 100, required = true, on = "save", label="security.user.fullname" )

        The "label" portion of the annotation tells Stripes to use the "security.user.fullname" key for reporting errors. Stripes will look in the bundle we told it to use, presumably CoreResources. But if we wanted to use something in a template bundle, we'd be hosed.

        Given the constraint that Stripes requires a consistent place for looking up message keys, we have exactly two choices here:

        • Move ALL presentation-tier messages to default.properties and have Stripes use that as its default bundle. We could do this in 2.8
        • Consolidate the properties in CoreResources and default.props and have Stripes use that bundle. It would be hard to do this in 2.8.

        I favor the latter – collapsing ALL i18n properties (plugins too) into a single set of files. In addition, I think it would also make sense to externalize the properties into a directory in WEB-INF, rather than keep them in JSPWiki.jar. If, indeed, we expect developers to customize things, it seems burdensome to force them to rebuild the JSPWiki.jar every time they change a message string.

        Show
        Andrew Jaquith added a comment - Indeed, when we get to Stripes, developers (and Stripes) should not guess where the strings are located. I filed this bug precisely because of that fact. TODAY, developers need to guess. And tomorrow, Stripes will have to. In theory, we distinguish between top-level JSPs (which provide business logic and field validation) and template *Content JSPs (which present the UI). Whether something is in CoreResources versus default.props seems to depend on whether we've shipped it something as opposed to a third party customization. But this has led to some slightly weird conventions. For example, the method that validates the input for new user profiles (in UserManager.validateProfile) uses the CoreResources bundle for generating errors – but the presentation markup on ProfileContent.jsp uses the "default" bundle. Why? Is there something intrinsic about validation that makes it a "core" feature rather than a "custom template" feature? Why look up field names in two places? The key problem, in my view, is that in "core" we have mixed presentation-tier messages (for example, JSP form field validation) in with core class messages that have nothing to do with the presentation tier. I would suggest to you that this is the wrong distinction. The key point of separation (assuming we need one at all!) is not who (us v. someone els) WROTE the message strings, but what TIER the messages apply to. For example, I've mixed together the various "login" properties from CoreResources and the default bundle. Can you tell which belongs to which? I sure can't. login.tab=Login login.title=Login login.heading.login=Sign in to {0} login.help=Please sign in with your login name and password. login.errorprefix=Error:  login.error.capslock=Invalid login (please check your Caps Lock key) #obsolete login.error.password=Not a valid login. login.error.noaccess=It seems you don't have access to that. Sorry. login.login=Login login.password=Password login.lostpw=Lost your password? login.lostpw.reset.login={0} to log in once you retrieve your new password. login.register.tab=Register New User Having a single set of bundles for the JSP tier is critical for Stripes. Stripes relies on being able to locate a standard resource bundle for looking up validation error strings, field labels and the like. In the servlet configuration, you can tell Stripes where to find these strings by setting the "StripesResources" servlet init param. (You can actually configure two different bundles, one for errors and one for field names, but that's a minor point.) The point is, Stripes has no knowledge of what a JSPWiki "default template" is versus a "core resource"; it just wants a predictable place to find message strings. For example, let's look at what happens in a typical Stripes ActionBean custom validation method. @ValidationMethod( on = "save", when = ValidationState.ALWAYS ) public void validatePasswords( ValidationErrors errors ) { // If a password was supplied, the same value must also have been passed // to passwordAgain if( m_profile.getPassword() != null ) { if( !m_profile.getPassword().equals( m_passwordAgain ) ) { errors.add( "profile.password", new LocalizableError( "security.error.passwordnomatch" ) ); } } } This method fires before the save() event handler executes, and it makes sure the two password fields match. The ValidationErrors object contains the set of errors for this particular submitted form. If we add a LocalizableError (constructed with a message key), it will look in the bundle we've configured Stripes to use. You could argue, in this case, that Stripes should obviously use CoreResources, and in this case I would agree. In case we wanted to use the template's bundle, we could supply a "SimpleError" type instead, and look up and supply as hard-coded text the localized string we want, from the bundle we want. Ok, fine. But, of course, we won't always have as much control over which message bundle we use. Consider a setFullname() setter method on the ActionBean with a @Validate annotation: @Validate( field = "fullname", maxlength = 100, required = true, on = "save", label="security.user.fullname" ) The "label" portion of the annotation tells Stripes to use the "security.user.fullname" key for reporting errors. Stripes will look in the bundle we told it to use, presumably CoreResources. But if we wanted to use something in a template bundle, we'd be hosed. Given the constraint that Stripes requires a consistent place for looking up message keys, we have exactly two choices here: Move ALL presentation-tier messages to default.properties and have Stripes use that as its default bundle. We could do this in 2.8 Consolidate the properties in CoreResources and default.props and have Stripes use that bundle. It would be hard to do this in 2.8. I favor the latter – collapsing ALL i18n properties (plugins too) into a single set of files. In addition, I think it would also make sense to externalize the properties into a directory in WEB-INF, rather than keep them in JSPWiki.jar. If, indeed, we expect developers to customize things, it seems burdensome to force them to rebuild the JSPWiki.jar every time they change a message string.
        Hide
        Janne Jalkanen added a comment -

        When I say "developer", I mean a person who takes the templates, does not really know anything about JSPWiki, and is able to create new templates based on the existing template code. Each template should be a completely separate thing which could be packaged in a JAR file.

        When you say "developer", you mean a jspwiki committer/contributor.

        These are different goals. What I am looking for is strong separation of core code and the templates. Collapsing all resources into a single file is not separation.

        Separation of the core code and the templates unfortunately means that the separation line is drawn in the middle of the View tier. Stripes is obviously not designed for this kind of use and we'll have to think how that is done.

        A good example is that if you create a new template called "mytemplate", which holds its keys on "mytemplate.resources", BUT you only copy a couple of files (say PageContent.jsp and SearchBox.jsp) and rely on the default template to provide the rest, you would need to ship ALL keys in mytemplate.resources. And then, when we update the default template, the mytemplate.resources does not contain these keys, and things look broken.

        This means that any external template would be tied to a particular minor revision of JSPWiki.

        Show
        Janne Jalkanen added a comment - When I say "developer", I mean a person who takes the templates, does not really know anything about JSPWiki, and is able to create new templates based on the existing template code. Each template should be a completely separate thing which could be packaged in a JAR file. When you say "developer", you mean a jspwiki committer/contributor. These are different goals. What I am looking for is strong separation of core code and the templates. Collapsing all resources into a single file is not separation. Separation of the core code and the templates unfortunately means that the separation line is drawn in the middle of the View tier. Stripes is obviously not designed for this kind of use and we'll have to think how that is done. A good example is that if you create a new template called "mytemplate", which holds its keys on "mytemplate.resources", BUT you only copy a couple of files (say PageContent.jsp and SearchBox.jsp) and rely on the default template to provide the rest, you would need to ship ALL keys in mytemplate.resources. And then, when we update the default template, the mytemplate.resources does not contain these keys, and things look broken. This means that any external template would be tied to a particular minor revision of JSPWiki.
        Hide
        Janne Jalkanen added a comment -

        BTW, I think that we can easily provide our own LocalizableError classes which specify the Bundle as well.

        Show
        Janne Jalkanen added a comment - BTW, I think that we can easily provide our own LocalizableError classes which specify the Bundle as well.
        Hide
        Janne Jalkanen added a comment -

        Also, we can use the @ValidationMethod annotation, which I think is a better idea than the @Validate anyway. Gives better control.

        Show
        Janne Jalkanen added a comment - Also, we can use the @ValidationMethod annotation, which I think is a better idea than the @Validate anyway. Gives better control.
        Hide
        Andrew Jaquith added a comment -

        Janne –

        I think the separation you are making is splitting things a little too finely. I agree that "developers" (in all senses of the word) should be able to customize templates, and the messages that go with them. But I am arguing here that unifying all of the presentation-tier messages in a single set of properties (while leaving the back-end messages elsewhere if we want to) is a pretty simple distinction to make. It's also very easy to hack. Hacking is good!

        The clone-and-go model (like you described in your mytemplate.resources example) is totally reasonable. After all, the hack-it approach is how jspwiki.properties works, right? We provide a .tmpl original, and expect that deployers will customize this as they go. We also expect that they keep it in sync with JSPWiki as it evolves, because it gains properties from time to time! I don't see why presentation-tier messages should be any different.

        I understand your concern about revision management, but it is only a minor concern. Our message key names are (or should be) pretty stable by now. And frankly, the default.properties files are ALREADY the original source for every third-party template's keys.

        I agree that, in the short term, supplying our own errors is the way to go. But using @ValidateMethod in preference to @Validate annotations is a poor use of committers' time. It would mean we'd just re-write validation routines for simple things like length checking, optionality, regex, etc. Stripes does this elegantly and in a bug-free way already. That is exactly the kind of low-value-added coding we should NOT be doing.

        Show
        Andrew Jaquith added a comment - Janne – I think the separation you are making is splitting things a little too finely. I agree that "developers" (in all senses of the word) should be able to customize templates, and the messages that go with them. But I am arguing here that unifying all of the presentation-tier messages in a single set of properties (while leaving the back-end messages elsewhere if we want to) is a pretty simple distinction to make. It's also very easy to hack. Hacking is good! The clone-and-go model (like you described in your mytemplate.resources example) is totally reasonable. After all, the hack-it approach is how jspwiki.properties works, right? We provide a .tmpl original, and expect that deployers will customize this as they go. We also expect that they keep it in sync with JSPWiki as it evolves, because it gains properties from time to time! I don't see why presentation-tier messages should be any different. I understand your concern about revision management, but it is only a minor concern. Our message key names are (or should be) pretty stable by now. And frankly, the default.properties files are ALREADY the original source for every third-party template's keys. I agree that, in the short term, supplying our own errors is the way to go. But using @ValidateMethod in preference to @Validate annotations is a poor use of committers' time. It would mean we'd just re-write validation routines for simple things like length checking, optionality, regex, etc. Stripes does this elegantly and in a bug-free way already. That is exactly the kind of low-value-added coding we should NOT be doing.
        Hide
        Andrew Jaquith added a comment -

        The broader issue here is how customizations are done. The model we've used in the presentation-tier, largely, is one that uses the custom version of the file if supplied, but reverts to the default version if not supplied.

        This is, for example, why we don't use jsp:include tabs, but have our own wiki:include tag. And the reason we have THAT is because the top-level JSPs are really controller pages that link to the template presentation JSPs.

        But with Stripes we do not need to be so rigid. It means we can blow up some of those assumptions, and simplify things considerably while keeping things very customizable.

        For example, the parameter binding stuff is taken care of the StripesFilter and/or useActionBean tag. Validations become annotations on ActionBean properties. And the business logic moves up into ActionBean methods. There is nothing for the top-level JSPs to do other than forward to the content JSP!

        In a world like that, I would argue that it's actually easier to have NO templates at all – just encourage template customizers to hack the top-level JSPs, which would be 100% presentation. That's how WordPress does it, for example. This is a different model than the hypothetical JAR model you mentioned, which is something that doesn't exist today.

        Now, that's a detailed example. But it's related to the discussion we are having about presentation-tier messages. ...

        Show
        Andrew Jaquith added a comment - The broader issue here is how customizations are done. The model we've used in the presentation-tier, largely, is one that uses the custom version of the file if supplied, but reverts to the default version if not supplied. This is, for example, why we don't use jsp:include tabs, but have our own wiki:include tag. And the reason we have THAT is because the top-level JSPs are really controller pages that link to the template presentation JSPs. But with Stripes we do not need to be so rigid. It means we can blow up some of those assumptions, and simplify things considerably while keeping things very customizable. For example, the parameter binding stuff is taken care of the StripesFilter and/or useActionBean tag. Validations become annotations on ActionBean properties. And the business logic moves up into ActionBean methods. There is nothing for the top-level JSPs to do other than forward to the content JSP! In a world like that, I would argue that it's actually easier to have NO templates at all – just encourage template customizers to hack the top-level JSPs, which would be 100% presentation. That's how WordPress does it, for example. This is a different model than the hypothetical JAR model you mentioned, which is something that doesn't exist today. Now, that's a detailed example. But it's related to the discussion we are having about presentation-tier messages. ...
        Hide
        Janne Jalkanen added a comment -

        We do strive for backwards compatibility on the jspwiki.properties level, so I don't think that is a valid argument, and we certainly don't change it very lightly. I actually think that we should even try and get rid of even this dependency in 3.0 and make it more robust (I have some ideas about that).

        Yes, they are the source. But that does not mean that we need to make their life even more difficult than what it is now. Stripes is going to allow us to make cleaner templates, so we can grab the opportunity and make our templating system even better, not worse. Hacking is not good, if you need to do it every single time you upgrade just to keep up...

        @Validate is meant for the simple cases. We can easily default this to a particular resourcebundle, and, should we need something more complex, we can use a @ValidateMethod. In addition, we can pretty easily add a new argument to @Validate, e.g. "resourceBundle" with just the name.

        Our message keys are not stable. Many bugs and almost all new features will introduce change or introduce new keys. CoreResources seems to have changed on the average every two weeks for the past year or so.

        (I do totally agree on splitting the resourcebundles to separate JAR files though; the build process is nearly there but not quite.)

        Show
        Janne Jalkanen added a comment - We do strive for backwards compatibility on the jspwiki.properties level, so I don't think that is a valid argument, and we certainly don't change it very lightly. I actually think that we should even try and get rid of even this dependency in 3.0 and make it more robust (I have some ideas about that). Yes, they are the source. But that does not mean that we need to make their life even more difficult than what it is now. Stripes is going to allow us to make cleaner templates, so we can grab the opportunity and make our templating system even better, not worse. Hacking is not good, if you need to do it every single time you upgrade just to keep up... @Validate is meant for the simple cases. We can easily default this to a particular resourcebundle, and, should we need something more complex, we can use a @ValidateMethod. In addition, we can pretty easily add a new argument to @Validate, e.g. "resourceBundle" with just the name. Our message keys are not stable. Many bugs and almost all new features will introduce change or introduce new keys. CoreResources seems to have changed on the average every two weeks for the past year or so. (I do totally agree on splitting the resourcebundles to separate JAR files though; the build process is nearly there but not quite.)
        Hide
        Janne Jalkanen added a comment -

        I've always found most PHP app template hacks to be distasteful, to be frank. If you change something, trying to get it to work with the next version is a bit of a problem.

        Since we already consider Wiki.jsp et al to be a part of the controller framework, that code will move to ActionBeans. And that means that the code in the View tier is already in the templates/xxx files. Which is also where the resources are (default.properties).

        The problem is that our controller will return information visible to the user (e.g. exceptions and errors). And this makes them partly Controllers and partly View. Which in turn means that you need to split the bundles somewhere. At the moment the choice is that "if it's under templates, it's a part of the template resource bundle. If it's not in the templates, it's in the core resources." It's fairly clear, I think.

        Show
        Janne Jalkanen added a comment - I've always found most PHP app template hacks to be distasteful, to be frank. If you change something, trying to get it to work with the next version is a bit of a problem. Since we already consider Wiki.jsp et al to be a part of the controller framework, that code will move to ActionBeans. And that means that the code in the View tier is already in the templates/xxx files. Which is also where the resources are (default.properties). The problem is that our controller will return information visible to the user (e.g. exceptions and errors). And this makes them partly Controllers and partly View. Which in turn means that you need to split the bundles somewhere. At the moment the choice is that "if it's under templates, it's a part of the template resource bundle. If it's not in the templates, it's in the core resources." It's fairly clear, I think.
        Hide
        Andrew Jaquith added a comment -

        You've finally conceded something: "We can easily default this to a particular resourcebundle, and, should we need something more complex, we can use a @ValidateMethod"

        Allrighty then. Here are the guidelines that I propose:

        1. Default the @Validate messages to the same resource bundle used by the templates. This would be default*.properties. Practically speaking, this means that the current contents of StripesResources.properties (which have the default messages for @Validate validations) would be appended to default*.properties. Stripes messages and keys are VERY stable.
        2. For @ValidateMethod custom validation methods, always add SimpleErrors to the ValidationProperties object. The message string passed to the SimpleError constructor should be the final text that is obtained by looking it up in CoreResources.
        3. For event handler methods (i.e., they have a @HandlesEvent annotation) that generate errors, do the same as #2: look up the final string in CoreResources and pass it to the SimpleError constructor.

        This does not give me what I really want, namely tier-based rather than template-based separation (or complete unification, which would be even simpler). But it does mean we can make this work without having to subclass the @Validate annotation, create our own ValidationError implementation, or write crazy @ValidationMethod methods even for the simplest cases.

        Reasonable?

        Show
        Andrew Jaquith added a comment - You've finally conceded something: "We can easily default this to a particular resourcebundle, and, should we need something more complex, we can use a @ValidateMethod" Allrighty then. Here are the guidelines that I propose: 1. Default the @Validate messages to the same resource bundle used by the templates. This would be default*.properties. Practically speaking, this means that the current contents of StripesResources.properties (which have the default messages for @Validate validations) would be appended to default*.properties. Stripes messages and keys are VERY stable. 2. For @ValidateMethod custom validation methods, always add SimpleErrors to the ValidationProperties object. The message string passed to the SimpleError constructor should be the final text that is obtained by looking it up in CoreResources. 3. For event handler methods (i.e., they have a @HandlesEvent annotation) that generate errors, do the same as #2: look up the final string in CoreResources and pass it to the SimpleError constructor. This does not give me what I really want, namely tier-based rather than template-based separation (or complete unification, which would be even simpler). But it does mean we can make this work without having to subclass the @Validate annotation, create our own ValidationError implementation, or write crazy @ValidationMethod methods even for the simplest cases. Reasonable?
        Hide
        Janne Jalkanen added a comment -

        Once we agree on the problem, the solution tends to become obvious .

        Your solution sounds good, except that why can't we use @Validate with CoreResources? Because Stripes assumes that all of the keys from the templates too are from a single resource file?

        If I read the Stripes documentation right, template authors can still specify with <fmt:setBundle> which bundle their strings are coming from? I.e. Stripes does not override whatever the user wants, it just defaults in the absence in any other information. If this is true with Stripes, then we actually have no issue, since we can contain the keys internally without having them to leak out. But this needs to be tested.

        Show
        Janne Jalkanen added a comment - Once we agree on the problem, the solution tends to become obvious . Your solution sounds good, except that why can't we use @Validate with CoreResources? Because Stripes assumes that all of the keys from the templates too are from a single resource file? If I read the Stripes documentation right, template authors can still specify with <fmt:setBundle> which bundle their strings are coming from? I.e. Stripes does not override whatever the user wants, it just defaults in the absence in any other information. If this is true with Stripes, then we actually have no issue, since we can contain the keys internally without having them to leak out. But this needs to be tested.
        Hide
        Janne Jalkanen added a comment -

        Anyway, is this urgent for 2.8?

        Show
        Janne Jalkanen added a comment - Anyway, is this urgent for 2.8?
        Hide
        Janne Jalkanen added a comment -

        Since I suspect many of the localization files will be changed for 3.0 anyway, I think it's safe to postpone this discussion for 3.0... Not much benefit today anyway.

        Show
        Janne Jalkanen added a comment - Since I suspect many of the localization files will be changed for 3.0 anyway, I think it's safe to postpone this discussion for 3.0... Not much benefit today anyway.
        Hide
        Andrew Jaquith added a comment -

        Now that I've done a few ActionBeans now in the 3.0 branch, I thought it would be good to revisit this issue.

        My tentative recommendation is that we use read localized message strings from the same place for all Stripes-related validation methods (that is, methods that have either @Validate or @ValidationMethod annotations). Practically speaking, inside of ValidationMethod methods, you'd add error messages by creating LocalizableErrors, which get their localized messages from wherever we tell Stripes to look.

        So far, I've configured the Stripes web.xml configuration parameter to use the template default* bundle, just because it was easiest. But we could easily switch it to use CoreResources, and I think that is probably the right approach because it would be template-independent. However, we'd need to do some work to move some of the simple field name stuff into CoreResources as a result.

        If we agree, I'll make this change and commit it in the near future.

        Show
        Andrew Jaquith added a comment - Now that I've done a few ActionBeans now in the 3.0 branch, I thought it would be good to revisit this issue. My tentative recommendation is that we use read localized message strings from the same place for all Stripes-related validation methods (that is, methods that have either @Validate or @ValidationMethod annotations). Practically speaking, inside of ValidationMethod methods, you'd add error messages by creating LocalizableErrors, which get their localized messages from wherever we tell Stripes to look. So far, I've configured the Stripes web.xml configuration parameter to use the template default* bundle, just because it was easiest. But we could easily switch it to use CoreResources, and I think that is probably the right approach because it would be template-independent. However, we'd need to do some work to move some of the simple field name stuff into CoreResources as a result. If we agree, I'll make this change and commit it in the near future.
        Hide
        Janne Jalkanen added a comment -

        If the stuff is template-independent, it should come from the CoreResources... Even if it's used in the template itself. It would be shared by templates, most likely.

        Show
        Janne Jalkanen added a comment - If the stuff is template-independent, it should come from the CoreResources... Even if it's used in the template itself. It would be shared by templates, most likely.
        Hide
        Andrew Jaquith added a comment -

        Ok. I'll change the Stripes config to use CoreResources. It makes sense to do it this way.

        Show
        Andrew Jaquith added a comment - Ok. I'll change the Stripes config to use CoreResources. It makes sense to do it this way.
        Hide
        Andrew Jaquith added a comment -

        Fixed in 3.0.0-svn build 41.

        Show
        Andrew Jaquith added a comment - Fixed in 3.0.0-svn build 41.

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrew Jaquith
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 2h
              2h
              Remaining:
              Remaining Estimate - 2h
              2h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development