Nathan Mische wrote:
Extending the "core" is pretty damn easy (whether you mean extending core objects or creating new ones, it's the same concept anyways).
Basically, I'm not sure what work could be done on the core to make it easier to use.

I agree, the COAPI is very easy to use and that is the direction I would
like to see the rest of the FarCry code base move towards. The
documentation says that FarCry has a few "rough-edges," it's these rough
edges I'd like to see polished up.

FarCry is actually a very mature product that has been in the market for many years. However, like many mature Enterprise solutions it's accumulated some detritus along the way as things have evolved. Although it would be ideal, it's often not practical to go back and rework earlier code -- if it works...


Custom tag calls in Core are often a legacy of some code being ported from pre-CFMX code, or CFMX 6.0 code (where the CFC's had some issues). Ultimately, we'd like to move to a completely component driven model -- incidentally in many instances you will find that custom tags can often be found calling CFC's and so you're seeing a migration of the coding style.

Also, we had libraries of custom tags to hide the complexity of building and calling CFCs in the early days. Although this is something I'd like to see eradicated from core, its certainly something that will be continued in farcry project code like the webskin.

For example, why is the COAPI called
via the fourq custom tag library at some points in the code? Why not
just call the fourq object directly, as is done in other parts of the
code? Why is the login functionality handled by a custom tag in the
navajo tag library? Why not the security library? Why a custom tag at
all? When I was initially digging into FarCry these are just a few of
the questions I had.

Specifically re FourQ. It was originally written as an independent library during the NEO alpha/beta. MM had something called "greystoke" and I was toying with ideas. One of my experiments was to basically port Spectra to use FourQ instead of its standard COAPI -- hence some of the familiarity in the naming. Maybe fourq should move into FarCry core??


Security? Security we wrote originally to replace Netegrity's SiteKiller product that posed as advanced security in CF5 and below. It was a custom tag library, ported to CFC's. Again another thing that needs a bit of spit and polish.

So I guess my question about the future of FarCry is, are the custom
tags here to stay, or is the entire code base moving to a component
based architecture? If there is an effort to move more of the code base
into components, and I hope there is, what can we do to ensure that
everyone is on the same page? There are differing opinions on how best
to leverage components, even how to code them, so which ones are we to
follow in core development?

Custom tags... to be used more and more in the webskin and areas non-programmers might be found. Always considered to be optional. Custom tags in core... we're working to gradually remove everything. And you'll see progressive and subtle improvements here each point release. By and large we are concentrating on making project work independent of core changes -- ideally you shouldn't need to understand anything in the core except for the CFC API.


These questions are not meant to be a troll... I'm a very big fan of
FarCry, I just want to see it keep getting bigger and better!

Keep the questions coming. I'm almost finished a draft Technical Whitepaper (keep getting distracted!).


-- 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]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to