Loading ...
Sorry, an error occurred while loading the content.

Re: [fusebox5] PATCH: implicit in 5.5.1

Expand Messages
  • Barney Boisvert
    The optional-true functionality was officially supported in FB4. In fact, if I recall correctly, the first versions of FB4 didn t have true/false at all. If
    Message 1 of 25 , Jan 7, 2010
    • 0 Attachment
      The optional-true functionality was officially supported in FB4.  In fact, if I recall correctly, the first versions of FB4 didn't have true/false at all.  If you wanted an if/else construct, you used two ifs and negated the condition of the second one.  I don't have the FB4 code anywhere to look at, but perhaps someone else does?

      And it completely works in FB5 - no checks are made on the children of the 'if' verb.  Both 'true' and 'false' must be nested directly inside an 'if' verb, but they're optional.  In fact, there are all kinds of neat things you can do.  And the children aren't special in any way, all the verbs have a list of zero or more children, all of which are always processed.  The only way to prevent that is to do some child type checking in the verb implementation itself and raise an exception to prevent the body from execution.  So it's either all or error.

      fuseboxVerb.cfc does a start tag, all the tag's children (unless skipBody is set), and then the end tag, so there are no checks there for the children's types.   The if.cfm simply emits the open and close CFIF tags after doing a couple attribute checks.  true.cfm is a no-op and and false.cfm simply emits a CFELSE tag.  Subversion is rooted at http://svn.fusebox.org/framework/tags/fusebox500/ if you want to look directly.

      This lets you do it the "right" way (XML first line, parsed CFML second line):

      <if condition="..."><true><set value="yes" /></true><false><set value="no" /></false></if>
      <cfif ...><cfset "yes" /><cfelse><cfset "no" /></cfif>

      The direct-if way:

      <if condition="..."><set value="yes" /></if>
      <cfif ...><cfset "yes" /></cfif>

      The direct-if-else way:

      <if condition="..."><set value="yes" /><false><set value="no" /></false></if>
      <cfif ...><cfset "yes" /><cfelse><cfset "no" /></cfif>

      The direct-asking-for-pain way:

      <if condition="..."><false><set value="no" /></false><set value="no" /></if>
      <cfif ...><cfelse><cfset "no" /><cfset "no" /></cfif>

      And the coup de grace, the "right"-asking-for-pain way:

      <if condition="..."><false><set value="no" /></false><true><set value="no" /></true></if>
      <cfif ...><cfelse><cfset "no" /><cfset "no" /></cfif>

      The first two are what I included in my email this morning.  The third example (which I'm not much of a fan of and my patch doesn't support) was, if not officially supported, then used enough to be publicly recommended by people.  That's also what Mike asked about in his email this morning.  The fourth and fifth examples illustrate horribly brokenness in the 5.0 core files.  :)

      FB5.5 (and 5.5.1, of course) only allow true and false children to the if verb (the first example), and raise an exception if any other verb is detected.  My patch just adds a check so that if ONLY other verbs are detected, they'll be wrapped with the missing true automatically (the second example).  Examples 3, 4 and 5 remain unsupported.

      cheers,
      barneyb

      On Thu, Jan 7, 2010 at 7:16 PM, Sean Corfield <seancorfield@...> wrote:


      On Thu, Jan 7, 2010 at 9:30 AM, Barney Boisvert <bboisvert@...> wrote:
       Sorry, wasn't very clear. Your first example is correct. In 5.0

      these two snippets were equivalent:

      <if condition="...">
      <set ... />
      </if>

      <if condition="...">
      <true>
      <set ... />
      </true>
      </if>


      That was definitely a bug in 5.0 - it should never have been allowed (and I'm pretty sure it was never allowed in FB4.x?).

      Are you certain that in 5.0 if you execute the following, both x and y and z get set?

      <if condition="true">
      <set name="x" value="1"/>
      <set name="y" value="2"/>
      <set name="z" value="3"/>
      </if>
       
      I ask because with the behavior being a bug, I'm wondering whether it translates all children or just the first two?

      If I was in charge of the framework, I'd deny this patch on the grounds that the behavior was never intentional and I'd argue that you should go through your code and add <true> blocks in! :)

      I'd be interested to know the FB4.x behavior...
      --
      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





      --
      Barney Boisvert
      bboisvert@...
      http://www.barneyb.com/
    • Sean Corfield
      ... OK. If that s the case - and FB5 supports it - then it was a bug introduced in FB55 to disallow it :) I can understand wanting to disallow it in strict
      Message 2 of 25 , Jan 7, 2010
      • 0 Attachment
        On Thu, Jan 7, 2010 at 7:58 PM, Barney Boisvert <bboisvert@...> wrote:
        The optional-true functionality was officially supported in FB4.  In fact, if I recall correctly, the first versions of FB4 didn't have true/false at all.  If you wanted an if/else construct, you used two ifs and negated the condition of the second one.  I don't have the FB4 code anywhere to look at, but perhaps someone else does?

        OK. If that's the case - and FB5 supports it - then it was a bug introduced in FB55 to disallow it :)

        I can understand wanting to disallow it in strict mode tho'...

        I'd have to look at the code to see what I changed between FB5 and FB55. I can't imagine I went to so much trouble to disallow it. There should be a ticket that has an associated changeset for it - and that would be the code to look at to see what needs to be done...
        --
        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
      • Sean Corfield
        Bingo! http://trac.fusebox.org/fusebox/ticket/180 and the changeset that introduced the validation: http://trac.fusebox.org/fusebox/changeset/316 So the change
        Message 3 of 25 , Jan 7, 2010
        • 0 Attachment
          Bingo!

          http://trac.fusebox.org/fusebox/ticket/180

          and the changeset that introduced the validation:

          http://trac.fusebox.org/fusebox/changeset/316

          So the change to "revert" this will be to put this block (introduced
          in the changeset) into an if block on strict:

          http://trac.fusebox.org/fusebox/changeset/316#file4

          On Thu, Jan 7, 2010 at 8:48 PM, Sean Corfield <seancorfield@...> wrote:
          > On Thu, Jan 7, 2010 at 7:58 PM, Barney Boisvert <bboisvert@...> wrote:
          >>
          >> The optional-true functionality was officially supported in FB4.  In fact,
          >> if I recall correctly, the first versions of FB4 didn't have true/false at
          >> all.  If you wanted an if/else construct, you used two ifs and negated the
          >> condition of the second one.  I don't have the FB4 code anywhere to look at,
          >> but perhaps someone else does?
          >
          > OK. If that's the case - and FB5 supports it - then it was a bug introduced
          > in FB55 to disallow it :)
          > I can understand wanting to disallow it in strict mode tho'...
          > I'd have to look at the code to see what I changed between FB5 and FB55. I
          > can't imagine I went to so much trouble to disallow it. There should be a
          > ticket that has an associated changeset for it - and that would be the code
          > to look at to see what needs to be done...
        • Stephen Cassady
          Ha! I thought this conversation sounded familiar. I remember doing what Barney is doing - porting an application up from a previous fusebox version. Without
          Message 4 of 25 , Jan 7, 2010
          • 0 Attachment

            Ha!

             

            I thought this conversation sounded familiar. I remember doing what Barney is doing – porting an application up from a previous fusebox version. Without the <true> and <false>, the children in the tag were simply ignored. So the application was failing in a weird way – it would run (no errors) but ignored code that worked before (all those if statements without <true> <false>. That caused all sorts of neat things to happen in the application. J

             

            Stephen Cassady

             

            From: fusebox5@yahoogroups.com [mailto:fusebox5@yahoogroups.com] On Behalf Of Sean Corfield
            Sent: January-07-10 9:55 PM
            To: fusebox5@yahoogroups.com
            Subject: Re: [fusebox5] PATCH: implicit <true> in 5.5.1

             

             

            Bingo!

            http://trac.fusebox.org/fusebox/ticket/180

            and the changeset that introduced the validation:

            http://trac.fusebox.org/fusebox/changeset/316

            So the change to "revert" this will be to put this block (introduced
            in the changeset) into an if block on strict:

            http://trac.fusebox.org/fusebox/changeset/316#file4

            On Thu, Jan 7, 2010 at 8:48 PM, Sean Corfield <seancorfield@...> wrote:

            > On Thu, Jan 7, 2010 at 7:58 PM, Barney Boisvert <
            href="mailto:bboisvert%40gmail.com">bboisvert@...> wrote:
            >>
            >> The optional-true functionality was officially supported in FB4. 
            In fact,
            >> if I recall correctly, the first versions of FB4 didn't have
            true/false at
            >> all.  If you wanted an if/else construct, you used two ifs and
            negated the
            >> condition of the second one.  I don't have the FB4 code anywhere
            to look at,
            >> but perhaps someone else does?
            >
            > OK. If that's the case - and FB5 supports it - then it was a bug
            introduced
            > in FB55 to disallow it :)
            > I can understand wanting to disallow it in strict mode tho'...
            > I'd have to look at the code to see what I changed between FB5 and FB55. I
            > can't imagine I went to so much trouble to disallow it. There should be a
            > ticket that has an associated changeset for it - and that would be the
            code
            > to look at to see what needs to be done...

          • Kai Koenig
            ... Agreeing with Sean, although there s a lot of use for the short-hand notation, I d like to see it disallowed in strict mode. Just as a side note: Had a
            Message 5 of 25 , Jan 8, 2010
            • 0 Attachment




              On Thu, Jan 7, 2010 at 7:58 PM, Barney Boisvert <bboisvert@...> wrote:
              The optional-true functionality was officially supported in FB4.  In fact, if I recall correctly, the first versions of FB4 didn't have true/false at all.  If you wanted an if/else construct, you used two ifs and negated the condition of the second one.  I don't have the FB4 code anywhere to look at, but perhaps someone else does?

              OK. If that's the case - and FB5 supports it - then it was a bug introduced in FB55 to disallow it :)

              I can understand wanting to disallow it in strict mode tho'...

              I'd have to look at the code to see what I changed between FB5 and FB55. I can't imagine I went to so much trouble to disallow it. There should be a ticket that has an associated changeset for it - and that would be the code to look at to see what needs to be done...
              -- 


              Agreeing with Sean, although there's a lot of use for the short-hand 
              notation, I'd like to see it disallowed in strict mode.

              Just as a  side note: Had a look in one of the FB 4 books and it 
              stated that the <true> and <false> verbs were optional in FB 4. 
              Haven't tried it with actual code and the FB 4 core though.

              Cheers
              Kai



              _________________________________________________
              Kai Koenig - Ventego Creative Ltd
              ph: +64 4 476 6781 - mob: +64 21 928 365 /  +61 450 132 117








            • Sandra Clark
              Actually, that is incorrect. I recall while Alpha Testing having discussions with John Q regarding this. The true and false blocks were in FB4 from the
              Message 6 of 25 , Jan 8, 2010
              • 0 Attachment
                Actually, that is incorrect. I recall while Alpha Testing having discussions with John Q regarding this.  The true and false blocks were in FB4 from the beginning.

                Sandy

                Barney Wrote:

                  In fact, if I recall correctly, the first versions of FB4 didn't have true/false at all. If you wanted an if/else construct, you used two ifs and negated the condition of the second one.
              • Jeffrey Roberson
                Sandy is correct. The true/false blocks have always been there. I actually never knew that they were ever optional. Jeff
                Message 7 of 25 , Jan 8, 2010
                • 0 Attachment
                  Sandy is correct.

                  The true/false blocks have always been there.  I actually never knew that they were ever optional.

                  Jeff

                  On Jan 8, 2010, at 6:18 AM, Sandra Clark wrote:

                   

                  Actually, that is incorrect. I recall while Alpha Testing having discussions with John Q regarding this.  The true and false blocks were in FB4 from the beginning.

                  Sandy

                  Barney Wrote:

                    In fact, if I recall correctly, the first versions of FB4 didn't have true/false at all. If you wanted an if/else construct, you used two ifs and negated the condition of the second one.


                • Mike Ritchie
                  Weird, some people are saying that as early as FB4 the tag would work without a / child, but that s not my recollection. I remember wondering
                  Message 8 of 25 , Jan 8, 2010
                  • 0 Attachment
                    Weird, some people are saying that as early as FB4 the <if> tag would
                    work without a <true>/<false> child, but that's not my recollection. I
                    remember wondering why something wasn't behaving as expected in my
                    fuseaction, only to discover that I had put my conditional tags directly
                    inside the <if> block. Only by adding the <true> and moving my own tags
                    inside this child was I able to correct the problem. It was a very
                    passive-aggressive system, it wouldn't tell you when there was a
                    problem, it would just ignore you.

                    Kind of like my wife... badump bump tsss!

                    Mike
                    www.fusebuilder.net

                    P.S.: Sean, is there someone around here that still has commit
                    permissions, if Barney's revised patch fits the bill?


                    Jeffrey Roberson wrote:
                    >
                    > Sandy is correct.
                    >
                    >
                    > The true/false blocks have always been there. I actually never knew
                    > that they were ever optional.
                    >
                    > Jeff
                    >
                    > On Jan 8, 2010, at 6:18 AM, Sandra Clark wrote:
                    >
                    >>
                    >> Actually, that is incorrect. I recall while Alpha Testing having
                    >> discussions with John Q regarding this. The true and false blocks
                    >> were in FB4 from the beginning.
                    >>
                    >> Sandy
                    >>
                    >> Barney Wrote:
                    >>
                    >> In fact, if I recall correctly, the first versions of FB4 didn't have
                    >> true/false at all. If you wanted an if/else construct, you used two
                    >> ifs and negated the condition of the second one.
                    >>
                    >
                    >
                    > ------------------------------------------------------------------------
                    >
                    >
                    > No virus found in this incoming message.
                    > Checked by AVG - www.avg.com
                    > Version: 9.0.725 / Virus Database: 270.14.129/2605 - Release Date: 01/06/10 23:35:00
                    >
                    >
                  • Barney Boisvert
                    ... I have commit access to SVN so I can commit accepted patches, but I m not an/the acceptor of patches. cheers, barneyb -- Barney Boisvert
                    Message 9 of 25 , Jan 8, 2010
                    • 0 Attachment
                      On Fri, Jan 8, 2010 at 8:39 AM, Mike Ritchie <starkraving2002@...> wrote:
                      > P.S.: Sean, is there someone around here that still has commit
                      > permissions, if Barney's revised patch fits the bill?

                      I have commit access to SVN so I can commit accepted patches, but I'm
                      not an/the "acceptor" of patches.

                      cheers,
                      barneyb

                      --
                      Barney Boisvert
                      bboisvert@...
                      http://www.barneyb.com/
                    • Sean Corfield
                      ... Since no one is project lead at the moment, there is no acceptor ... If you want me to review the patch before you commit it, I can, but with my current
                      Message 10 of 25 , Jan 8, 2010
                      • 0 Attachment
                        On Fri, Jan 8, 2010 at 9:44 AM, Barney Boisvert <bboisvert@...> wrote:
                        I have commit access to SVN so I can commit accepted patches, but I'm
                        not an/the "acceptor" of patches.

                        Since no one is "project lead" at the moment, there is no "acceptor"...

                        If you want me to review the patch before you commit it, I can, but with my current workload it'll be next week at the earliest...
                        --
                        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
                      • Kai Koenig
                        ... Moving forward from here, what is people s opinion on further work/patches of Fusebox. I ve got a client who s made an investment into the framework and as
                        Message 11 of 25 , Jan 8, 2010
                        • 0 Attachment

                          On Fri, Jan 8, 2010 at 9:44 AM, Barney Boisvert <bboisvert@...> wrote:
                          I have commit access to SVN so I can commit accepted patches, but I'm
                          not an/the "acceptor" of patches.

                          Since no one is "project lead" at the moment, there is no "acceptor"...

                          If you want me to review the patch before you commit it, I can, but with my current workload it'll be next week at the earliest...

                          Moving forward from here, what is people's opinion on further work/patches
                          of Fusebox. I've got a client who's made an investment into the framework
                          and as much as I think FB as a framework does a good job in what I (and
                          them) use it for, I'd love the overall infrastructure around FB to improve - 
                          documentation, tools like Kevin's scaffolder etc.

                          Does the framework need a dedicated project lead - could a steering
                          committee (and afaics that used to be team fusebox) of 2-4 people
                          take maybe take over that role - at least for stuff like patches, minor
                          releases further down the track?

                          After the not-worked-out fork - is there maybe a case for a fork that's
                          run by more than one person but a group of people who actually have
                          an interest in the framework and actually use it to build applications 
                          with it?

                          Just a few thoughts...

                          Cheers
                          Kai









                        • pietro_robertson
                          Moving forward from here is a good topic Kai and thank you for raising it. One of the main problems I see is the legal status of Fusebox expressed as
                          Message 12 of 25 , Jan 9, 2010
                          • 0 Attachment
                            "Moving forward from here" is a good topic Kai and thank you for raising it.

                            One of the main problems I see is the 'legal' status of Fusebox expressed as follows; ".. TeraTech owns it and wouldn't relinquish it to a community-driven Fusebox team.." which was posted by Sean Corfield, 18 Nov 09, on the FuseNG list. I also have some idea that the core is somehow 'owned' by Teratech in the sense that while it is open source, only Teratech can decide what is in or out and they don't seem too interested. This being the case, and the fact that forking hasn't resulted in anything positive, is it worth making another approach to Teratech or is that a lost cause? My feeling is that if an involved community can't get control of the name and domain and run the repository, then the chances of morphing it forward are remote. If it were possible to do that, I'd like to put my hand up for the documentation project.

                            Cheers



                            Peter Robertson
                          • jordanreiter
                            ... Well, it looks like the patch is overkill, since all we really want to do is enforce true/false fields for strict mode, right? Surely something as simple
                            Message 13 of 25 , Jan 9, 2010
                            • 0 Attachment
                              > P.S.: Sean, is there someone around here that still has commit
                              > permissions, if Barney's revised patch fits the bill?

                              Well, it looks like the patch is overkill, since all we really want to do is enforce true/false fields for strict mode, right?

                              Surely something as simple as this should do the trick. Changing

                              if (fb_.verbInfo.children[fb_.i].getNamespace() is not "") {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              }

                              to

                              if (fb_.verbInfo.children[fb_.i].getNamespace() is not "" AND fb_.verbInfo.action.getCircuit().getApplication().strictMode) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "In strict mode, an 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              }

                              and

                              fb_.hasTrue = false;
                              [...]
                              case "true":
                              if (fb_.hasTrue) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain at most one 'true' verb in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else {
                              fb_.hasTrue = true;
                              }
                              break;
                              case "false":
                              if (fb_.hasFalse) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain at most one 'false' verb in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else {
                              fb_.hasFalse = true;
                              }
                              break;
                              default:
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              break;
                              }

                              to

                              fb_.hasTrue = false;
                              fb_.implicitTrue = false;
                              [...]
                              case "true":
                              if (fb_.hasTrue) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain at most one 'true' verb in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else if (fb_.implicitTrue) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "The 'if' is using implicit true, 'true' and 'false' verbs aren't allowed in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else {
                              fb_.hasTrue = true;
                              }
                              break;
                              case "false":
                              if (fb_.hasFalse) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "An 'if' may contain at most one 'false' verb in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else if (fb_.implicitTrue) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "The 'if' is using implicit true, 'true' and 'false' verbs aren't allowed in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else {
                              fb_.hasFalse = true;
                              }
                              break;
                              default:
                              if (fb_.verbInfo.action.getCircuit().getApplication().strictMode) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "In strict mode, an 'if' may contain only 'true' and 'false' verbs in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else if (fb_.hasTrue || fb_.hasFalse) {
                              fb_throw("fusebox.badGrammar.illegalVerb",
                              "Illegal verb",
                              "The 'if' has a true or false verb, so the 'if' cannot use implicit true in fuseaction #fb_.verbInfo.circuit#.#fb_.verbInfo.fuseaction#.");
                              } else {
                              fb_.implicitTrue = true;
                              }
                              break;
                              }
                            • Sean Corfield
                              I think the ideal solution for Fusebox at this point would be for 4CFF to take it over - but that would mean persuading TeraTech to give up copyright and turn
                              Message 14 of 25 , Jan 9, 2010
                              • 0 Attachment
                                I think the ideal solution for Fusebox at this point would be for 4CFF to take it over - but that would mean persuading TeraTech to give up copyright and turn it over to 4CFF (much like the Apache Foundation owns copyright on all of its projects).

                                Sean


                                On Sat, Jan 9, 2010 at 2:18 AM, pietro_robertson <pietro_robertson@...> wrote:
                                 



                                "Moving forward from here" is a good topic Kai and thank you for raising it.

                                One of the main problems I see is the 'legal' status of Fusebox expressed as follows; ".. TeraTech owns it and wouldn't relinquish it to a community-driven Fusebox team.." which was posted by Sean Corfield, 18 Nov 09, on the FuseNG list. I also have some idea that the core is somehow 'owned' by Teratech in the sense that while it is open source, only Teratech can decide what is in or out and they don't seem too interested. This being the case, and the fact that forking hasn't resulted in anything positive, is it worth making another approach to Teratech or is that a lost cause? My feeling is that if an involved community can't get control of the name and domain and run the repository, then the chances of morphing it forward are remote. If it were possible to do that, I'd like to put my hand up for the documentation project.

                                Cheers

                                Peter Robertson




                                --
                                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
                              • Adam Haskell
                                Sean, I think a foundation will have more luck than an individual. Michael really needs to be explained what is going on and how the foundation taking over
                                Message 15 of 25 , Jan 11, 2010
                                • 0 Attachment
                                  Sean, I think a foundation will have more luck than an individual. Michael really needs to be explained what is going on and how the foundation taking over would be beneficial. I'd offer assistance but I don't think Michael is interested in hearing from me anymore so I'll continue to lurk in the shadows again :)

                                  Adam


                                  On Sun, Jan 10, 2010 at 1:34 AM, Sean Corfield <seancorfield@...> wrote:
                                   

                                  I think the ideal solution for Fusebox at this point would be for 4CFF to take it over - but that would mean persuading TeraTech to give up copyright and turn it over to 4CFF (much like the Apache Foundation owns copyright on all of its projects).


                                  Sean


                                  On Sat, Jan 9, 2010 at 2:18 AM, pietro_robertson <pietro_robertson@...> wrote:
                                   



                                  "Moving forward from here" is a good topic Kai and thank you for raising it.

                                  One of the main problems I see is the 'legal' status of Fusebox expressed as follows; ".. TeraTech owns it and wouldn't relinquish it to a community-driven Fusebox team.." which was posted by Sean Corfield, 18 Nov 09, on the FuseNG list. I also have some idea that the core is somehow 'owned' by Teratech in the sense that while it is open source, only Teratech can decide what is in or out and they don't seem too interested. This being the case, and the fact that forking hasn't resulted in anything positive, is it worth making another approach to Teratech or is that a lost cause? My feeling is that if an involved community can't get control of the name and domain and run the repository, then the chances of morphing it forward are remote. If it were possible to do that, I'd like to put my hand up for the documentation project.

                                  Cheers

                                  Peter Robertson




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

                                • Jason Daiger
                                  Whom w/in the 4CFF would be the best candidate to take on this task? -Jason ... -- *Jason Daiger*, /Dir of Technology Services/* Attendee Interactive, LLC*
                                  Message 16 of 25 , Jan 11, 2010
                                  • 0 Attachment
                                    Whom w/in the 4CFF would be the best candidate to take on this task?

                                    -Jason
                                     
                                    --
                                    Jason Daiger, Dir of Technology Services
                                    Attendee Interactive, LLC

                                    URL: http://www.attendeeinteractive.com
                                    EML: jason@...
                                    PH: 410.480.8148 x 301

                                    Please consider your environmental responsibility before printing this e-mail
                                  • Adam Haskell
                                    My honest opinion is non of them. I think a group of long term Fusebox users should go to Teratech and talk to them, it needs to be the community, not a
                                    Message 17 of 25 , Jan 11, 2010
                                    • 0 Attachment
                                      My honest opinion is non of them. I think a group of long term Fusebox users should go to Teratech and talk to them, it needs to be the community, not a representative of the community that talks to Michael. At most 4CFF should be willing to facilitate that discussion, and of course, will to take the project over. As a matter of who in 4CFF could facilitate if I recall John Zhu has a relationship with the Teratech so he might be a good facilitator, another candidate might be Dan Wilson whom runs another framework (Model Glue) and is very good and making sure the real intent is communicated.


                                      Adam


                                      On Mon, Jan 11, 2010 at 10:53 AM, Jason Daiger <jason@...> wrote:
                                       

                                      Whom w/in the 4CFF would be the best candidate to take on this task?

                                      -Jason
                                       

                                      --
                                      Jason Daiger, Dir of Technology Services
                                      Attendee Interactive, LLC

                                      URL: http://www.attendeeinteractive.com
                                      EML: jason@...
                                      PH: 410.480.8148 x 301

                                      Please consider your environmental responsibility before printing this e-mail

                                    • Sean Corfield
                                      ... Discussions within 4CFF lead me to believe that John Zhu will be approaching Michael about this at some point (or may have already done so?). -- Sean A
                                      Message 18 of 25 , Jan 11, 2010
                                      • 0 Attachment
                                        On Mon, Jan 11, 2010 at 8:30 AM, Adam Haskell <a.haskell@...> wrote:
                                        My honest opinion is non of them. I think a group of long term Fusebox users should go to Teratech and talk to them, it needs to be the community, not a representative of the community that talks to Michael. At most 4CFF should be willing to facilitate that discussion, and of course, will to take the project over. As a matter of who in 4CFF could facilitate if I recall John Zhu has a relationship with the Teratech so he might be a good facilitator, another candidate might be Dan Wilson whom runs another framework (Model Glue) and is very good and making sure the real intent is communicated. 

                                        Discussions within 4CFF lead me to believe that John Zhu will be approaching Michael about this at some point (or may have already done so?).
                                        --
                                        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
                                      • Adam Haskell
                                        Cool, being that they have a relationship that would be nice. I do feel like it would be better for someone outside of the foundation also talk to Teratech. I
                                        Message 19 of 25 , Jan 11, 2010
                                        • 0 Attachment
                                          Cool, being that they have a relationship that would be nice. I do feel like it would be better for someone outside of the foundation also talk to Teratech. I think part of the issue I had with talking to them was a lack of community voice actually saying something to Teratech. Good luck with it!

                                          Adam


                                          On Mon, Jan 11, 2010 at 2:03 PM, Sean Corfield <seancorfield@...> wrote:
                                           

                                          On Mon, Jan 11, 2010 at 8:30 AM, Adam Haskell <a.haskell@...> wrote:
                                          My honest opinion is non of them. I think a group of long term Fusebox users should go to Teratech and talk to them, it needs to be the community, not a representative of the community that talks to Michael. At most 4CFF should be willing to facilitate that discussion, and of course, will to take the project over. As a matter of who in 4CFF could facilitate if I recall John Zhu has a relationship with the Teratech so he might be a good facilitator, another candidate might be Dan Wilson whom runs another framework (Model Glue) and is very good and making sure the real intent is communicated. 

                                          Discussions within 4CFF lead me to believe that John Zhu will be approaching Michael about this at some point (or may have already done so?).
                                          --
                                          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

                                        • Barney Boisvert
                                          ... The reason I implemented my patch the way I did was so that the true verb is still invoked regardless of whether the true node is present in the XML. Yes,
                                          Message 20 of 25 , Jan 11, 2010
                                          • 0 Attachment
                                            On Sat, Jan 9, 2010 at 4:07 PM, jordanreiter <jordanthecoder@...> wrote:
                                            > Well, it looks like the patch is overkill, since all we really want to do is enforce true/false fields for strict mode, right?
                                            >
                                            > Surely something as simple as this should do the trick.
                                            > <snip />

                                            The reason I implemented my patch the way I did was so that the true
                                            verb is still invoked regardless of whether the true node is present
                                            in the XML. Yes, it's a bit complex on the inside, but I was
                                            attempting to minimize the external effects of the change.

                                            The change would have been best implemented in fuseboxIfVerb.compile,
                                            but the 'do' verb is the only verb with a custom implementation - the
                                            rest all use fuseboxVerb, so there isn't an if-specific place to do IR
                                            transformations. As such, I'm doing it in the verb itself, which is
                                            total hack. :)

                                            cheers,
                                            barneyb

                                            --
                                            Barney Boisvert
                                            bboisvert@...
                                            http://www.barneyb.com/
                                          Your message has been successfully submitted and would be delivered to recipients shortly.