Global view helper

Communities ColdBox HMVC
1

I see that there are view- and folder-specific helpers by convention.
Is there such a thing as a global view helper, that gets mixed into
all views (and ideally layouts)?

Thanks,
Dave

2

Looks like a partial answer is the UDFLibrary setting in coldbox.xml.
That file gets injected into handlers, as well as views and layouts,
which is a little weird, since the UDFs I'm thinking of here are
rendering utilities that don't have any use in handlers as far as I
can see. I do have some genuinely global utilities I want available
*everywhere*, so I've put them in the global UDFLibrary file, and at
least for now I've put these rendering tools there too, but it's not
completely appropriate. Similarly, as I've noted in another msg, those
globals aren't fully universal, since they're not injected into
services or beans, presumably so model components are completely
standalone.

Personally, I'd prefer somewhat tighter granularity. I wonder if a
preRender interceptor that loaded a configured UDF file would make
those functions available to views and layouts.

Dave

3

The udflibrary setting is an application helper for views/layouts and handlers.

If you want things in your services, they I would do it manually, the domain model is not the concern of the framework, but your specific requirements. So I would probably leverage the life cycle events of the model to do such things or have utility classes to help in the domain model

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

4

Thanks for jumping in Louis. I understand that services should be
decoupled from the framework, and that that's a good thing.

The things I'm talking about really fall into two classes I think:
low-level language extensions like structMake and arrayMake (backwards
compatibility for {...} and [...] respectively), and html rendering
utilities like renderSelectOptions and renderCheckboxRadioGroup.

The languages extension ideally should be available everywhere --
handlers, views, layouts, services, beans, interceptors, plugins,
etc. What I've done so far is 1) add them to the UDFLibrary file, and
2) cfinclude the UDFLibrary file in a BaseCFC (never did that before),
which a BaseService and BaseBean extend, and extend those base classes
for those types of objects. Now that ColdBox doesn't require you to
extend its components, we're free to leverage our own inheritance
hierarchy, for things like this and for higher-level reasons.

But the rendering tools get stickier. For now I've added them to the
UDFLibrary file too, which works, but they don't belong in services or
beans at all, and really not in handlers either. I haven't had a
chance to try having a pre-render interceptor cfinclude a rendering
tools UDF file. Would that make those functions available to views and
layouts? I'm not sure of the scoping at the point that interceptor
runs.

What I was thinking would be helpful was a second UDF library config,
maybe renderingUDFLibrary, which would automatically get
injected/included/whatever into views and layouts, but not into
handlers. Does that make sense to you? I'd think other people would
have the same need for HTML rendering tools.

Dave

5

Dave,

I usually do that sort of HTML rendering helper tools in a plugin, then you can just call the plugin from any view or layout. In fact, there is a plugin in the framework called HTMLHelper you may find useful or may want to extend from for your helper plugin.

http://wiki.coldbox.org/wiki/Plugins:HTMLHelper.cfm

Make sense?

Curt

6

I still think you are over complicating your needs, View Rendering tools
like you are asking for are still best handled via cfmodule and custom tags.

Unless I am not understanding what you are trying to do, how about an
example of the helper you are describing as a view?

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

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Tuesday, 12 October 2010 11:10 PM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6205] Re: Global view helper

Thanks for jumping in Louis. I understand that services should be

decoupled

from the framework, and that that's a good thing.

The things I'm talking about really fall into two classes I think:
low-level language extensions like structMake and arrayMake (backwards
compatibility for {...} and [...] respectively), and html rendering

utilities like

renderSelectOptions and renderCheckboxRadioGroup.

The languages extension ideally should be available everywhere --

handlers,

views, layouts, services, beans, interceptors, plugins, etc. What I've

done so

far is 1) add them to the UDFLibrary file, and
2) cfinclude the UDFLibrary file in a BaseCFC (never did that before),

which a

BaseService and BaseBean extend, and extend those base classes for those
types of objects. Now that ColdBox doesn't require you to extend its
components, we're free to leverage our own inheritance hierarchy, for
things like this and for higher-level reasons.

But the rendering tools get stickier. For now I've added them to the
UDFLibrary file too, which works, but they don't belong in services or

beans

at all, and really not in handlers either. I haven't had a chance to try

having a

pre-render interceptor cfinclude a rendering tools UDF file. Would that

make

those functions available to views and layouts? I'm not sure of the

scoping at

the point that interceptor runs.

What I was thinking would be helpful was a second UDF library config,

maybe

7

Thanks guys.

@ Curt: Did check out the HTML Helper, didn't seem to be what I need,
but I'll take another look. A plugin isn't completely desirable,
because lots of calls to its methods is a little verbose. You could do
htmlPlugin = getPlugin(...), then call htmlPlugin.renderSelectOptions,
it's just a bit clunkier than having the functions just available. I'm
used to having these sorts of functions close at hand (methods in a
view CFC, which ColdBox doesn't support). Just exploring ColdBox-way
approaches to achieve something similar; a plugin isn't too bad I
suppose.

@ Andrew: There are examples of simple rendering functions in my reply
to Louis. I know from earlier conversations that you prefer this kind
of stuff in custom tags, but in general I prefer functions. Among
other reasons, that's because they're callable from cfscript or
tag-based code, and they can return strings for further processing
without passing in the name of a return var, or the tag having the
side effect of setting vars in the caller scope, and having to open
the tag to see which ones get set.

Dave

8

Each to their own. But to be honest setting vars in the caller scope is not
considered good practice.

As for HTML Rendering tools I will stand by what I said, for example how
would you do this in your way of thinking?

  <cs:form>
    <cs:grid name="AndrewTest"
bind="#event.buildLink('general.getparks')#" width="700" height="350"
pageSize="20" defaultSortColumn="posted">
      <cs:gridItem name="TITLE" caption="Title"
width="470" />
      <cs:gridItem name="RELEASED" caption="Released"
width="69" Renderer="trueFalseFormat"/>
      <cs:gridItem name="POSTED" caption="Posted"
width="69" renderer="dateFormat" />
      <cs:gridItem name="VIEWS" caption="Views" width="69"
/>
      <cs:gridBottomBar />
    </cs:grid>
  </cs:form>

I stand by what you're talking about should be considered as a plugin, and
yes these are going to be released soon as a replacement to the ColdFusion
grids.

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

From: coldbox@googlegroups.com [mailto:coldbox@googlegroups.com] On
Behalf Of enigment
Sent: Wednesday, 13 October 2010 1:33 AM
To: coldbox@googlegroups.com
Subject: Re: [coldbox:6208] Re: Global view helper

Thanks guys.

@ Curt: Did check out the HTML Helper, didn't seem to be what I need, but
I'll take another look. A plugin isn't completely desirable, because lots

of calls

to its methods is a little verbose. You could do htmlPlugin =

getPlugin(...),

then call htmlPlugin.renderSelectOptions, it's just a bit clunkier than

having

the functions just available. I'm used to having these sorts of functions

close

at hand (methods in a view CFC, which ColdBox doesn't support). Just
exploring ColdBox-way approaches to achieve something similar; a plugin
isn't too bad I suppose.

@ Andrew: There are examples of simple rendering functions in my reply to
Louis. I know from earlier conversations that you prefer this kind of

stuff in

custom tags, but in general I prefer functions. Among other reasons,

that's

because they're callable from cfscript or tag-based code, and they can

return

strings for further processing without passing in the name of a return

var, or

the tag having the side effect of setting vars in the caller scope, and

having to