Geoff, Agreed, however, we're finding ourselves in the unique(?) situation of requiring a member profiling system that is tightly coupled with the dmSec security system... This allows members to login to the site and view content secured by FarCry permissions.
This means we have had to modify the dmProfile type *within* farcry_core because it is so tightly coupled with dmUser in dmSec. If anybody can suggest a better way of doing this so we don't have to modify the farcry_core would be appreciated because we're getting caught occasionally when we apply updates to the core. Cheers, Craig -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Bowers Sent: Wednesday, 22 October 2003 10:21 AM To: FarCry Developers Subject: [farcry-dev] Re: PLP walkthrough, best practices, jai, public obj creation and doctypes Michael Sammut wrote: > Well stated! From my perspective, the only reason I see to move > something from custom to core is if the nature of the code will be > intrinsic to the application as a whole. In the case of doing ecom > where the number of routines to process orders is "core" to the > application, I felt that saving the type to the core (BTW this code > set is on another server solely for building ecom) rather than custom > would be a good choice. Since the code is only a type, any upgrade > tot he core code will have no affect. > > If you feel that these types (around 25) should be strictly custom, I > value your opinion and perspective. Well we would take the view that *all* additional types should be custom types, ie. in the farcry_project directory for your app. For instance when we work on a project and version all the code it's incredibly important that we don't mix the code bases -- because different teams maybe working on both code bases. From a "customers" perspective that matters less. I think there must be something not-right in the way we've been communicating the concept of a custom-type. These are really the exact same as any other type, ie. they extend the farcry_core abstract class types.cfc, they access display handlers from the ../webskin/ directory and so on. The only difference is the storage location. And we've worked hard to architect things such that the custom types can happily sit in the farcry_project structure, completely separate from farcry_core. To be clear, architecturally, FarCry CMS was designed so that it could be modified and extended -- customised -- for each and every application, while sharing a *common* set of code libraries: farcry_core and fourq. The current framework allows for the following extensions: - custom administration interfaces - custom types - custom rules - custom tags - custom components - includedObjects - custom configs - custom dmCron scheduled tasks - custom display templates for all core objects - and more (all store in the relevant farcry_project) There should be absolutely no reason to modify farcry_core in anyway. If you find yourself doing that then we've either not communicated things correctly or there is something wrong in the architecture that needs addressing. Ultimately we'd like to have a library of "custom bits", that people can use to share their modifications. Adding a customisation should be as simple as popping the relevant templates into the relevant directory in the farcry_project code base. Anyway.. I've rambled on a bit. I hope that makes our objectives a little clearer :) -- geoff http://www.daemon.com.au/ --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
