On Thu, Oct 1, 2009 at 12:19 AM, ameen.rabea <ameen.rabea@gmail.com> wrote:
> Strange thing is going on fusebox.org website after appearing of FuseNG.
> I was looking for Fusebox 551 Docs, yesterday links was redirect to FuseNG Docs, but Today It goes to
> http://wiki.fusebox.org/index.php?action=Login&module=Users&login_module=Home&login_action=index

Just to clarify for everyone:

TeraTech owns the "Fusebox" name and the fusebox.org site/domain. The
Fusebox code is open source under the Apache license. TeraTech were
asked to relinquish the name and the domain because they have not been
supportive / helpful to the Fusebox project for a long time (most of
Team Fusebox quit ages ago over this). TeraTech refused.

Adam - with the support of several key Team Fusebox people - forked
the source code under the new name FuseNG (Next Generation). Adam owns
and runs the fuseng.info site.

I own the fuseboxframework.org/.net/.com domains (dating back to when
Fusebox was nearly forked *before* TeraTech took ownership) and those
domains were pointed at the old Trac/SVN system. Adam actually
migrated Fusebox to the new JIRA/Confluence/SVN system quite a while
ago and I updated the DNS accordingly.

The fusebox.org site had many references to fuseboxframework.org
because that's how it linked to the documentation, the bug tracker and
the SVN repository.

After the fork (Fusebox 5.5.1 -> FuseNG), that left fusebox.org out of
our control (still under TeraTech) but fuseboxframework.org still
pointing to the new wiki/repository, just as it had before the fork.
It looks like TeraTech are finally updating the old Fusebox site to
point to some new sites they are setting up.

