handlers accessing application helper UDFS

I have setup 10 different udf functions in the application helper file
config:

UDFLibraryFile = "includes/helpers/ApplicationHelper.cfm"

for example

    <cffunction name="dt" access="public" returntype="any"
output="true">
    <cfargument name="theDate" type="date" default="now()"
required="no">
        <cfargument name="End" type="boolean" default="false"
required="no">
    <cfif End>
      <cfreturn createDateTime(year(arguments.theDate),
month(arguments.theDate), day(arguments.theDate), 11, 59, 59)>
        <cfelse>
          <cfreturn createDateTime(year(arguments.theDate),
month(arguments.theDate), day(arguments.theDate), 0, 0, 0)>
        </cfif>
    </cffunction>

and I am unable to access these udfs via my handlers.

any ideas?

thank you again for your help

btw, i am reinit the application - i am on osx, cf8.1, cb 3 m6

update:

I can access the helper udfs from my views, but not handler when I run
an event from a separate handler, do they have to be injected to work
correctly? I do not see anything in the guides to setup a udf function
to be injected?

I could be wrong here, but if you read the documentation the helper files
are more of a way to do custom tag type stuff. And because these are view
helpers then they will be available to your views only.

What exactly are you wanting to do?

In my opinion if you are wanting a UDF inject you can either do this as a
plugin, and or a service/model.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of chris hough
Sent: Friday, 1 October 2010 9:22 AM
To: ColdBox Platform
Subject: [coldbox:6025] Re: handlers accessing application helper UDFS

update:

I can access the helper udfs from my views, but not handler when I run an
event from a separate handler, do they have to be injected to work
correctly? I do not see anything in the guides to setup a udf function to

be

I am wanting to have a set of udfs accessible to all of my handlers,
basically helper functions - this would be similar to all of my class
files extending a base class where all the common shared udf functions
would exist. what is the proper way to set this up in CB?

Why would you do this, versus creating a superclass, if all your
handlers will be using these? I've had similar needs and the way I
handled it was to have a superclass that extended the framework
eventhandler, and then was inherited by the individual handlers.

Just asking so I can understand this thing better. Never too old of a
dog to learn! :wink:

Kevin

sorry to sound like a noob here, but do you have an samples for your
recommendation? this sounds like the right approach

No worries, Chris, and I'm hoping your question below was to my earlier
email. I've been doing CF to a *long* time (since first out in
O'Reilly's Web Site Pro), BUT, ColdBox is new to me. Very amazing
framework, but I'm struggling to get my arms around it!

Here is a sample of what I have in one of my ongoing development...

---[ handler.public.cfc ]-----------------------------------
component extends="HandlerHelper" output="false" autowire="true"
{
  /* Dependency injections, etc. */
  ...

  public void function index(any event)
  {
    ...event processing code and model invokes, etc...
  }

}

---[ handler.HandlerHelper.cfc ]--------------------------
component extends="coldbox.system.eventHandler" output="false"
{

  private string function encryptor(required string pwd)
  {
    var rc = "";

    ...code to encrypt provided pwd string...
    return rc;
  }

}

It would be very important to make sure you don't use any reserved
method names, etc., but I'm sure you knew that. Hope this is somewhat
helpful.

Cheers!

Kevin

ty soo much kevin, I am learning CB as well, loving every minute of
it.

I have been tasked with a very large rearchitecture project and CB
makes my life so much easier.

your example worked perfectly, thank you so much :slight_smile:

I would guess a plugin, but it depends on what they are going to do.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of chris hough
Sent: Friday, 1 October 2010 11:46 AM
To: ColdBox Platform
Subject: [coldbox:6029] Re: handlers accessing application helper UDFS

I am wanting to have a set of udfs accessible to all of my handlers,

basically

helper functions - this would be similar to all of my class files

extending a

(FYI, I have a long time w CF, extremely new to CB, bring grains of
salt accordingly...)

The pattern where some methods are common to all handlers, and some
are common to a subset of them, seem perfect for an inheritance model,
as Kevin suggested. For instance, you might have a BaseHandler.cfc
(common to all), BaseAuthenticatedHandler (common to all handlers
whose methods can only be accessed by logged in users).

