>> Why would you want to? because to integrate the functionality we want to bolt on to the existing system would mean (pretty much) a complete rewrite of the whole thing, whereas adding an additionl aspect would be much easier and cleaner.
>> (I'm not convinced that AOP is the "big deal" some folks make it out to be) yeah, I understand your point, but as a specialist tool/technique it does have it's place. I first thought AOP was only suited for a "fix it later" approach (which is - sort of - the problem we have now) >> Can you explain what you're really trying to do and maybe someone will come up with >> a neat solution in plain ol' CF? OK. the system: - existing client/server app being rebuilt for the web - 150+ installed sites using the product as mission critical for their intranets - legacy database and structure (no schema changes without major headache) - parallel running of client/server and web versions until all modules are finished then full cut over. - system built as: persist(data access) / service(model interface) / global presenter(controller) / UI (taglib) - many cases where the "edit screen save" can affect many tables (commonly 3, some up to 5 tables in one go) - db table unique identifiers can involve up to 4 fields (no autonumbers/UUID's on this baby!) - existing widely-used CF ancillery products using the same database that has no existing data integrety controls we've finally decided how data collision (eg on updates, deletes) should be handled. NOT ACCEPTABLE: re-read before update: - retrofitting the additional data structures into the code to carry the old data back to the persist for comparison - notification of data conflict happens after save but does not stop the editing process NOT ACCEPTABLE: timestamp/last-saved-by/hashing-the-record ( + comparisons) - 100+ tables in schema, all needing the additional fields to the 150+ sites - still doesn't prevent editing (ie: only notification after the event) PROPOSED: mimic row locking by code using a "row lock" table to record what table + row, when ( 5min expiry typical ) and (more importantly) who. In addition to the standard "get data", there's a "get data for editing" that re-queries (for latest data) and enters an entry for the row lock table (NOTE: the tables are not "locked" as such, just controlled for access) �- only one additional table req'd (no changes to other tables) �- drop-dead simple notification of lock status (when, who) with additional management by admin to proritise/ break deadlocks. For our users, this is similar to how the existing client/server system works. PROBLEMS TO OVERCOME: �- the presenter does not know (nor should it) the underlying data structure (ie: it might control a particular screen but that might be populated by up to 5 tables)...this would be a logical place to control the locking since it could notify the users �- there are "data grid" screens (in Flash) that can edit hundreds of records in one session �- existing code base where retrofitting *any* solution to it would be a major PITA WHERE AOP could help: �- existing code + logic remains unchanged since the "lock aspect" pointcut would be triggered by persist and notify the presenter. - lock control is not "mixed in" to data retrieval and can be modified seperatly WHERE AOP will not work for us (as it turns out): - AspectJ is the only java-based system I've found and (my understanding) it needs the source (CF runtime) to integrate and compile with. we've got two other possibilities that we'll try soon (unless others have brill ideas) - create a data-model-aware companion to the presenter that controls the "locks" and notifies the presenter - roll our own CFQUERY (or mod it) with the additional messaging functionality (Spike opened a real pandoras box on this one...). It's times like this that I wish it was ASP.NET and we'd have easy access to MSMQ (... nah!...) any thoughts people? we're running out of ideas... thanx barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