It is unknown whether TeraTech will attempt to evolve Fusebox - they
contributed nothing in terms of evolution after an initial bit of
interest and management support (essentially the big survey that led
to the decision to provide a no-XML option in Fusebox 5.5). I resigned
as lead developer partly because of TeraTech's lack of input and
support and Team Fusebox effectively disbanded. The main benefit to
TeraTech is to justify their Fusebox training business (and everyone I
know who's taken their course says it sucks).

FuseNG offers a dynamic, community-driven way for the codebase to
continue to evolve under Adam's leadership.

This mailing list will continue to support folks using Fusebox 5.x and
probably FuseNG as well since it is just an evolution of Fusebox 5.x
and, certainly for some while to come, will be backward compatible.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Thanks Barney, that's great! :)

I ended up creating it manually in OpenOffice before, which was slow
and frustrating.

This utility will be a huge help in future.

is there any document which describes the changes from fusebox 4 (which is what
I used in my last project) to fusebox 5?

also, what happened to the scaffolding wizard?

-michael

On Tue, Nov 17, 2009 at 9:14 PM, Jason Daiger
<jason@...> wrote:
> On a side note, the issue you are describing is one I'm very well aware.  We
sound like we are in very similar boats as far as our applications go. The
memory footprint is one of those items we have been struggling w/ for a few
years now. I discussed the memory footprint w/ both Adam and Sean a long time
ago and after input from both and digging into the code some, it's definitely
not an easy problem to solve.

I have a few ideas about this but we should start a new thread for
discussing the memory footprint.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Hey Jason,

I'm game to try. I was able to come up with a solution for the PHP port
so I'm pretty sure two or three brains working on it can do something
similarly workable in CF. What I did was make two serialized files, one
for when fusebox.load or fusebox.parse was true, and one for when the
app was in production mode, and the parsed file existed. For production
the only things in the serialized application.fusebox structure were the
things that you could touch through myFusebox. So that meant fusebox and
plugin parameters, circuit settings such as permissions, path and
access, fuseaction settings and lexicon attributes. Anything else was
removed from the 'production' structure before serializing and writing
it to disk. Whenever I needed the whole structure I just read it into
memory for the rest of the request.

Of course that was using the fact that a persistent application 'scope'
doesn't actually exist in PHP, but I'm certain there's a way to do
something similar in the CF version.

Mike

Jason Daiger wrote:
>
>
> Mike,
> On a side note, the issue you are describing is one I'm very well
> aware.  We sound like we are in very similar boats as far as our
> applications go. The memory footprint is one of those items we have
> been struggling w/ for a few years now. I discussed the memory
> footprint w/ both Adam and Sean a long time ago and after input from
> both and digging into the code some, it's definitely not an easy
> problem to solve.  Hence why we just upgraded to a 64-bit Windows
> server where so we  can have 3 CF instances w/ 3GB of RAM allocated to
> each instance in order to run over 20 sites per instance.  Ultimately
> that's the easiest (though certainly not the cheapest) solution to the
> memory footprint at present moment.
>
> -Jason
>
>
> Mike Ritchie wrote:
>
>> Truly the only thing I'd like to see in future Fusebox development is to
>> find a way to drastically reduce its memory footprint. I've been working
>> on a browser-based website builder called SiteGIDGET
>> (http://www.sitegidget.com/online-builder-affiliate-demo.html in
>> Firefox), and it works amazingly well. The problem is scale though, as
>> more than 20 or so websites loaded into application scope really tax the
>> server. If there was a way to reduce the production-mode footprint so
>> that the application scope only had to hold those elements that can be
>> interacted with by the developer (fusebox and plugin parameters,
>> circuit/fuseaction permissions, etc), then it really would be "complete"
>> as far as I can tell. I guess I could just switch to the "noXML"
>> variant, but I'm two and a half years into the development of this app
>> now, and I don't relish the idea of rewriting it now.
>>
>>
> --
> *Jason Daiger*, /Dir of Technology Services/*
> Attendee Interactive, LLC*
> *URL:* http://www.attendeeinteractive.com
> <http://www.attendeeinteractive.com>
> *EML:* jason@...
>
<mailbox:///C%7C/Documents%20and%20Settings/Jason/Application%20Data/Postbox/Pro\
files/a92rad1s.default/Mail/Local%20Folders/Sent?number=60043227>
> *PH:* 410.480.8148 x 301
>
> Be sure to visit us at IAEE EXPO! EXPO! on 12/9 in Atlanta, GA!  We
> are in booth #1422!
>
> /Please consider your environmental responsibility before printing
> this e-mail/
>
>

Truly the only thing I'd like to see in future Fusebox development is to find a way to drastically reduce its memory footprint. I've been working on a browser-based website builder called SiteGIDGET (http://www.sitegidget.com/online-builder-affiliate-demo.html in Firefox), and it works amazingly well. The problem is scale though, as more than 20 or so websites loaded into application scope really tax the server. If there was a way to reduce the production-mode footprint so that the application scope only had to hold those elements that can be interacted with by the developer (fusebox and plugin parameters, circuit/fuseaction permissions, etc), then it really would be "complete" as far as I can tell. I guess I could just switch to the "noXML" variant, but I'm two and a half years into the development of this app now, and I don't relish the idea of rewriting it now.

Personally, in a way I'm glad because that means that I can pretend that
FuseNG (the event not the framework) never happened. To be honest the
drama it introduced was almost as much as the complaints of Teratech's
lack of stewardship towards Fusebox.

Truly the only thing I'd like to see in future Fusebox development is to
find a way to drastically reduce its memory footprint. I've been working
on a browser-based website builder called SiteGIDGET
(http://www.sitegidget.com/online-builder-affiliate-demo.html in
Firefox), and it works amazingly well. The problem is scale though, as
more than 20 or so websites loaded into application scope really tax the
server. If there was a way to reduce the production-mode footprint so
that the application scope only had to hold those elements that can be
interacted with by the developer (fusebox and plugin parameters,
circuit/fuseaction permissions, etc), then it really would be "complete"
as far as I can tell. I guess I could just switch to the "noXML"
variant, but I'm two and a half years into the development of this app
now, and I don't relish the idea of rewriting it now.

Anyways, I don't think Fusebox is "dead", it's just not the squeaky
wheel anymore.

Mike
www.fusebuilder.net

Sean Corfield wrote:
>
> I've seen a few tweets about Fusebox / FuseNG recently and most of
> them trace down to Adam Haskell's blog post about the "death" of
> FuseNG:
>
> http://cfrant.blogspot.com/2009/11/fuseng-update.html
> <http://cfrant.blogspot.com/2009/11/fuseng-update.html>
>
> Peter Farrell picked this up and ran with it:
>
> http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d
> <http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d>
>
> And of course the father of Fusebox, Hal Helms, just announced his
> "departure" to Ruby on Rails.
>
> The bottom line is that no one is working on the Fusebox/FuseNG
> framework and that has been the situation for quite a long time (from
> shortly after I handed Fusebox over to Adam).
>
> Activity on these Fusebox mailing lists has definitely dropped off
> over the last year. If both Fusebox and FuseNG are dead, how do people
> feel about that? Are Fuseboxers moving to other frameworks or still
> plugging along with a (possibly customized) earlier version of
> Fusebox?
>
> I'd like to hear everyone's thoughts on this...
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ <http://getrailo.com/>
> An Architect's View -- http://corfield.org/ <http://corfield.org/>
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.704 / Virus Database: 270.14.61/2498 - Release Date: 11/11/09
23:38:00
>
>

I remember at CFUnited a few years ago (maybe 2006?) a roundtable
about frameworks in general, and Fusebox in particular.  The general
consensus was that Fusebox is complete.  There isn't more to add.  So
I'm not sure the "abandoning" of core development is necessarily a
problem, because I'm not sure what core development there is to do.

I've used Fusebox for a lot of years, from FB2 up through FB 5.5,
though of late I'm custom Fusebox-like framework (applying FB4/5
features to the FB3 syntax) for most things.  I still support and
actively work on a number of FB5 and 5.5 apps, though, and they're not
going to be ported.  I think there are a lot of people in the same
situation, where it's a solid workhorse.  You don't need to think
about how to get stuff done (or eve if it's possible), you just do it,
get your check, and move on to the next project.

Calling Fusebox dead is inaccurate.  It's just not being actively
developed.  As you said, Sean, this isn't a revelation; it's been
pretty stagnant for a long time.  If it needs new stuff, people will
step up, but right now, I don't see any compelling additions.

And as both Peter Farrell and Matt Woodward (both of whom are Mach-II
leads) pointed out, we can fight over frameworks all day, but it's
kind of irrelevant.  A framework is a tool, and like any tool, it can
be replaced with no great effect on the end result.  It's those end
results (the applications) that matter, not the internal bits used to
construct them.

cheers,
barneyb

On Tue, Nov 17, 2009 at 6:14 PM, Sean Corfield <seancorfield@...> wrote:
> I've seen a few tweets about Fusebox / FuseNG recently and most of
> them trace down to Adam Haskell's blog post about the "death" of
> FuseNG:
>
> http://cfrant.blogspot.com/2009/11/fuseng-update.html
>
> Peter Farrell picked this up and ran with it:
>
> http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d
>
> And of course the father of Fusebox, Hal Helms, just announced his
> "departure" to Ruby on Rails.
>
> The bottom line is that no one is working on the Fusebox/FuseNG
> framework and that has been the situation for quite a long time (from
> shortly after I handed Fusebox over to Adam).
>
> Activity on these Fusebox mailing lists has definitely dropped off
> over the last year. If both Fusebox and FuseNG are dead, how do people
> feel about that? Are Fuseboxers moving to other frameworks or still
> plugging along with a (possibly customized) earlier version of
> Fusebox?
>
> I'd like to hear everyone's thoughts on this...



--
Barney Boisvert
bboisvert@...
http://www.barneyb.com/

Peter, I don't know if you ever found something to do this for you,
but I whipped up a little utility that does it:

http://www.barneyb.com/barneyblog/2009/11/17/fusebox-xml-flowchart-generator/

It's really primitive, and I've not tested it extensively, but it
rendered stuff correctly for several decent size apps we run at work.

cheers,
barneyb

On Tue, Nov 10, 2009 at 8:46 AM, Peter Boughton <boughtonp@...> wrote:
>
>
> Thanks Mark, I've got it now.
> Unfortunately it doesn't appear to do the reverse-engineering that I was
hoping for. Oh well.
>
> Eitherway, I agree it would be good to have it hosted on the FuseNG site.
>
>


--
Barney Boisvert
bboisvert@...
http://www.barneyb.com/

 

I've seen a few tweets about Fusebox / FuseNG recently and most of
them trace down to Adam Haskell's blog post about the "death" of
FuseNG:

http://cfrant.blogspot.com/2009/11/fuseng-update.html

Peter Farrell picked this up and ran with it:

http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d

And of course the father of Fusebox, Hal Helms, just announced his
"departure" to Ruby on Rails.

The bottom line is that no one is working on the Fusebox/FuseNG
framework and that has been the situation for quite a long time (from
shortly after I handed Fusebox over to Adam).

Activity on these Fusebox mailing lists has definitely dropped off
over the last year. If both Fusebox and FuseNG are dead, how do people
feel about that? Are Fuseboxers moving to other frameworks or still
plugging along with a (possibly customized) earlier version of
Fusebox?

I'd like to hear everyone's thoughts on this...
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

I'm a long-time Fuseboxer and am currenty using the 5.5 core.
I was asked by someone at the recent CFObjective, (here in Melbourne,
Australia), what things I'd like to see added to the core.  My reply was,
"nothing really, I think it's complete".  What I did think about was the state
of the documentation (especially as regards an 'on-ramp' for people considering
it) and the absence of a really dynamic add-on/plug-in/FB apps scene.  This is
not a complaint, as clearly I haven't stepped up to that particular plate
myself, just an observation that may account for the perceived lack of interest.
Perhaps in some ways FB's success is part of the problem, in that there seem to
be heaps of satisfied users like me who beaver away in relative isolation (I've
presented FB to the local CFUG a couple of times), rarely post, for whom FB
fills a need.

My position now is that I can easily continue with my current apps on FB5.5 core
for the forseeable future, so while sad if this is really end-of-life, not the
end of the world.  I'm also really open to whatever comes next (eg FW/1??).

On the other hand, if there are enough of us that's like to see FB go forward,
what do people suggest, what do we want?

Cheers



Peter Robertson


--- In fusebox5@yahoogroups.com, Sean Corfield <seancorfield@...> wrote:
>
> I've seen a few tweets about Fusebox / FuseNG recently and most of
> them trace down to Adam Haskell's blog post about the "death" of
> FuseNG:
>
> http://cfrant.blogspot.com/2009/11/fuseng-update.html
>
> Peter Farrell picked this up and ran with it:
>
> http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d
>
> And of course the father of Fusebox, Hal Helms, just announced his
> "departure" to Ruby on Rails.
>
> The bottom line is that no one is working on the Fusebox/FuseNG
> framework and that has been the situation for quite a long time (from
> shortly after I handed Fusebox over to Adam).
>
> Activity on these Fusebox mailing lists has definitely dropped off
> over the last year. If both Fusebox and FuseNG are dead, how do people
> feel about that? Are Fuseboxers moving to other frameworks or still
> plugging along with a (possibly customized) earlier version of
> Fusebox?
>
> I'd like to hear everyone's thoughts on this...
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>

I've seen a few tweets about Fusebox / FuseNG recently and most of
them trace down to Adam Haskell's blog post about the "death" of
FuseNG:

http://cfrant.blogspot.com/2009/11/fuseng-update.html

Peter Farrell picked this up and ran with it:

http://maepub.com/fuseng-and-therefore-fusebox-by-default-are-d

And of course the father of Fusebox, Hal Helms, just announced his
"departure" to Ruby on Rails.

The bottom line is that no one is working on the Fusebox/FuseNG
framework and that has been the situation for quite a long time (from
shortly after I handed Fusebox over to Adam).

Activity on these Fusebox mailing lists has definitely dropped off
over the last year. If both Fusebox and FuseNG are dead, how do people
feel about that? Are Fuseboxers moving to other frameworks or still
plugging along with a (possibly customized) earlier version of
Fusebox?

I'd like to hear everyone's thoughts on this...
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Hey Bob,

I made a change to my own local copy of the Fusebox core so that I could
include my core files from a CF Mapping instead of a relative path from
my index.cfm. It basically looks at the first character of
fusebox_application_path and if it's a "/" it takes the fusebox path
as-is for application.fusebox.webroottocorepath, instead of trying to
calculate it. I'm not sure if this is related to your situation or not,
but making this change to the core allowed me to have my webroot on my
C: drive, with my approot on my F: drive so that I could develop my
application in either Ubuntu or Windows and use the same code base. It's
working a treat for me so far. I haven't submitted it anywhere because I
can't vouch for the quality or the robustness of the code I introduced
into the core, but if you're interested I can send it to you.

Mike
http://www.fusebuilder.net


bobsilverberg wrote:
>
> I found a bug in FuseboxApplication.cfc, in the locateCfc() function.
> Due to my lack of familiarity with the internals of the framework I'm
> not sure how to address it.
>
> The problem is occurring because I have a symbolic link in my server's
> web root which points to my code which is elsewhere. locateCfc() uses
> ExpandPath("/") to get the location of the webroot, which in my case
> is /Library/WebServer/Documents/muraCMSPlain/. The filename being
> passed into locateCfc() is the actual location of the cfc, which is
>
/Users/robertsilverberg/Documents/workspace/muraCMSPlain/plugins/meldforums_16/c\
ontroller/cApp.cfc.
>
>
> The problem is that the logic that checks to see if the application
> resides in the webroot is determining that my app *does not* live in
> the webroot because of the discrepancy in the paths. But the app
> *does* live in the webroot. Because the framework thinks it does not
> live in the webroot, it assumes that I have a mapping to the folder
> that contains the controller, but I do not have such a mapping, so
> when the parsed file is written the CreateObject call points to an
> invalid location for the component.
>
> As I said above, I'm not sure how to best get around this issue. I
> don't know if there's another way to determine the webroot that would
> yield /Users/robertsilverberg/Documents/workspace/muraCMSPlain/ rather
> than /Library/WebServer/Documents/muraCMSPlain/, or whether this means
> that there is a need for a configuration option to tell the framework
> "I don't care what you think - my app is in the webroot".
>
> Does anyone have any ideas on how to resolve this issue?
>
> Thanks,
> Bob
>
>

I found a bug in FuseboxApplication.cfc, in the locateCfc() function. Due to my
lack of familiarity with the internals of the framework I'm not sure how to
address it.

The problem is occurring because I have a symbolic link in my server's web root
which points to my code which is elsewhere. locateCfc() uses ExpandPath("/") to
get the location of the webroot, which in my case is
/Library/WebServer/Documents/muraCMSPlain/. The filename being passed into
locateCfc() is the actual location of the cfc, which is
/Users/robertsilverberg/Documents/workspace/muraCMSPlain/plugins/meldforums_16/c\
ontroller/cApp.cfc.

The problem is that the logic that checks to see if the application resides in
the webroot is determining that my app *does not* live in the webroot because of
the discrepancy in the paths. But the app *does* live in the webroot. Because
the framework thinks it does not live in the webroot, it assumes that I have a
mapping to the folder that contains the controller, but I do not have such a
mapping, so when the parsed file is written the CreateObject call points to an
invalid location for the component.

As I said above, I'm not sure how to best get around this issue. I don't know if
there's another way to determine the webroot that would yield
/Users/robertsilverberg/Documents/workspace/muraCMSPlain/ rather than
/Library/WebServer/Documents/muraCMSPlain/, or whether this means that there is
a need for a configuration option to tell the framework "I don't care what you
think - my app is in the webroot".

Does anyone have any ideas on how to resolve this issue?

Thanks,
Bob

Possibly Adalon does/did this, but I can't seem to access adalon.net
nor Google's cache to find out.

Is anyone able to confirm if it can do this, and if so send me a copy?
(I think v3.6 was released as abandonware?)

Hi all,

Does anyone happen to know of any tool that automatically converts a
circuit.xml into a flowchart, with IFs being decision points, DOs
linking parts together and include/set/etc being action blocks?

(I am specifically looking for flowchart style, *not* the tree view
that Frameworks Explorer provides)

Thanks,

Peter

Hi all,

One of my applications seems to randomly re-initialize itself and throw an
error while doing so. It seems that every now and then FB executes the
appinit global fuseaction although the app is constantly being used.

During the appinit phase I initialize the ColdSpring service factory and
then retrieve three service cfcs from the factory and store them in
application scope. While retrieving the last service, CF sometimes throws
an error "Element SERVICEFACTORY is undefined in a CFML structure
referenced as part of an expression." This never occurs during regular
initialization, but, within seconds of another page request to the same
application.

The error always occurs on the same line of the parsed file that Fusebox
generates. The same service factory that bombs on this line is used on the
lines before without throwing an error. The statement in question is
surrounded by a conditional statement that checks whether FB is loaded or
not (apparently it isn't at time of error) and an exclusive lock.

At first I thought that someone had used fusebox.loadclean=true, so I
changed the fusebox.password, but, to no avail.

My questions here are: are there conditions when FB suddenly needs to
re-initialize without being told to do so? And why should the service
factory be non-existing, while is has existed on the line before?

The setup: FB 5.5/ColdSpring/CF 8.01 Enterprise on Windows

Below you'll find some code (hints about errors included for readability).

Thank you

Chris

fusebox.xml.cfm:
<globalfuseactions>
    <appinit>
       <fuseaction action="m.initialize"/>
    </appinit>
</globalfuseactions>

circuit.xml.cfm of circuit "m" :
<circuit access="internal" xmlns:cs="path_to_coldspring">
    <fuseaction name="initialize">
       <set name="defaultProperties" value="#StructNew()#" />
       <set name="defaultProperties.dsn" value="#request.dsn#" />

       <cs:initialize coldspringfactory="servicefactory"
defaultproperties="#defaultProperties#">
          <cs:bean beanDefinitionFile="#ExpandPath('coldspring.xml')#" />
       </cs:initialize>

       <cs:get bean="SearchParamService"
returnvariable="application.SearchParamService"
coldspringfactory="serviceFactory"/>

       <cs:get bean="ReferenceService"
returnvariable="application.ReferenceService"
coldspringfactory="serviceFactory"/>

       <!-- this sometimes errors out -->
       <cs:get bean="LanguageService"
returnvariable="application.LanguageService"
coldspringfactory="serviceFactory"/>

       <set name="application.qLanguages"
value="#application.LanguageService.getLanguages()#" />
       <set name="application.sizes"
value="#application.searchParamService.getPictureSizes()#" />
       <set name="application.Languages"
value="#application.searchParamService.getLanguagesAsStruct()#" />
    </fuseaction>
</circuit>

from the parsed file (empty lines inserted for readability):
<cfset application.SearchParamService =
myFusebox.getApplication().getApplicationData().serviceFactory.getBean(beanN
ame="SearchParamService")/>

<cfset application.ReferenceService =
myFusebox.getApplication().getApplicationData().serviceFactory.getBean(beanN
ame="ReferenceService")/>

<!-- this sometimes errors out -->
<cfset application.LanguageService =
myFusebox.getApplication().getApplicationData().serviceFactory.getBean(beanN
ame="LanguageService")/>