Well that's just one bug I know about -- I'd also like to see them add some of the features that folks like Hal Helms are saying make them not as useful as they could be... I don't remember the specifics on the bug (I do know it's a known issue, so it should be in the known issued doc on the MM site), but there are problems with setting persistent scope vars from within a CFC. It was being talked about on either [EMAIL PROTECTED] or the cfdj list a little earlier today.
In general I'm waiting for them to mature a bit -- I've been alternatively very impressed and very unhappy with MM's implementation of CF MX. I was really impressed that they managed to get it working on a completely different platform (J2EE) so damn fast. But I think they made some poor decisions about that implementation, like the fact that it generates a java class for each cfm template (which ultimately is probably a hold-over from the pcode versions). I suspect that BlueDragon doesn't do that but rather uses the internal mechanisms of cfimport (or something like it) to use a series of classes which emulate the original functionality of the CFML language. I remember prior to the release of MX after the J2EE architecture was announced, stating on the CF newsgroup that I was really hoping they would go that route, rather than having it generate brand new Java code from CFML (translating one language to another language) which I predicted would be hideously slow, and I was right. This is what causes the first-run problem. To give you some idea of exactly what I'm talking about. I had an installer for my CMS which used a SQL Server backup which turned out to be a bottleneck that caused installation problems, so I decided to go with a much better method (in spite of the fact that it required more coding on my part) and build all the tables, views, stored procedures, etc. from a series of cf scripts instead. So I put them all in a directory and I used cfdirectory to get a list of them and include them one after another. Which worked great on CF5, chewing through 30 or so per second until it finished with all 2000 + files (it's up to about 2500 now). The whole thing took a minute or 2 on CF5. But when I ran the same code on CFMX each file in the directory took a full second to execute. Since this is an installer, by definition, the files are useless after the first run, so I can't just say "it'll be fine after the templates are initialized", because it won't. And with 2000 files in the directory it would take roughly an hour to install the db on MX and I wasn't willing to settle for that. What I discovered was that it was significantly faster (slightly slower than the original method on CF5) to build a temp file by appending the content of each file to one _BIG_ cf template (3MB in a single template -- you can't really edit that kind of thing in CF Studio), and then execute and delete that temporary template. I don't really like the workaround, but it does work, and at least for now there's nothing better available. > What bugs are you referring to regarding persistent scoped > vars? Just Curious..... > Dan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of S. Isaac Dealey > Sent: Friday, February 28, 2003 10:22 PM > To: [EMAIL PROTECTED] > Subject: RE: Fusebox 3 question on fbx_fusebox_XXXX > I'm neither averse nor married to it. What I've discovered > recently is that > I seem to work faster ( entirely for myself ) when I use > my own methods -- > that is, fusebox only slows me down. I'm by no means > saying FB is slow (or > even bloated) whether I think it or not -- I've just > noticed that it's > faster and easier for me achieve the same results using my > own methods. What > I notice in FB is that I'm continually editing fbx_switch > files and > fbx_circuits files which equivalents in my own coding > methods require no > maintenance -- and I think that's probably where a lot of > the time is saved. > As to MX being "object based" I'm waiting for them to fix > some of the known > bugs in CFC's before I dive right into them. I'm just not > willing to spend a > lot of time developing workarounds for things like > persistent variables when > I know MM is going to fix those things soon -- just like > back in CF 4 when > there was a known bug in request variables such that > custom tags didn't see > them and so they didn't serve the purpose for which they > were created. ;P > IIRC they fixed that right away in the 4.01 upgrade. >> I agree....Down with Fuse Blah....To bloated....Look into >> MVC since CFMX is a Object Based language now.... >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> Behalf Of Marlon Moyer >> Sent: Friday, February 28, 2003 7:07 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Fusebox 3 question on fbx_fusebox_XXXX >> I've been fuseboxing for a while now and lately I've been >> trying to wean >> myself from it. I'm not real thrilled about the nested >> layouts and >> such, but I can't seem to find a way to duplicate the >> ease >> of navigation >> that it presents. I've been toying around with ideas >> about how to >> emulate the abstraction of the directory trees. Have you >> found a >> reliable method? >> Thanks. >> Marlon >> S. Isaac Dealey wrote: >>> >>>I don't use FB for my own development -- I use the >>>attributes trick so that >>>I can call certain base templates as custom tags if it'll >>>help, and I use >> an >>>equivalent of the fuseaction variable and the fbx_switch >>>that's more >> dynamic >>>(actually just dynamic includes). Speaking of which -- >>>apparently a few >>>people have run into problems with migrating FB2/3 >>>applications to CF MX as >>>a result of the 64k method limitation of the underlying >>>Java engine. >>>Apparently when MX generates a java class for a new >>>template, it puts >>>everything in a single method, so if you've got a >>>switch-case in the >>>template it'll examine all those includes and include the >>>contents of all >>>those included files in the generated Java code. So even >>>if your switch >> case >>>statement only has 2 cases like <cfswitch >>>expression="#fusebox.fuseaction#"><cfcase >>>value="a"><cfinclude >>>template="a.cfm"></cfcase><cfcase value="b"><cfinclude >>>template="b"></cfcase></cfswitch> you could still exceed >>>the 64k limit if >>>the CF Server generates more than 64k of combined Java >>>code from a.cfm and >>>b.cfm (i.e. between them, not per file). >>> >>> >>> >>> >> ----------------------------------------------- >> To post, send email to [EMAIL PROTECTED] >> To unsubscribe: >> Send UNSUBSCRIBE to [EMAIL PROTECTED] >> To subscribe / unsubscribe: http://www.dfwcfug.org >> ----------------------------------------------- >> To post, send email to [EMAIL PROTECTED] >> To unsubscribe: >> Send UNSUBSCRIBE to [EMAIL PROTECTED] >> To subscribe / unsubscribe: http://www.dfwcfug.org > s. isaac dealey 954-776-0046 > new epoch http://www.turnkey.to > lead architect, tapestry cms http://products.turnkey.to > tapestry api is opensource http://www.turnkey.to/tapi > certified advanced coldfusion 5 developer > http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org > ----------------------------------------------- > To post, send email to [EMAIL PROTECTED] > To unsubscribe: > Send UNSUBSCRIBE to [EMAIL PROTECTED] > To subscribe / unsubscribe: http://www.dfwcfug.org s. isaac dealey 954-776-0046 new epoch http://www.turnkey.to lead architect, tapestry cms http://products.turnkey.to tapestry api is opensource http://www.turnkey.to/tapi certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
