Final point (re: script)..... I'd probably be one of those who prefer it - so I actually disagree with this request. Despite the shortcomings of CFSCRIPT, I find it easier to read. Of course, there are always exceptions where using tag-based coding is not optional - but for the rest of it, I still think using CFSCRIPT makes sense.
Shame that MM can't see any sense in tidying up a few syntactical loose ends (e.g. boolean operators). Regards, Gary Menzel On Mon, 14 Mar 2005 09:34:22 -0700, Rob Brooks-Bilson <[EMAIL PROTECTED]> wrote: > Geoff Bowers wrote: > > > > Folks, > > > > We're building our plans for the next milestone release of FarCry. This > > should be considered a work in progress and has not been finalised. I > > put this out to the community to really get some feedback on what people > > are eager to see and spark some discussion about the priorities we need > > to give to various areas of the code base. > > > > ************************************** > > * FarCry 2.4 is codenamed "Glamour" * > > ************************************** > > > > --/ Mission Statement /-- > > *Glamour* is all about the users. We must overhaul the UI of FarCry > > administration, and surface as much hidden functionality as possible. > > FarCry will become an elegant and beautiful thing to behold. > > > > --/ Reality Check /-- > > Although the FarCry administration interfaces are generally good and > > maintain a particular look and feel across all interfaces they are not > > ideal. There are many features that exist under the hood that are > > really only acessible to power users of the system -- and by that we > > mean developers who have an intimate understanding of the core. This > > will be changed. > > > > FarCry provides for sophisticated content management scenarios. We need > > to provide more intuitive interfaces for non-technical authors to get > > the most from the system. On the flip-side we need to somehow > > accommodate the least experienced users in our community and more easily > > allow admins to "dumb down" the admin interfaces. > > > > A rough list of desired outcomes includes: > > > > ** Overhaul of UI > > - work to a single set of CSS styles to allow for complete admin > > customisations > > - standardise all FORMs and wizards to admin styles > > - introduce Crystal SVG icon library throughout > > - Standardise on cross browser support for Safari, Firefox, Mozilla and IE > > - improve rich text editor integration for popular editors (refactor > > editor integration to make this easier for developers wanting to plugin > > in new editors) > > - improve media management of files and images for all content types > > (including custom types) > > > > ** Functional Changes to Core > > - add basic image manipulations (eg. auto thumb generation) > > - add file archiving > > - add generic interface for container reflection > > - add generic admin interfaces for ALL core content types (including > > tree content types) > > - replace the SECURITY interfaces completely (include profile > > management, and multi directory management options) > > - statistics aggregation and purging options > > - updates to FriendlyURL servlet > > > > ** Architecture Changes > > - integrate FourQ package directly into the Core code base > > - extend FourQ array properties to include data beyond object references > > - improve error handling options (including URL 404 and developer > > debugging) > > > > ** Installation > > - new installer to make life easier for new members to the community > > - more comprehensive sample site templates to show off more > > functionality and give better guidance > > - out of the box support for context roots > > - J2EE deployment options for CF7 installations > > > > --/ Rough TimeLines /-- > > We are aiming for a beta release of the *Glamour* code base for end of > > May 2005, with a final production release end of June 2005. This is > > ambitious and we're going to need help from the community to achieve this. > > > > --/ System Requirements /-- > > We've decided to hold off any CF7 specific enhancements in core for the > > *Glamour* release. However, CF7 features and functionality can certainly > > be leveraged in FarCry projects and extensions. > > > > It's envisaged that *Glamour* will be the final milestone release for > > CFMX 6.1. Future releases will be targetted to take specific advantage > > of the CF7 platform in the farcry_core code base. The next milestone > > version after 2.4 will be version 3.0 -- the change in primary version > > number denoting a backward compatability issue associated with the > > requirement for CF7. > > > > Note: Complete compatability with CF7 was a fundamental requirement of > > the 2.3 milestone release. Any incompatabilities are considered bugs > > and will be patched to the 2.3 maintenance branch in addition to the > > HEAD trunk. > > > > Best regards, > > > > -- geoff > > http://www.daemon.com.au/ > > > > > > > > > Geoff, > > It sounds like a lot of great enhancements are planned for 2.4. > Congrats to you and the entire FarCry community - especially for such an > ambitious timeline! > > I have a couple of suggestions I would like to get make for a future > FarCry release. Perhaps some of them could be worked into 2.4, while I > suspect others would have to wait for 3.0+. Most of them are > code/architecture related as opposed to functional in nature, and > reflect my opinion only. I appreciate all of the thought and effort > that has gone into FarCry thus far and only want to make suggestions to > strengthen it as a platform. > > + Review the code to ensure that all CFC methods are fully tagged. By > this, I mean that all relevant attributes such as Access, returnType, > Hint, etc. are used consistently. I would be willing to help out with > this effort. > > + I would love to see more encapsulation in the FarCry CFCs. By this I > mean refactoring the code such that application and session scoped > variables aren't referenced directly inside of CFC methods, but are > instead passed in as arguments. This will take some doing, and probably > won't make sense until there are unit tests developed for FarCry. > > + Drop the mixing of tags and cfscript within CFCs. We've coded > several of our applications over the last year or so this way too, and > are now finding that as we try to build tools to help us automate > certain tasks (in CFEclipse), having to parse CFCs that have both tags > and cfscript blocks in the same methods is a bit problematic. While > some of our developers prefer the cfscript style syntax, the reality is > that Macromedia has basically said that there won't be further > enhancements to cfscript (in any meaningful way). Because of that, I > think it makes sense to try to keep the coding style in FarCry CFCs > consistent and make use of tags over cfscript. > > -Rob > > --- > You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > Aussie Macromedia Developers: http://lists.daemon.com.au/ > --- You are currently subscribed to farcry-dev as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
