UPDATE: Seems that railo doesn't have this issue at all.
UPDATE: I'm voting to close this issue as i as feel people are focusing more on the whole "does someone have a better idea splitting up large components" part of this question (which i should never have put in) then the real problem of using cfincludes with cfcomponent.
Note: this is just a simplified example of what i'm trying to do to get the idea across.
The problem I'm having is that I want to use cfinclude inside cfcomponent so that i can group like methods into separate files for more manageability. The problem I'm running into is when i try to extend another component that also uses cfinclude to manage it's method as demonstrated below. Note that ComponentA extends ComponentB:
ComponentA
==========
<cfcomponent output="false" extends="componentb">
<cfinclude template="componenta/methods.cfm">
</cfcomponent>
componenta/methods.cfm
======================
<cffunction name="a"><cfreturn "componenta-a"></cffunction>
<cffunction name="b"><cfreturn "componenta-b"></cffunction>
<cffunction name="c"><cfreturn "componenta-c"></cffunction>
<cffunction name="d"><cfreturn super.a()></cffunction>
ComponentB
==========
<cfcomponent output="false">
<cfinclude template="componentb/methods.cfm">
</cfcomponent>
componentb/methods.cfm
======================
<cffunction name="a"><cfreturn "componentb-a"></cffunction>
<cffunction name="b"><cfreturn "componentb-b"></cffunction>
<cffunction name="c"><cfreturn "componentb-c"></cffunction>
The issue is that when i try to initialize ComponentA I get an the error: "Routines cannot be declared more than once. The routine a has been declared twice in different templates."
The whole reason for this is because when you use cfinclude it's evaluated at RUN TIME instead of COMPILE TIME.
Short of moving the methods into the components themselves and eliminating the use of cfinclude, how can i get around this or does someone have a better idea splitting up large components?
My advice is: reanalyze your objects, try to apply to all the OOP rules and best practices (abstraction, encapsulation, modularity, polymorphism, inheritance, DRY etc.).
So basically you want component B to have method isCrunchable(), then component A extends B, and isCrunchable() is available from inheritance. Both A and B will return different states so I don't see any problem with this. If you make one class "above" which has all the methods and components A and B extend that one, you'd get your solution for "large components", but again, I'd try to crunch this a little bit more.
If this answer doesn't help, you can post real example, maybe we'll get better idea why you need this done like that.