[jira] [Commented] (JSPWIKI-864) ValidationManager added to WikiEngine
[
https://issues.apache.org/jira/browse/JSPWIKI-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14113619#comment-14113619
]
Glen Mazza commented on JSPWIKI-864:
Could we use this: http://commons.apache.org/proper/commons-validator/ ? I
wouldn't want us to be reinventing the wheel if we can avoid it.
ValidationManager added to WikiEngine
-
Key: JSPWIKI-864
URL: https://issues.apache.org/jira/browse/JSPWIKI-864
Project: JSPWiki
Issue Type: Wish
Components: Core storage
Reporter: David Vittor
Priority: Minor
Here is another idea. When I write plugins, I spend a lot of time writing
code to make sure that the parameters passed into the plugins are valid.
Things such as strings, booleans, numbers, urls, emails addresses, etc.
I was thinking if we could create a ValidationManager class that could take a
List of Validators (interface) and pass values for validation.
The two main interface method of a Validator would be:
* void validate(String value, String type) throws InvalidValueException;
* void validate(String value, String type, boolean required) throws
InvalidValueException;
** Note: by default required would be false.
The type would be a static int TYPE_EMAIL, TYPE_STRING, etc. defined in the
ValidationManager.
The ValidationManager, would have property:
* ListValidator validators;
and methods:
* void addValidator(Validator v);
* Validator removeValidator(Validator v);
* List Validator getValidators();
This would be very beneficial for all plugin developers, cause then they can
call:
*
wikiContent.getValidationManager().validate(params.get('url'),ValidationManager.TYPE_URL);
And they don't need a try catch, as the user will be told exactly what the
error was. If all parameters are valid, the plugin can continue to do it's
work.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JSPWIKI-864) ValidationManager added to WikiEngine
[
https://issues.apache.org/jira/browse/JSPWIKI-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14113686#comment-14113686
]
David Vittor commented on JSPWIKI-864:
--
Hi Glen,
Thanks for the comment, I'm definitely happy to use this framework for
validation. However as my plan is to write a whole lot of different plugins,
I'm wondering if we could add this validation framework to the core
jspwiki-war/pom.xml file.
http://mvnrepository.com/artifact/commons-validator/commons-validator/1.4.0
dependency
groupIdcommons-validator/groupId
artifactIdcommons-validator/artifactId
version1.4.0/version
/dependency
If we do that then in my individual plugins I can add the above, with scope set
to provided which means I will assume that this is available in the platform.
Let us know what you think. Cheers.
ValidationManager added to WikiEngine
-
Key: JSPWIKI-864
URL: https://issues.apache.org/jira/browse/JSPWIKI-864
Project: JSPWiki
Issue Type: Wish
Components: Core storage
Reporter: David Vittor
Priority: Minor
Here is another idea. When I write plugins, I spend a lot of time writing
code to make sure that the parameters passed into the plugins are valid.
Things such as strings, booleans, numbers, urls, emails addresses, etc.
I was thinking if we could create a ValidationManager class that could take a
List of Validators (interface) and pass values for validation.
The two main interface method of a Validator would be:
* void validate(String value, String type) throws InvalidValueException;
* void validate(String value, String type, boolean required) throws
InvalidValueException;
** Note: by default required would be false.
The type would be a static int TYPE_EMAIL, TYPE_STRING, etc. defined in the
ValidationManager.
The ValidationManager, would have property:
* ListValidator validators;
and methods:
* void addValidator(Validator v);
* Validator removeValidator(Validator v);
* List Validator getValidators();
This would be very beneficial for all plugin developers, cause then they can
call:
*
wikiContent.getValidationManager().validate(params.get('url'),ValidationManager.TYPE_URL);
And they don't need a try catch, as the user will be told exactly what the
error was. If all parameters are valid, the plugin can continue to do it's
work.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JSPWIKI-856) Enhance FileSystemProvider to be able to save page attributes as properties
[ https://issues.apache.org/jira/browse/JSPWIKI-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Vittor updated JSPWIKI-856: - Description: *Requirements:* * 1. Plugins and other code should be able to store some page attributes into the properties of a page, just as author and changenote currently are. * 2. This should work for both FileSystemProvider and VersioningFileProvider and any future JDBCProviders or EncryptionProviders * 3. The properties added should be dynamic, e.g. all properties starting with @ like @likes, or @hitcount ** 3.1. A protected addCustomProperties() method should be done added * 4. The property names and property values should be validated ** 4.1. A protected validateCustomProperties() method should be done added ** 4.2 e.g. only contain ascii characters ** 4.3 Max property key length ** 4.4 Max property value length ** 4.5 Max number of properties was: *Requirements:* * 1. Plugins and other code should be able to store some page attributes into the properties of a page, just as author and changenote currently are. * 2. This should work for both FileSystemProvider and VersioningFileProvider and any future JDBCProviders or EncryptionProviders * 3. The properties added should be dynamic, e.g. all properties starting with db: like db:likes, or db:hitcount ** 3.1. A protected addCustomProperties() method should be done added * 4. The property names and property values should be validated ** 4.1. A protected validateCustomProperties() method should be done added ** 4.2 e.g. only contain ascii characters ** 4.3 Max property key length ** 4.4 Max property value length ** 4.5 Max number of properties Priority: Minor (was: Major) Enhance FileSystemProvider to be able to save page attributes as properties --- Key: JSPWIKI-856 URL: https://issues.apache.org/jira/browse/JSPWIKI-856 Project: JSPWiki Issue Type: New Feature Components: Core storage Affects Versions: 2.10.1 Reporter: David Vittor Priority: Minor Labels: provider Attachments: AbstractFileProvider.java, AbstractFileProvider.java, FileSystemProvider.java, FileSystemProvider.java, VersioningFileProvider.java, VersioningFileProvider.java, WikiPage.java, providers.patch, providers.patch *Requirements:* * 1. Plugins and other code should be able to store some page attributes into the properties of a page, just as author and changenote currently are. * 2. This should work for both FileSystemProvider and VersioningFileProvider and any future JDBCProviders or EncryptionProviders * 3. The properties added should be dynamic, e.g. all properties starting with @ like @likes, or @hitcount ** 3.1. A protected addCustomProperties() method should be done added * 4. The property names and property values should be validated ** 4.1. A protected validateCustomProperties() method should be done added ** 4.2 e.g. only contain ascii characters ** 4.3 Max property key length ** 4.4 Max property value length ** 4.5 Max number of properties -- This message was sent by Atlassian JIRA (v6.2#6252)
