Lets say I have the event handler / event general.index. I also have a
private method in the general event handler called validate.
How would I, within a Plugin called from general.index, invoke the
validate method of general?
runEvent can work, however I need the ability to pass args to the
method and this does not allow it. Any ideas?
Can you provide more details about this use case. Why is the plugin
trying to run a function in the event handler?
Assuming the controller is calling the plugin, couldn't the event call
the plugin, get whatever it needs from the plugin, and then run the
validate function itself.
- Gabriel
I have created a plugin that handles form validation routines, simply
by passing in the name of the field to validate from the RC and a list
of routines to run on the field (required,min_length[5],valid_email);
<cfset getPlugin('form').setValidation('email', 'required,min_length
[5],valid_email')>
As an example.
Naturally, this can grow out of scope really quick as almost every
form will have it's own needs from a validation standpoint. Since
handlers take care of validation, additional private methods can be
added to the handler, and then passed in during the setting of
validation rules.
ie
<cfset getPlugin('form').setValidation('field_name',
'customValidation')>
<cffunction name="customValidation" access="private"
returntype="boolean">
[...snip]
</cffunction
What I need to do during the running of the validation routine (where
it actually validates the fields), 1) check if a private method exists
in the handler and 2) if it does exist, invoke it passing it the
fieldname value and potentially a second argument.
I can invoke the method from within the plugin doing the following:
getController().runEvent(getcontroller().getRequestService
().getRequestContext().getCurrentHandler() & '.customValidation',
true, true)
However, this leaves me limited in the fact that I can't test for the
events existance, nor can I pass the event any arguments.
Thoughts, or perhaps a different way of going about this?
Actually, I was just thinking. What about method injection? Is it
possible to inject a method into a plugin from one that is already set
in the handler?
1. I think that form validation is like religion and politics in that
there are many different options and passionate support for them. I
have _a_ way that I currently use to handle forms that may fit with
the way you're currently handling them. Although there are many
different ways and I may convert to one in the future.
2. If each form has its own needs from a validation standpoint, you
could create an object to represent each form. If you have an object
that represents the form, then your handler can do something like:
<!--- Get the form object --->
<cfset PRC.formObj = getModel('myForm')>
<!--- Populate and Validate the form --->
<cfset PRC.formObj.populateAndValidate(RC)>
<!--- Get the result --->
<cfset result = PRC.formObj.getResult()>
In your case, the plugin would get pushed into the form object as well
as any validation functions that you're currently adding to the
handler. Any logging or notification would also get pushed into the
form object as part of the validation. The "result" is a generic error
object that is populated by the form object with the error messages.
The handler can then take whatever action is needed by looking at
what's in the result.
3. Generally speaking, form validation in the handler is definitely
one of the options out there. But splitting that up into a plugin
calling a function in the handler is not something I've seen before
and the idea "smells" bad to me even though I'm not able to articulate
well what's wrong with doing that.
- Gabriel
I agree as well. While I have definitely seen plugins/libraries for
doing form validation within the handler/controller, executing a
handler event from the plugin is something that is very unique. The
plugin, however, does first check if the method exists in the current
context (ie the instance of the plugin), before it will attempt to
look in other places.
My next thought is to simply create a cfm file and utilize
IncludeUDF's method injection. By way of conventions, I would create a
directory somewhere (maybe includes or maybe under plugins since it
relates) called validations.
/plugins/validations and have it attempt to auto load based off of
package.handler.event
so for the handler and event general.index,
includeUDF ('plugins/validations/general.cfm'), and of course fail
silently if it can't find it, since it will not be required.
This would keep the handlers a bit more clean, and would no longer be
attempting to execute this sudo plugin > handler invocation.
This does, however, make another file that I have to maintain instead
of it being inline with the handler.