Is there a way to access methods in the application helper from inside
the model or do I need to explicitly inject the methods I need inside
(for example) a service or gateway?
Why would you being wanting to do that? Application helpers are for views.
My logic would be to create a model that the Application Helper and your
other models can use, and promoting code reuse to boot.
Regards,
Andrew Scott
http://www.andyscott.id.au/
Well, according to the docs, the helper is a UDF library - there's no
hard rule about where you're "allowed" to use it. Sometimes it's just
easier to have a global UDF library than try to package everything,
particularly when you're talking about half a dozen unrelated methods.
Much easier to maintain and version control individual methods if
they're split out. I pack them into a CFC currently at runtime, but I
was just curious if the framework provided a mechanism to grab the
helper from somewhere other than a handler/view
Yeah I understand that, and I was more looking at reducing and reusing code.
One can very easily extend another object from the helper, but more
importantly if it is coming from a model I would also be looking at using it
in the handler more first.
I did ask why because I was curious what you intentions are, more too how
you logic was going to be working.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of oobi
Sent: Thursday, 2 December 2010 11:42 AM
To: ColdBox Platform
Subject: [coldbox:7028] Re: accessing Application helper inside model?Well, according to the docs, the helper is a UDF library - there's no hard
rule
about where you're "allowed" to use it. Sometimes it's just easier to have
a
global UDF library than try to package everything, particularly when
you're
talking about half a dozen unrelated methods.
Much easier to maintain and version control individual methods if they're
split out. I pack them into a CFC currently at runtime, but I was just
curious if
I have a core set of UDFs that cross apply to any CFCs within my app,
so I had a similar need when I found that Interceptor & Model layers
didn't inject UDFLibrary in Coldbox.cfc (ApplicationHelper.cfm).
Since they can use Autowire injection, I made a custom plugin UDF.cfc
that wrapped my UDF helper functions..
Plugin/UDF.cfc:
<cfcomponent output="false" cache="true" hint="This plugin wraps all
Coldbox helper UDFs so non-Coldbox CFCs can access it.">
<cffunction name="init" access="public" returntype="UDF"
output="false">
<cfscript>
return this;
</cfscript>
</cffunction>
<cfinclude template="/includes/helpers/ApplicationHelper.cfm">
</cfcomponent>
Then injected this plugin into my new Interceptor:
<cfproperty name="udf" inject="coldbox:myPlugin:UDF" />
I think I'll eventually refactor my UDFs to go the route where the
functions are instead housed my service layer (model.service). I just
offer this as fix to get UDF helpers into Interceptor and model
layers, as it was quick and easy to implement and still allowed DRY
code in UDFs.
ah that's a fantastic idea! Thanks!
I went the way of cfincluding it into my BaseCFC, which my BaseBean
and BaseService extend. I've never used cfinclude in a cfc before, in
any app.
I think how appropriate that is depends on what's actually in there.
In my case, it splits into two categories: Language
extension/convenience methods (plural, pick, etc), and html rendering
utilities (renderSelectOptionsFromArray,
renderRadioCheckboxGroupFromArray, etc).
FWIW, "ApplicationHelper" isn't such a great name for something that
by design has a narrower scope, which many of us find workarounds for.
(And yes I know I can name it whatever I want, but that's the
default.) the problem isn't just the name though. I'd really rather
see at least two helpers, on that's genuinely global, i.e., injected
into handlers, services, and views (maybe beans too if there's a
standard approach to that), and another one that's specific to views,
since html rendering primitives are such a common need, and they
really shouldn't be needed anywhere else.
When I first started with ColdBox, this upset me a lot, almost to the
point where I thought of writing my own framework instead, based on
previous architectures I've used. But after working with CB for a
while, I gained a huge amount of respect for everything that's
included, how it's architected, and the community and momentum around
it, and I'm doing fine with the workaround above. But I do consider it
a workaround for a (rare) architectural flaw in ColdBox.
</$.00002>
Dave
I must be missing the point of your problem.
If you want true rendering capabilities in views then you are more than
welcome to write your own set of custom tags, to render radio, checkboxes
etc. I really don't see your problem.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Dave Merrill
Sent: Saturday, 11 December 2010 11:37 PM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:7172] Re: accessing Application helper inside model?I went the way of cfincluding it into my BaseCFC, which my BaseBean and
BaseService extend. I've never used cfinclude in a cfc before, in any app.I think how appropriate that is depends on what's actually in there.
In my case, it splits into two categories: Language extension/convenience
methods (plural, pick, etc), and html rendering utilities
(renderSelectOptionsFromArray, renderRadioCheckboxGroupFromArray,
etc).FWIW, "ApplicationHelper" isn't such a great name for something that by
design has a narrower scope, which many of us find workarounds for.
(And yes I know I can name it whatever I want, but that's the
default.) the problem isn't just the name though. I'd really rather see at
least
two helpers, on that's genuinely global, i.e., injected into handlers,
services,
and views (maybe beans too if there's a standard approach to that), and
another one that's specific to views, since html rendering primitives are
such
a common need, and they really shouldn't be needed anywhere else.
When I first started with ColdBox, this upset me a lot, almost to the
point
where I thought of writing my own framework instead, based on previous
architectures I've used. But after working with CB for a while, I gained a
huge
amount of respect for everything that's included, how it's architected,
and
ah that's a fantastic idea! Thanks!
Oobi,
Actually I just found on a more elegant solution than my admittedly
bit-of-a-hack up thread (cfincluding the helper UDFs into a CFC then
autowire injecting that into Interceptor or Model layer) - and it's a
part of core Coldbox.
includeUDF() method injects (mixins) UDF functions directly into the
CFC in question.
For instance, my service layer all extend a core _service.CFC. In the
init there, I can call includeUDF('includes/helpers/
ApplicationHelper') to mixin the functions so they all can be called
as a native function in any service CFC that I extend from there.
In an Interceptor, you can do the same in the Configure() function.
<cffunction name="Configure" access="public" returntype="void"
hint="This is the configuration method for your interceptors"
output="false" >
<cfscript>
includeUDF('includes/helpers/ApplicationHelper');
</cfscript>
</cffunction>
I can then call anything I consider a global UDF across the entire app
(not just in a handler, view, or layout).
Garrr, wrote that too soon. This worked great in my Interceptor
layer... but not in Model/service layer, where includeUDF() isn't
recognized (since model isn't derived from anything w/in Coldbox).
Back to Autowiriing in a plugin that wraps my UDFs...
another good one to try -- Coldbox just keeps on giving 
re the model/service layer, perhaps you could inject a reference to
the coldbox controller and access includeUDF from there?
You could, but that seems like a rather heavy way to do a cfinclude.
includeUDF() is a nice bit of sugar but it doesn't really (as far as I
know) do anything more than act as a facade to cfinclude.
Personally, I go the route of having a Utilities cfc and I use DI to
inject it where I need it in my model.
Judah
I am not a fan of seeing bad coding and using the include to import
functions into cfc, this isn't really good OOP and promotes bad practices
going forward. If you need to then you should be looking at extending the
CFC to another CFC that carries these methods.
The other thing to note, is that by autowiring the CFC into the model or
service. You then begin to adopt better practices down the road as well.
Yeah cfinclude inside a component is a pet hate of mine, any time I see this
sort of code in an application that I maintain or take on the maintenance
off, is quickly refactorted and removed.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of muji
Sent: Tuesday, 14 December 2010 7:25 AM
To: ColdBox Platform
Subject: [coldbox:7183] Re: accessing Application helper inside model?For instance, my service layer all extend a core _service.CFC. In the
init
there, I can call includeUDF('includes/helpers/
ApplicationHelper') to mixin the functions so they all can be called as a
native
Well a utils package at least, I have a folder full of services/plugins that
arefor this purpose that are injected when needed. Very similar to the
plugins concept but without the added CB framework support.
Regards,
Andrew Scott
http://www.andyscott.id.au/
From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of Judah McAuley
Sent: Tuesday, 14 December 2010 8:42 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:7186] Re: accessing Application helper inside model?You could, but that seems like a rather heavy way to do a cfinclude.
includeUDF() is a nice bit of sugar but it doesn't really (as far as I
know) do anything more than act as a facade to cfinclude.Personally, I go the route of having a Utilities cfc and I use DI to
inject it