To be honest, one of the things that's holding me up from getting more
completely involved with ColdBox is that view and layouts are cfms,
not cfcs, so you can't build an inheritance tree at that level. For
quite a while now, I've built views as cfc methods, and it works
great. Global utilities like rendering sets of html select options,
groups of radios, etc, belong in BaseView. More specific things like
renderDepartmentPicker belong in a base class that inherits from
BaseView and is the basis for all views in the part of the world that
need that facility.

It also provides a great place to put private helper methods specific
to one view, or a related set of them. I also like that its structure
parallels the other cfc-based layers.

None of the frameworks I'm aware of do views as cfcs, so obviously I'm
in the minority in wishing for this, but it just makes so much sens to
me. Some people seem to feel that it's "just wrong" to write view code
in a cfc, but not to me. If it's really huge, I might break it out
into a separate include that the cfc method calls; you just have to be
careful to 'var' all the locals it uses too (my views are singletons).

Dave

The one thing you will learn over time is especially if you ever go an write
anything in a true MVC language, is that views are completely separate to
components or classes.

In your example if you have to write anything that is returned in via
component, I can show you a much better way of doing it.

I don't want to come across as a know it all, or even that I have been
around developing for a long time. However we all know that ColdFusion
allows us to do things that might be considered wrong by other languages.

In my opinion you might be better to go and learn a true MVC framework that
is not ColdFusion, and you would very quickly learn there is a huge
difference. In other words why would you use a CFC/Component to do views, or
layouts? This is normally handles by standard templates and nothing more.

If a CFC makes sense to you to use as a view and/or layout then you are in
my opinion in the extreme minority, and you should go and learn grails in
which ColdBox is modelled from. In grails they use java as everything
outside of the view, and for the view they use the thing that you might call
JSP which is equivalent to ColdFusion templates and or custom tags.

If you ask me you need to learn other languages, because you might learn the
ColdFusion allows you to do things that others would think is not normal as
you have described, and in time you might learn that even if the language
allows you to do something that doesn't mean the framework you are using is
allowing you to do it this way either.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Friday, 1 October 2010 10:42 PM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6035] Re: handlers accessing application helper UDFS

(FYI, I have a long time w CF, extremely new to CB, bring grains of salt
accordingly...)

The pattern where some methods are common to all handlers, and some are
common to a subset of them, seem perfect for an inheritance model, as
Kevin suggested. For instance, you might have a BaseHandler.cfc (common
to all), BaseAuthenticatedHandler (common to all handlers whose methods
can only be accessed by logged in users).

To be honest, one of the things that's holding me up from getting more
completely involved with ColdBox is that view and layouts are cfms, not

cfcs,

so you can't build an inheritance tree at that level. For quite a while

now, I've

built views as cfc methods, and it works great. Global utilities like

rendering

sets of html select options, groups of radios, etc, belong in BaseView.

More

specific things like renderDepartmentPicker belong in a base class that
inherits from BaseView and is the basis for all views in the part of the

world

that need that facility.

It also provides a great place to put private helper methods specific to

one

view, or a related set of them. I also like that its structure parallels

the other

cfc-based layers.

None of the frameworks I'm aware of do views as cfcs, so obviously I'm in
the minority in wishing for this, but it just makes so much sens to me.

Some

people seem to feel that it's "just wrong" to write view code in a cfc,

but not

to me. If it's really huge, I might break it out into a separate include

that the

cfc method calls; you just have to be careful to 'var' all the locals it

uses too

Hmmm, I understand that views aren't objects in the sense that they
have instance data. Still, it seems like a mental habit, nothing more,
to think that they shouldn't have a hierarchical inheritance scheme,
with more general and more specific views that are still related.
They're templates, yes, but that doesn't make them completely
unrelated to all other templates.

From the research I've done on the original meaning of MVC, I don't
actually think it applies to the web at all. The original context was
a relatively static GUI frame that the user acted on. Events were
detected by the controller, which told models to alter their data, and
views updated themselves when they were notified of data changes to
which they'd subscribed. On the web, the controller gets modified of
user actions and potentially modifies data, but views don't get
subscribe to or get notified about that, they just run in the world as
it is post those modifications.

That's not to say that separating control logic, domain data, and UI
rendering isn't very important, it is. Most web frameworks call this
pattern MVC, and that's fine -- meaning can evolve to suit current
usage -- but if you look at the history of the pattern, I believe it's
changed.

