Crystal Clear, thanks for the time to review. I guess I was hung up on the word custom. I will pull those types out of core and continue the build on the ecom module. Thanks!
-- Regards, Michael J. Sammut ____________________________________________________________________ F O U R E Y E S P R O D U C T I O N S think | plan | create :: web site design & development :: NYC E. [EMAIL PROTECTED] | T: 718.254.9557 ext. 101 | F: 718.254.0399 W. http://www.foureyes.com "Geoff Bowers" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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]
