Looking for some open discussion here. Farcry is very clear about includedObj.
DEPRECATED; Included objects are essentially chunks of code that have nowhere else to go. For example, if you are porting ColdFusion code from another application, or trying to integrate another framework this is a likely location to place a controller or the code itself. If you’re building a pure FarCry application you should hesitate before using included objects. There is a better alternative; use type webskins instead.
However, it is still supported. So my question / discussion topic is around those “little chunks of code” that are meant to be modular, and reusable when building a site. They are not content objects, they are not page templates, just helpers we use for flexibility in the life of a site.
I would like to discuss the following.
If includedObj is “deprecated”, what is the roadmap for its removal?
What are alternative methods to includedObjs? Particularly the “chunks of code”.
What is the preferred method for creating modular / reusable “chunks of code” in FarCry?
We can plan all we want, but there always seems to be a need for something beyond the breath of a template, and the bucket of a content type. So what, and how is the proper method to design and build for it.
thanks so much community. Looking for some good discussion on how folks build things.
The “includedObj” feature was effectively just a “cfinclude” of a .cfm file, and these files lived inside the projects “/includedObj” folder. This was the “old” way of doing things back in FarCry Core 2.x / 3.x / 4.x days. The recommended way to do this now is to make use of “type webskins”.
For reference, the place where you typically see “includes” is in the site tree. Here’s the edit form for an include that I’ve created;
At the bottom you’ll notice “(Deprecated Option: Include File)”. This is where you might have configured the old “includedObj” files, such as includedObj/_sitemap.cfm.
To use the type webskin option instead you might create a webskin/dmNavigation/displayTypeBodySitemap.cfm (and restart your app), and then it would be configurable under “Content Type View” by choosing “Navigation” and “Sitemap”;
(The “Sitemap” display names comes from the <!--- @@displayname: Sitemap ---> webskin decorator at the top of the webskin)
We marked the “Include File” option as deprecated in 7.0.x and it’ll likely be removed in 8.x but as you can see there isn’t a huge burden to move from one option to the other, it’s basically just a different filename in a different folder but now follows the conventions of the rest of the framework
We’ve been using FarCry for a long time now and have relied pretty heavily on the IncludedObj to help us get through a lot of situations where the client is asking for something that the system just doesn’t do (or, we may not know exactly how to get FarCry to do it and it’s easier to just write the code).
That “chunks of code” that Corey references can be anything from a specially formatted promotion that CMS Admins might use to add content to a sidebar, it could be a feed of data from multiple object types and data not managed in the CMS, or it could just be some complicated user interface.
When I look at a newly installed version of FarCry and bring up the Edit Form for a dmInclude object, I see several options that come in the Content Type. Are these from any webskin sub-dirs that have displayTypeBodyXXX.cfm files? And then the sub-menu is driven by the Type selected? How is the “Layout” selector driven? The @@displayname in /core/webskin/dmInclude/displayBody.cfm reads ‘Standard dmInclude body display’ which is different than Standard Page.
I think one of the things that I’ve always appreciated about the “IncludedObj” folder is that it is a great repository for all of the miscellaneous things that go into a website and I’d be interested to hear from other developers how they approach organizing those types of things. For instance, is there a method to which object you choose to add displayTypeBody skins when the functionality you are writing code for isn’t directly associated with that object?
Reusable anything in the front-end is best done as a view of one form or other.
It might be easier to think in terms of example solutions to real world problems rather than trying to explain all the options in FarCry framework for generating a view for consumption.
For example, a reusable chunk of code to be rendered in the site hierarchy (or tree) might best be served by a dedicated content type. That way you can capture arguments/parameters/configuration metadata for how you might like that view to render.
Rather than having an _myRandomIncludedObj.cfm you might have a newsListing.cfc that can have an instance attached in the tree, and a configuration for the the title, teaser, number of news items, matching categories, etc.
Note, this also largely replaces the need for containers and publishing rules.
I had written a lot of includes in FarCry before we switched to the view
approach. Looking back, they were usually tied to data in some way, either
an unusual view on existing data (like news listings), or
a form that added rows to a table (like a feedback form), or
they used other advantages of being a content type like having
views/sub-views, formtools, etc (like a search form)
The rare cases that weren’t data related at all still benefited from having
their own content type for configuration and visibility in the Site Tree,
like Geoff says.