Anyway, bottom line is that if views or layouts need helper functions,
either you end up with some mechanism to "inject" a patchwork of
helper files, or you build a layered collection of view objects, with
appropriate facilities at each level. That's what I prefer, so far.

Dave

Eh, "the controller gets *notified* of user actions".

Dave

I am not sure if you are aware of it or not, but in some frameworks and Luis
has just implemented this as well. A view can be called without running a
controller.

But I am lost in what it is your actually wanting to do.

For building hierarchy of views, sure that is not a problem if that was your
original thinking. I do it with a layout that might have a view that might
have up to 15 viewlets.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Saturday, 2 October 2010 1:36 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6037] Re: handlers accessing application helper UDFS

Hmmm, I understand that views aren't objects in the sense that they have
instance data. Still, it seems like a mental habit, nothing more, to think

that

they shouldn't have a hierarchical inheritance scheme, with more general
and more specific views that are still related.
They're templates, yes, but that doesn't make them completely unrelated to
all other templates.

From the research I've done on the original meaning of MVC, I don't

actually

think it applies to the web at all. The original context was a relatively

static

GUI frame that the user acted on. Events were detected by the controller,
which told models to alter their data, and views updated themselves when
they were notified of data changes to which they'd subscribed. On the web,
the controller gets modified of user actions and potentially modifies

data, but

views don't get subscribe to or get notified about that, they just run in

the

world as it is post those modifications.

That's not to say that separating control logic, domain data, and UI

rendering

isn't very important, it is. Most web frameworks call this pattern MVC,

and

that's fine -- meaning can evolve to suit current usage -- but if you look

at the

history of the pattern, I believe it's changed.

Anyway, bottom line is that if views or layouts need helper functions,

either

you end up with some mechanism to "inject" a patchwork of helper files, or
you build a layered collection of view objects, with appropriate

facilities at

You can actually do what you want to do but you have to do the rendering yourself.

Basically a handler would return the contents to be rendered from your own renderer, or just create your own renderer plugin

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Sorry if I wasn't clear. While I am interested in wrapping view output
in a layout container, and potentially wrapping that layout's output
in another layout etc, that's not what I was getting at in talking
about view and layout CFCs and inheritance among them.

There are some utility-level functions that I'd like to have available
to all views, things like renderHTMLSelectOptionsFromArray,
renderCheckboxRadio, renderCheckboxRadioSet, and so on. It's also
common to want certain widget rendering functions in related views;
for instance UserView.profileEdit and UserView.admin may both want
renderUserCategorySelect. Individual views may also have rendering
utilities unique to them, broken out into separate functions not
because they're common to multiple views, but for readability -- I
rather see renderPhoneNumbers(phoneData) in a view than the actual
code to iterate over that data and output a series of fields and the
javascript to edit them inline.

To me, the cleanest way to handle all of this is to built views as CFC
methods. Locally unique helper functions are just methods of the view
CFC that needs them. So are methods common to various domain-specific
views; UserView contains renderUserCategorySelect, for example.
Generic things like renderHTMLSelectOptionsFromArray go in BaseView,
from which all views eventually inherit. If you need it, methods
common to a series of view CFCs go in an intermediate base class that
extends BaseView, and that the relevant individual views extend. If
you're returning raw data from some ajax calls (rather than HTML), you
may have some JSON or XML rendering utilities you could put in an
BaseAjaxView class (a little contrived, and there may be better
approaches, but you get the idea).

You may also find that there are some useful pseudo-constants you
could declare in the init code for a view or base view, things like
HTML_SELECT_OPTION_NONE = '-- select --', or whatever you like.
Completely universal "language extensions" and CFML-version-leveling
tools like structMake and arrayMake can go in a BaseCFC that BaseView
and other base classes extend. So do shortcut "constants" like CR, LF,
CRLF, and TAB.

If the code for a view gets uncomfortably big, a view method can
cfinclude a separate file, leaving only the argument and local 'var'
declarations in the CFC method itself.

So views aren't objects in the sense that they represent business
logic, or have instance data. Still, they can be built as singletons
that inherit from a BaseView containing whatever common utilities you
want, and possibly from more specific base classes with methods common
to some set of view classes.

