I am working on migrating an application to an framework application (specifically Fusebox 5.5). I would need to extend two Application.cfc [Fusebox5.Application] and another Application.cfc that sits in a folder a couple directories up. Below is the directory structure:
--WebRoot
--Fusebox5 <---(This is where the corefiles for Fusebox is stored)
--Folder1 <---(This is the Application.CFC file I want to extend)
--sub-Folder1
--sub-subOfFolder1
--sub-sub-subOfFolder1
--Application Folder (This is where the application lives)
The Application.cfc file has the following code:
<cfcomponent extends="fusebox5.Application" output="false">
It's not as simple as adding fusebox5.Application,Folder1.Application, but basically, is what I want to do. Any help would be appreciated.
Couple caveats:
I do NOT want to make any impact on any existing code outside of the Application folder. I read about extending an ApplicationProxy.cfc and would probably be willing to try that out, but that would be the extent of any modifications to existing code base.
I can consider an alternative framework, but a lot of the existing code base that I'm migrating would not lend itself very well. My primary objective would simply to be organize code.
Without knowing which bits from which Application.cfc you need to re-use, it's difficult to answer this.
However you cannot have multiple inheritance in CF. I guess you know this.
You could conceivably create a new CFC in your sub app which extends the one in the main app, and then create an instance of that wihthn your sup-app's Application.cfc. You can then call its public methods and access its THIS scope as needs must.
And your sub-app can then extend the Fusebox one as per normal.
Or, possibly, do it the other way around, depending on which makes more sense.
Other than that, you could refactor the bits you need from the main app into some other construct (and include file, a different CFC or something), and then call that code from each of the main-app and sub-app, and again extend Fusebox from the sub-app. Obviously this means monkeying with the main app, and regression testing again, etc.
Related
I'm working on the new system and there are few things that are different from what I used to see. Basically there is an JQuery ajax call with "POST" type and url pointing to .cfm page. The .cfm page will return html table.
After talking to lead developer he mentioned that this method is more efficient. This way calling .cfm we do not create new instance each time we make a call. The other way if we use .cfc and call a function new instance will be created each time. I do not know everything behind the screen and deep layers of ColdFusion.
One other thing he mentioned this way it's better since we do not use any frameworks. I have been working with ColdFusion for the past 4 years and what I seen in the past is JQuery Ajax calling component.cfc with specific method name. The data is returned and table is built dynamically. I was wondering if someone knows more about this and why the .cfm might be better than calling .cfc.
Thank you.
To long for a comment
I agree with what the others have already said. There is no specific answer because it always depends on more things than just this bit of code. Having said that...
I found this from the Adobe documentation here which seems relevant. Below is an excerpt from that documentation. I highlighted in bold the part which seems relevant. Notice the part about after the CFC is instantiated. You can read more at the link.
When to use CFCs
You can use CFCs in the following ways:
Developing structured, reusable code
Creating web services
Creating Flash Remoting elements
Using asynchronous CFCs
Developing structured, reusable code
CFCs provide an excellent method for developing structured applications that separate display elements from logical elements and encapsulate database queries. You can use CFCs to create application functionality that you (and others) can reuse wherever needed, like user-defined functions (UDFs) and custom tags. If you want to modify, add, or remove component functionality, you make changes in only one component file.
CFCs have several advantages over UDFs and custom tags. These advantages, which CFCs automatically provide, include all of the following:
The ability to group related methods into a single component, and to group related components into a package
Properties that multiple methods can share
The This scope, a component-specific scope
Inheritance of component methods and properties from a base component, including the use of the Super keyword
Access control
Introspection for CFC methods, properties, and metadata
CFCs have one characteristic that prevents them from being the automatic choice for all code reuse. It takes relatively more processing time to instantiate a CFC than to process a custom tag. In turn, it takes substantially more time to process a custom tag than to execute a user-defined function (UDF). However, after a CFC is instantiated, calling a CFC method has about the same processing overhead as an equivalent UDF. As a result, do not use CFCs in place of independent, single-purpose custom tags or UDFs. Instead, use CFCs to create bodies of related methods, particularly methods that share properties.
For more information about UDFs, custom tags, and other ColdFusion code reuse techniques, see Creating ColdFusion Elements.
Creating web services
ColdFusion can automatically publish CFC methods as web services. To publish a CFC method as a web service, you specify the access="remote" attribute in the method's cffunction tag. ColdFusion generates all the required Web Services Description Language (WSDL) code and exports the CFC methods. For more information on creating web services in ColdFusion, see Using Web Services.
Now I don't always trust the Adobe documentation as they have a nasty habit of just carrying forward the existing documentation from version to version. So who knows when this was originally written and if it is still true. And this is specific to Adobe's ColdFusion, Lucee is likely better at handling this but I'm not sure.
That document also refers to this document - Selecting among ColdFusion code reuse methods. I will include that info here as well.
The following table lists common reasons to employ code reuse methods and indicates the techniques to consider for each purpose. The letter P indicates that the method is preferred. (There can be more than one preferred method.) The letter A means that the method provides an alternative that is useful in some circumstances.
This table does not include CFX tags. You use CFX tags only when it is best to code your functionality in C++ or Java. For more information about using CFX tags, see Using CFX tags.
I'm new to Django and fairly confused about how third-party apps are best integrated. In my (possibly naive) interpretation of DRY, I want to minimize copy/pasting not only my own code but other people's code as well, so I'm happy with, for example, the pattern of using contrib.auth as mostly a black box if I needed additional info on auth.User (by extending auth.User with a UserProfile object or inheritance). And this was how I imagined I'd use most third-party apps as well.
However, I quickly found out this was very difficult, so now I've resigned to having "copies" of all of my third-party apps living inside my project folder that are basically entire copies with minimal changes. The final straw was me wanting to add a basic blog (I settled on django-basic-blog) and needing to just change a single template, and I thought of no better solution than just making a copy of that app inside my project with the single template changed.
My questions:
in this specific case where I need to change just a single template, is this (copy the entire app over) the best I can do? If I just needed to change a single model I can keep the third-party app respectfully intact and do a model inheritance in my own app...
in general, this practice of copying the apps under my project and patching each a tiny bit feels crazily wasteful and dirty. It also feels like if I'm using a frequently-updated third-party app it will be a pain to sync the changes. Should I just learn to love the bomb or is there some obvious architectural pattern / Django-provided assistance I am missing?
You should not modify the code of 3rd-party modules, as it's hard to track the changes and it creates a mess with the same code copied into many projects. Typical solution is to have only one version of each third-party module in your python path, not in your project's dir. This single package can then be reused by all of your projects.
However different approach is needed for templates, as they often need to be modified on a per-project basis. That's why Django comes with settings.TEMPLATE_DIRS and settings.TEMPLATE_LOADERS.
TEMPLATE_DIRS specifies list of directories containing template files. TEMPLATE_LOADERS specifies the classes used to load templates. The loaders will be used in order they were defined and the directories will be traversed in order they were defined. So you can look for templates in your project's directory first and in other modules as a fallback.
So basically you do not need to copy the entire python module in order to change one template. Copy just the templates directory of that 3rd party module or even just the single template you want to change. If you'll put in the right place and add have the path in TEMPLATE_DIR Django will use it.
I am new to Joomla, started learning it just a day ago and didn't manage to find an answer to my question in the docs (which suck real bad compared to Drupal).
So what I want to do is override the whole module in a template. The documentation only suggests I can override the markup of a module by placing corresponding files in the html folder, but I have to make some corrections to the actual logic. Is copying the module, changing and then installing it as a separate entity the only way to go? I mean it makes sense that "template" folder is for "views" but with the kind of application I have to develop it is gonna be annoying...
Yeah, you can only override views.
If you want to override logic, you have 2 options:
Change the actual logic in-place, which leads to problems on updating etc
Duplicate the module and change the logic, as you suggested
One other way to consider is to replicate or fix the logic in the template. While this is not a very slick way of doing it, it is faster, especially than duplicating a whole component.
Note that you can also add your own libraries to the Joomla libraries folder to centralize your own code.
Further, if you manage your code with (for example) svn, you should not have any problems on upgrades with creating new views that may include their own logic.
I'm starting a a new application, and want to concentrate on making it modular. What I mean by that is that is that in my head I envisage some basic facilities log on, user roles, layouts etc but then I am looking to be able to be able to add self contained "chunks" of functionality e.g. document repository and upload, diary and reminder service .. whatever.
How I've been laying out apps so far is simply everything in root, separate subfolders for images and cfcs, sticking to naming conventions for variable and query names etc, all database interaction via cfcs, doing all my processing at the top of the page, then a comment line then display/page layout below that.
I have tried and failed to get my head around the various frameworks out there, but I just get paralysed with indecision and confused about whether I'm doing it "right". Is there a way of working that has some acceptance of being a useful methodology without getting in to the whole official "framework" thing?
Then you probably want to separate your presentation layer from the core as much as possible. A good and popular way to do this that is picking up speed very fast is following the MVC (model-view-controller) pattern
http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller
This will allow you to modulate functionalities into controllers that are completely seperate from layout, etc. The controllers can then more easily be integrated into other projects as need be.
I know you said you didn't want framework and you most certainly don't need one but I strongly suggest it for larger application such as what you are describing. Some can have so many rules and what not that they seem to get in the way a lot. One that I like, which is based on Ruby on Rails called CFWheel (http://cfwheels.org/).
It's pretty much there to help you structure stuff, you are free to follow the "normal" way or not it won't really stop you. Have a look at the screencasts here: http://cfwheels.org/screencasts
Model Glue is an excellent CF Framework. The google group support + docs are great.
FW/1 is another simpler framework to start learning, not sure about the docs at this point.
Frameworks are definately the way to go. Once you get your head around them, they just feel "right". They tend to make you write better code, and having used a coldfusion framework for a year or so now, I can honestly say I'll never go back to not using one 8-)
Honestly, the frameworks can lead to analysis paralysis quite easily. You can easily over think things. Here is what you do, keep it simple and just bang away at the keyboard. Use your "own" framework. It might not be pretty, but you'll get it eventually and you'll see why the other frameworks exist.
Here is how you start:
Create folders layouts and views. Put all your page layout stuff in the layouts folders (you'll probably have only a few and maybe even one layout)! Put all of your view stuff in the views folder (this will probably look like what you've been doing with a bunch bunch of files not very well organized). The key is that you won't have ANY page processing "top of page" code in your view files.
Your index.cfm will be the only .cfm root. Use a URL variable "event" = action to make your framework go.
In your index.cfm, use a giant cfswitch to determine which "top of page" code to execute (this will be a giant "controller").
mysite.com/index.cfm?event=contactInfo
<cfswitch expression="#url.event#">
<cfcase value="contactInfo">
<top of page code>
<cfset structLayoutInfo["pagetitle"] = "XYZ Contact Info" />
<cfmodule template="/layouts/mainlayout.cfm" attributeCollection="#structLayoutInfo# >
<cfinclude template="/views/contactInfo.cfm"/>
</cfmodule>
</cfcase>
.....
</cfswitch>
Combine this with the cfmodule tag to load your layout. So, all your page requests come in through index.cfm. Index.cfm will do all the top of page stuff and then do a cfinclude to the appropriate view in your views folder. Use the cfmodule tag to load your layout (check out the tag.execution mode stuff for headers and footers).
You'll keep adding features and adding features to your framework. You'll probably move the index.cfm code to a controller folder with a bunch of CFCs that call your database CFCs.
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.