I see this approach as an organized, organic, and encapsulated
approach to view helpers. Yes views are "just templates", but they've
got code in them, some of which is highly reusable, and they're
related in various ways to other views, and even somewhat to non-view
components. There's no reason to think of views as unique creatures
that need a completely different approach to reuse and
interrelatedness than everything else. The fact that
jsp/Velocity/Smarty/insert-favorite-templating-engine-here don't do
this doesn't mean we can't.

I certainly don't mean to criticize ColdBox, any other framework, or
their makers or users; they deserve a huge amount of respect. I'm just
talking about another way I've built views in the past, sans
framework, and why that works for me. The fact that that approach
isn't available in any frameworks I'm aware of may mean that I have
poor judgment and should be ignored (:-). Or maybe it's something
worth thinking about.

Dave

Actually I disagree with you.

You claim to want something to render checkboxers and/or radio buttons.
These sort of things are best left to custom tags, that is what they are
designed for, the problem is people don't know how to use them or don't even
consider them.

In my opion if you are looking for this sort of helper
methods/classes/templates then you should be thinking about the use of
customtags.

Regards,
Andrew Scott
http://www.andyscott.id.au/

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Saturday, 2 October 2010 9:47 PM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6047] Re: handlers accessing application helper UDFS

Sorry if I wasn't clear. While I am interested in wrapping view output in

a

layout container, and potentially wrapping that layout's output in another
layout etc, that's not what I was getting at in talking about view and

layout

CFCs and inheritance among them.

There are some utility-level functions that I'd like to have available to

all

views, things like renderHTMLSelectOptionsFromArray,
renderCheckboxRadio, renderCheckboxRadioSet, and so on. It's also
common to want certain widget rendering functions in related views; for
instance UserView.profileEdit and UserView.admin may both want
renderUserCategorySelect. Individual views may also have rendering

utilities

unique to them, broken out into separate functions not because they're
common to multiple views, but for readability -- I rather see
renderPhoneNumbers(phoneData) in a view than the actual code to iterate
over that data and output a series of fields and the javascript to edit

them

inline.

To me, the cleanest way to handle all of this is to built views as CFC

methods.

Locally unique helper functions are just methods of the view CFC that

needs

them. So are methods common to various domain-specific views; UserView
contains renderUserCategorySelect, for example.
Generic things like renderHTMLSelectOptionsFromArray go in BaseView,
from which all views eventually inherit. If you need it, methods common to

a

series of view CFCs go in an intermediate base class that extends

BaseView,

and that the relevant individual views extend. If you're returning raw

data

from some ajax calls (rather than HTML), you may have some JSON or XML
rendering utilities you could put in an BaseAjaxView class (a little

contrived,

and there may be better approaches, but you get the idea).

You may also find that there are some useful pseudo-constants you could
declare in the init code for a view or base view, things like
HTML_SELECT_OPTION_NONE = '-- select --', or whatever you like.
Completely universal "language extensions" and CFML-version-leveling tools
like structMake and arrayMake can go in a BaseCFC that BaseView and other
base classes extend. So do shortcut "constants" like CR, LF, CRLF, and

TAB.

If the code for a view gets uncomfortably big, a view method can cfinclude

a

separate file, leaving only the argument and local 'var'
declarations in the CFC method itself.

So views aren't objects in the sense that they represent business logic,

or

have instance data. Still, they can be built as singletons that inherit

from a

BaseView containing whatever common utilities you want, and possibly from
more specific base classes with methods common to some set of view
classes.

I see this approach as an organized, organic, and encapsulated approach to
view helpers. Yes views are "just templates", but they've got code in

them,

some of which is highly reusable, and they're related in various ways to

other

views, and even somewhat to non-view components. There's no reason to
think of views as unique creatures that need a completely different

approach

to reuse and interrelatedness than everything else. The fact that
jsp/Velocity/Smarty/insert-favorite-templating-engine-here don't do this
doesn't mean we can't.

I certainly don't mean to criticize ColdBox, any other framework, or their
makers or users; they deserve a huge amount of respect. I'm just talking
about another way I've built views in the past, sans framework, and why

that

works for me. The fact that that approach isn't available in any

frameworks

Um, to each their own?

Not sure where you got the idea I might not know how to use custom
tags. Also not sure why they're so much better suited to rendering
select options or sets of checkboxes than methods or functions.
ColdBox supports view helpers, so it looks like I'm not the only one
who finds functions useful for rendering.

Anyway, just some ideas, nothing you have to do or even think about if
you don't want to.

Dave