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

Re: [fusebox5] Nesting custom lexicon verbs

Expand Messages
  • Patrick McElhaney
    Instead of borrowing ideas from CF custom tags, could you just use custom tags? What I m thinking is the parser might translate your verbs to custom tag calls
    Message 1 of 14 , Feb 1, 2006
    • 0 Attachment
      Instead of borrowing ideas from CF custom tags, could you just use custom tags?

      What I'm thinking is the parser might translate your verbs to custom
      tag calls and then execute that code.*

      <cfmodule template="[...]/sean/outer.cfm">
      <cfmodule template="[...]/fb/set.cfm"name="foo" value="1" />
      <cfmodule template="[...]/sean/middle.cfm">
      <cfmodule template="[...]/sean/inner.cfm"/>
      </cfmodule>
      </cfmodule>

      That way you could define your verbs as plain old CF custom tags.
      Here's an example of the loop verb rewritten as a custom tag.

      <cfscript>
      // mode=begin
      if (thisTag.executionMode EQ "startTag") {
      if (StructKeyExists(attributes, 'condition')) {
      caller.fb_appendLine('<cfloop condition="' & attributes['condition'] & '">');
      }
      else if (StructKeyExists(attributes, 'query')) {
      caller.fb_appendLine('<cfloop query="' & attributes['query'] & '">');
      }
      else if (StructKeyExists(attributes, 'from')
      AND StructKeyExists(attributes, 'to')
      AND StructKeyExists(attributes, 'index')) {
      if (NOT StructKeyExists(attributes, 'step')) {
      attributes.step = 1;
      }
      caller.fb_appendLine('<cfloop from="' & attributes['from'] & '"'
      & ' to="' & attributes['to'] & '"'
      & ' index="' & attributes['index'] & '"'
      & ' step="' & attributes['step'] & '"'
      & '>');
      }
      caller.fb_increaseIndent();
      } else { // mode=end
      caller.fb_decreaseIndent();
      caller.fb_appendline("</cfloop>");
      }
      </cfscript>

      CF custom tags are already implemented, thoroughly tested, documented,
      and supported by Adobe. And custom tags support nesting. If we
      implemented verbs as custom tags, we'd get all that for free.

      Patrick


      * FB takes Sean's <sean.outer>...</sean.outer> example, replaces all
      the tag names with cfmodule template="..." and writes the result to a
      temp file. It then executes the temp file, which outputs your "parsed"
      code. Finally, unless you're doing a debug build, it deletes the temp
      file.


      --
      Patrick McElhaney
      704.560.9117
      http://pmcelhaney.weblogs.us
    • Sean Corfield
      ... In order to do that, the parser would need to translate XML first to custom tag calling code like the above and then execute that, just to generate the
      Message 2 of 14 , Feb 1, 2006
      • 0 Attachment
        On Feb 1, 2006, at 5:02 AM, Patrick McElhaney wrote:
        > What I'm thinking is the parser might translate your verbs to custom
        > tag calls and then execute that code.*
        >
        > <cfmodule template="[...]/sean/outer.cfm">
        > <cfmodule template="[...]/fb/set.cfm"name="foo" value="1" />
        > <cfmodule template="[...]/sean/middle.cfm">
        > <cfmodule template="[...]/sean/inner.cfm"/>
        > </cfmodule>
        > </cfmodule>

        In order to do that, the parser would need to translate XML first to
        custom tag calling code like the above and then execute that, just to
        generate the parsed files! And you'd need to add in all the code to
        validate the availability of the files and the attributes and so on
        and so forth. That's a lot of additional work compared to how things
        work today - or how things work in my prototype. And with cfmodule
        you introduce all sorts of scoping issues regarding how custom verbs
        execute.

        My approach builds a tree of objects - a syntax tree, performing
        syntax validation at that point - and then a compile() method is
        called which generates the parsed file.

        Sean A Corfield
        An Architect's View -- http://corfield.org/

        "I'm trying to ban e-mail attachments. I just want an ASCII e-mail.
        If you want to show me something, put it in a Web page, publish it,
        give me the URL, and I'll look at it. That's the new model."
        -- Scott McNealy, CEO of Sun Microsystems, in May 1997 Upside magazine.
      • Sean Corfield
        ... Well, yes and no. Today, custom verbs are executed just once for those forms because XML requires the close tag. CFML is not XML and so it has a
        Message 3 of 14 , Feb 1, 2006
        • 0 Attachment
          On Jan 31, 2006, at 9:43 PM, Barney Boisvert wrote:
          > > <ns.verb /> - executed exactly as it is today
          > > <ns.verb> </ns.verb> - treated identically to <ns.verb />
          >
          > This is at odds with both CFML custom tags, and the semantics of XML.

          Well, yes and no. Today, custom verbs are executed just once for
          those forms because XML requires the close tag.

          CFML is not XML and so it has a distinction between <cf_tag> and
          <cf_tag/> which is really somewhat artificial. The important issue is
          not really whether it has an end tag - XML is *required* to have an
          end tag - but whether it has children.

          > Of course, because of the way lexicons were
          > _unofficially_ implemented in 4.1, there's a backwards compatibility
          > issue.

          Right and since some people *are* using them, I'd rather not break
          them if we don't have to (and I don't believe we *have* to break them).

          > I'd have to vote that the CFML/XML perspective is
          > the better route to go.

          Which is it? CFML and XML do not behave the same way here. XML
          requires <custom.verb/> where CFML would allow <cf_customVerb>
          whereas the intentional case is the same in both:

          <custom.verb>
          <set name="foo" value="42"/>
          </custom.verb>

          <cf_customVerb>
          <cfset foo = "42">
          </cf_customVerb>

          If I used fb_.verbInfo.hasChildren instead of fb_.verbInfo.hasEndTag
          would that satisfy you?

          > John QvT was quite clear in saying that there
          > was not even a hint "we'll keep stuff compatible" between the 4.1
          > implementation of lexicons and the future official implementation.

          Right. He didn't make a promise to keep it compatible. He also didn't
          say that we *would* break it.

          > Would this be tied to a single lexicon? Here's some code:
          >
          > <sean.outer>
          > <beb.tag>
          > <sean.inner />
          > </beb.tag>
          > </sean.outer>

          sean.inner: fb_.verbInfo.parent would be beb.tag's verbInfo
          beb.tag: fb_.verbInfo.parent would be sean.outer's verbInfo

          Code can validate whether it is appropriately nested or not and can
          walk to the "right" parent.

          > Is beb.tag parentless, or is it's parent sean.outer? And is
          > sean.inner's parent beb.tag, or sean.outer?

          As it stands, it handles the common case (simple nesting within one
          namespace) but also allows you to implement in one namespace, a verb
          that interacts with an existing (e.g., third-party) verb from another
          namespace.

          You can easily walk up to the parent in your own namespace:

          <cfset info = fb_.verbInfo>
          <cfloop condition="structKeyExists(info,'parent') and
          info.parent.lexicon is not fb_.verbInfo.lexicon">
          <cfset info = info.parent>
          </cfloop>
          <cfif structKeyExists(info,"parent")>
          <!--- i have a parent in my lexicon --->
          <cfelse>
          <!--- i have no parent in my lexicon --->
          </cfif>

          > Something strikes me as weird about having your context
          > skip part of the context (the built-in tags), but I can't think of a
          > time when you'd care.

          Exactly! Since the built-in tags function the same way regardless,
          why would custom verbs need access to them? And I would not want to
          encourage creation of custom verbs whose behave depended on the built-
          in verbs around them - I think that opens the doors for some horribly
          obtuse code. Imagine this code:

          <if condition="someExpression">
          <true>
          <custom.verb/>
          </true>
          <false>
          <custom.verb/>
          </false>
          </if>

          But custom.verb was able to look at it's parent (either <true> or
          <false>) and behave differently?!?!?! That creates a terrible lack of
          transparency to the XML...

          > Also, if the built-ins are shipped as a custom
          > lexicon that comes with the cores for free (that has been discussed,
          > and seems like a good idea to me, just for maintenance reasons), this
          > could become a more pressing issue.

          I've thought about that and I'm really not sure I like that idea. I
          think it introduces additional complexity because there are
          optimizations and "smarts" that can be built into the parser if it is
          able to manage custom code for the built-ins that it would perhaps
          have to give up if all the verbs were handled through the lexicon
          machinery. I also think it would be harder to provide robust error
          handling that way.

          Example: today, the core files read and process all the XML and
          validate attributes etc but custom verbs do their validation only
          when the verb is actually executed. In other words, if the built-ins
          were custom verbs, you would only catch XML errors when a specific
          fuseaction was requested (as opposed to at load time).

          Sean A Corfield
          An Architect's View -- http://corfield.org/
          Team Fusebox -- http://fusebox.org/
          Got Gmail? -- I have 100, yes 100, invites to give away!

          "If you're not annoying somebody, you're not really alive."
          -- Margaret Atwood
        • Patrick McElhaney
          ... Yes, that s exactly what I had in mind. It is a little unorthodox, isn t it? That doesn t bother me. Does it bother you? ... What do you do when you check
          Message 4 of 14 , Feb 1, 2006
          • 0 Attachment
            On 2/1/06, Sean Corfield <sean@...> wrote:
            > On Feb 1, 2006, at 5:02 AM, Patrick McElhaney wrote:
            > > What I'm thinking is the parser might translate your verbs to custom
            > > tag calls and then execute that code.*
            > >
            > > ...
            >
            > In order to do that, the parser would need to translate XML first to
            > custom tag calling code like the above and then execute that, just to
            > generate the parsed files!

            Yes, that's exactly what I had in mind. It is a little unorthodox,
            isn't it? That doesn't bother me. Does it bother you?


            > And you'd need to add in all the code to validate the availability of
            > the files ...

            What do you do when you check for the file and it's not there? Throw
            an exception, right? What if you didn't check, and cfmodule tried to
            include a nonexistent file? CF would throw an exception, right?

            The only difference I can see is your exception would provide a little
            more detail than cfmodule's exception. But you could catch cfmodule's
            exception and throw a more meaningful one. That would actually be more
            efficient, if you're counting CPU cycles. And it seems to be how the
            current implementation works.

            Are you proposing a solution in which custom lexicons code is added to
            an existing file? Because otherwise, it sounds like you'd still have
            to check for a file.


            > And you'd need to add in all the code to validate ... attributes and so on and so forth.

            My first reaction is "isn't that what schema are for"? But I'm
            assuming you've already discussed that at length.

            Regardless, I think that concern is orthogonal to the problem I
            propose could be solved with the help of cfmodule. Whatever you're
            already doing to validate attributes and so forth would probably work.


            > That's a lot of additional work compared to how things
            > work today - or how things work in my prototype.
            I don't see where any additional work is needed.

            I do see where you might save a lot of work in not creating something
            that's very similar to CF's custom tag architecture. So if it is more
            work here, it's less work there; in toto, a net loss.

            I also see where the simplicity of the cfmodule approach may save FB
            developers some work. I'd rather a few framework architects do more
            work once, than many FB developers do more work every time they create
            a custom verb.


            > And with cfmodule you introduce all sorts of scoping issues regarding
            > how custom verbs execute.
            The code that is executed is the output of the parser. And the output
            of the parser is the same, whether the parser is implemented with the
            cfmodule approach or any other approach. Does that make sense? Or
            maybe I misunderstood what you meant by "scoping issues"?

            Patrick

            --
            Patrick McElhaney
            704.560.9117
            http://pmcelhaney.weblogs.us
          • Patrick McElhaney
            ... Maybe you can kill two birds with one stone. -- works the old, unofficial FB 4.1 way -- works the new, official FB5 way Then you
            Message 5 of 14 , Feb 1, 2006
            • 0 Attachment
              On 2/1/06, Barney Boisvert <bboisvert@...> wrote:

              > Of course, because of the way lexicons were
              > _unofficially_ implemented in 4.1, there's a backwards compatibility
              > issue.

              Maybe you can kill two birds with one stone.

              <barney.tag> -- works the old, unofficial FB 4.1 way
              <barney:tag> -- works the new, official FB5 way

              Then you could deprecate the old way.

              Patrick

              --
              Patrick McElhaney
              704.560.9117
              http://pmcelhaney.weblogs.us
            • Sean Corfield
              ... Yes, it s a very ugly translation process that adds an entire other layer above and beyond either how today s core files work or how the Fusebox 5 core
              Message 6 of 14 , Feb 1, 2006
              • 0 Attachment
                On Feb 1, 2006, at 6:33 PM, Patrick McElhaney wrote:
                > Yes, that's exactly what I had in mind. It is a little unorthodox,
                > isn't it? That doesn't bother me. Does it bother you?

                Yes, it's a very ugly translation process that adds an entire other
                layer above and beyond either how today's core files work or how the
                Fusebox 5 core files will work.

                > What do you do when you check for the file and it's not there?

                The Fusebox core files are very thorough about validation and
                providing standardized exceptions.

                > > And you'd need to add in all the code to validate ... attributes
                > and so on and so forth.
                >
                > My first reaction is "isn't that what schema are for"? But I'm
                > assuming you've already discussed that at length.

                The core files validate the built-in verbs. Introducing XML schema
                validation to the core would require ColdFusion MX 7 and without
                that, the core would still have to do the validation regardless of
                what developers did in editing the XML.

                > I also see where the simplicity of the cfmodule approach may save FB
                > developers some work.

                Using <cfmodule> would actually create *more* work for Fusebox
                developers because it would be harder to write custom lexicons. If
                you don't see that, I suspect you haven't written many custom
                lexicons with Fusebox 4.1?

                > Or maybe I misunderstood what you meant by "scoping issues"?

                Yes, you misunderstood. Again, if you haven't written many custom
                lexicons, it is likely you would not realize what I meant.

                Sean A Corfield
                An Architect's View -- http://corfield.org/
                Get Glued! -- http://model-glue.com/
                The Model-Glue ColdFusion Framework

                "If you're not annoying somebody, you're not really alive."
                -- Margaret Atwood
              • Patrick McElhaney
                You got me, Sean. I haven t written any custom lexicons in FB4. I couldn t find any documention on the subject, and what knowledge I have was obtained from
                Message 7 of 14 , Feb 1, 2006
                • 0 Attachment
                  You got me, Sean. I haven't written any custom lexicons in FB4. I
                  couldn't find any documention on the subject, and what knowledge I
                  have was obtained from reading the source code.

                  So, where can I go to find out about custom lexicons?

                  Patrick

                  --
                  Patrick McElhaney
                  704.560.9117
                  http://pmcelhaney.weblogs.us
                • Sean Corfield
                  ... Yeah, and that s really, really hard to follow as far as custom verbs are concerned... :( ... I ll make sure there is some for Fusebox 5 when we have it
                  Message 8 of 14 , Feb 1, 2006
                  • 0 Attachment
                    On Feb 1, 2006, at 7:16 PM, Patrick McElhaney wrote:
                    > You got me, Sean. I haven't written any custom lexicons in FB4. I
                    > couldn't find any documention on the subject, and what knowledge I
                    > have was obtained from reading the source code.

                    Yeah, and that's really, really hard to follow as far as custom verbs
                    are concerned... :(

                    > So, where can I go to find out about custom lexicons?

                    I'll make sure there is some for Fusebox 5 when we have it baked into
                    the framework!

                    John Beynon has a little bit about custom verbs in the Fusebox 4.1
                    tutorial he has on his site:

                    http://john.beynon.org.uk/downloads/LearnFB_lesson6.pdf

                    http://john.beynon.org.uk/index.cfm/2004/11/4/LOCK--TRANSACTION-
                    custom-lexicon

                    Sean A Corfield
                    An Architect's View -- http://corfield.org/

                    "Progress isn't made by early risers. It's made by lazy men trying to
                    find easier ways to do something."
                    -- Robert Heinlein
                  • Sean Corfield
                    ... You must have been eavesdropping on the conversation Barney and I were having in IM today... or maybe you are Barney in disguise? Barney and I settled on
                    Message 9 of 14 , Feb 1, 2006
                    • 0 Attachment
                      On Feb 1, 2006, at 6:53 PM, Patrick McElhaney wrote:
                      > Maybe you can kill two birds with one stone.
                      >
                      > <barney.tag> -- works the old, unofficial FB 4.1 way
                      > <barney:tag> -- works the new, official FB5 way
                      >
                      > Then you could deprecate the old way.

                      You must have been eavesdropping on the conversation Barney and I
                      were having in IM today... or maybe you are Barney in disguise?

                      Barney and I settled on pretty much that in IM and I implemented it
                      in my prototype compiler to test it out.

                      fusebox.xml:

                      <lexicons>
                      <lexicon name="barney" path="barneys/tags/" />
                      </lexicons>

                      circuit.xml:

                      <barney.oldtag/> - executes just once, never has a parent, ignores
                      its body

                      <barney:newtag/> - executes twice (executionMode = "start" then
                      executionMode = "end")

                      <barney:newtag> - executes with executionMode = "start"
                      <set name="foo" value="42" /> - compiles this
                      </barney:newtag> - executes with executionMode = "end"

                      <barney:newtag>
                      <barney:nested/> - executes twice but has parent = barney:tag
                      </barney:newtag>

                      It would mean that a FB41 custom verb couldn't be used directly with
                      the new syntax without a slight modification, wrapping the code in
                      the following:

                      <cfif not structKeyExists(fb_.verbInfo,"executionMode") or
                      fb_.verbInfo.executionMode is "start">
                      ... body of custom verb ...
                      </cfif>

                      Note that an old style invocation never has a parent so with the
                      following:

                      <barney:newtag>
                      <barney.oldtag/> - executes ONCE but has NO parent
                      </barney:newtag>

                      Another consideration is that <prefix:verb/> relies on XML namespaces
                      - you can't parse such a file without an XML namespace declaration.
                      Fortunately, the core files can automagically handle that for you,
                      rewriting the <circuit> tag internally as this:

                      <circuit xmlns:barney="file:lexicon/barneys/tags/">

                      Of course, you can specify this manually as well if you want to use
                      XML editors that can validate your custom verbs (which you cannot do
                      with FB41 custom verbs). If you specify it manually, the core files
                      would use your namespace declaration instead.

                      Sean A Corfield
                      An Architect's View -- http://corfield.org/

                      "I have always wished that my computer would be as easy to use as my
                      telephone. My wish has come true - I no longer know how to use my
                      telephone."
                      -- Bjarne Stroustrup
                    • Patrick McElhaney
                      ... Dude, you need to come look at some of the code I have to deal with every day. Thanks for the examples. They look pretty much the way I expected them to
                      Message 10 of 14 , Feb 2, 2006
                      • 0 Attachment
                        On 2/1/06, Sean Corfield <sean@...> wrote:
                        > On Feb 1, 2006, at 7:16 PM, Patrick McElhaney wrote:
                        > > You got me, Sean. I haven't written any custom lexicons in FB4. I
                        > > couldn't find any documention on the subject, and what knowledge I
                        > > have was obtained from reading the source code.
                        >
                        > Yeah, and that's really, really hard to follow as far as custom verbs
                        > are concerned... :(

                        Dude, you need to come look at some of the code I have to deal with every day.

                        Thanks for the examples. They look pretty much the way I expected them
                        to look. In fact, I'm even more convinced that the cfmodule approach
                        would make writing custom lexicons easier. I'll send you some
                        cfmodulized versions of John's lexicons once I obtain his permission.

                        In the mean time, you can do it yourself.

                        1. Open the file in a text editor.
                        2. Replace "fb_.verbInfo.attributes.mode" with "thisTag.executionMode"
                        3. Replace "fb_.verbinfo.attributes" with "attributes"
                        4. Replace "fb_." with "" (or "variables." if you're paranoid)
                        5. Replace "fb_" with "caller.fb_"

                        Patrick

                        --
                        Patrick McElhaney
                        704.560.9117
                        http://pmcelhaney.weblogs.us
                      • John Quarto-vonTivadar
                        If the custom lexicon remains declarative in fusebox.xml, then it would be better to just insert the namespace declaration as you describe for all such
                        Message 11 of 14 , Feb 2, 2006
                        • 0 Attachment
                          If the custom lexicon remains declarative in fusebox.xml, then it would be
                          better to just "insert" the namespace declaration as you describe for all
                          such lexicons defined, in addition to any circuit-specific namespace
                          declarations. That way, rather than "if you insert even one, then all the
                          general ones are ignored and you must insert them all by hand" you instead
                          get "all the general ones are inserted and always available and any
                          circuit-specific ones you include are added too".



                          -----Original Message-----
                          From: fusebox5@yahoogroups.com [mailto:fusebox5@yahoogroups.com] On Behalf
                          Of Sean Corfield
                          Sent: Wednesday, February 01, 2006 11:43 PM
                          To: fusebox5@yahoogroups.com
                          Subject: Re: [fusebox5] Nesting custom lexicon verbs

                          On Feb 1, 2006, at 6:53 PM, Patrick McElhaney wrote:
                          > Maybe you can kill two birds with one stone.
                          >
                          > <barney.tag> -- works the old, unofficial FB 4.1 way <barney:tag> --
                          > works the new, official FB5 way
                          >
                          > Then you could deprecate the old way.

                          You must have been eavesdropping on the conversation Barney and I were
                          having in IM today... or maybe you are Barney in disguise?

                          Barney and I settled on pretty much that in IM and I implemented it in my
                          prototype compiler to test it out.

                          fusebox.xml:

                          <lexicons>
                          <lexicon name="barney" path="barneys/tags/" /> </lexicons>

                          circuit.xml:

                          <barney.oldtag/> - executes just once, never has a parent, ignores its body

                          <barney:newtag/> - executes twice (executionMode = "start" then
                          executionMode = "end")

                          <barney:newtag> - executes with executionMode = "start"
                          <set name="foo" value="42" /> - compiles this </barney:newtag> -
                          executes with executionMode = "end"

                          <barney:newtag>
                          <barney:nested/> - executes twice but has parent = barney:tag
                          </barney:newtag>

                          It would mean that a FB41 custom verb couldn't be used directly with the new
                          syntax without a slight modification, wrapping the code in the following:

                          <cfif not structKeyExists(fb_.verbInfo,"executionMode") or
                          fb_.verbInfo.executionMode is "start">
                          ... body of custom verb ...
                          </cfif>

                          Note that an old style invocation never has a parent so with the
                          following:

                          <barney:newtag>
                          <barney.oldtag/> - executes ONCE but has NO parent </barney:newtag>

                          Another consideration is that <prefix:verb/> relies on XML namespaces
                          - you can't parse such a file without an XML namespace declaration.
                          Fortunately, the core files can automagically handle that for you, rewriting
                          the <circuit> tag internally as this:

                          <circuit xmlns:barney="file:lexicon/barneys/tags/">

                          Of course, you can specify this manually as well if you want to use XML
                          editors that can validate your custom verbs (which you cannot do with FB41
                          custom verbs). If you specify it manually, the core files would use your
                          namespace declaration instead.

                          Sean A Corfield
                          An Architect's View -- http://corfield.org/

                          "I have always wished that my computer would be as easy to use as my
                          telephone. My wish has come true - I no longer know how to use my
                          telephone."
                          -- Bjarne Stroustrup





                          Yahoo! Groups Links
                        • Sean Corfield
                          ... Well, you can t insert a declaration for foo if the circuit already defines one. I was proposing inserting all of the lexicons anyway - except for those
                          Message 12 of 14 , Feb 2, 2006
                          • 0 Attachment
                            On Feb 2, 2006, at 8:13 AM, John Quarto-vonTivadar wrote:
                            If the custom lexicon remains declarative in fusebox.xml, then it would be
                            better to just "insert" the namespace declaration as you describe for all
                            such lexicons defined, in addition to any circuit-specific namespace
                            declarations.

                            Well, you can't insert a declaration for foo if the circuit already defines one. I was proposing inserting all of the lexicons anyway - except for those that are already declared in <circuit>.

                            In other words, if you declare lexicons foo, bar and john in fusebox.xml and then in your circuit.xml you declare bar, the core files would still insert foo and john (as well).

                            However, an off-list discussion with Patrick and Barney has suggested a better all-round alternative.

                            1. Treat <lexicons> in fusebox.xml exactly like FB41 does (backward-compatibility).

                            2. For new style 'lexicons', declare them as namespaces inside the circuits that use them, e.g.,

                            <circuit xmlns:barney="barneys/tags/">

                            This would allow <barney:tag/> anywhere in that circuit and look in {approot}/lexicons/barneys/tags/ for the tag.cfm verb implementation.

                            Benefit: this would allow a circuit to be simply "dropped in" to an application (and any necessary custom verbs copied to the appropriate lexicons/ sub-directory) even if the prefix used in that circuit clashes with the prefix used in another circuit.

                            Here's what Patrick had to say that convinced me this would be a better idea (with a few details changed - highlighted):

                            "Imagine if  John Beynon created a useful circuit that depends on his
                            <john:lock/> custom tag. No problem, you say! Just copy the
                            org/beynon/john/ directory to your app's lexicon directory. It's circuit.xml has:

                            <circuit xmlns:john="org/beynon/john/" />

                            But now, suppose I get another circuit from John QvT that depends on
                            his own set of custom tags, including <john:q-tip-collection/> and
                            <john:q-tip/>? No problem, you say! Just copy the
                            com/techspedition/johnq/ directory to your app's lexicon directory. It's circuit.xml has:

                            <circuit xmlns:john="com/techspedition/johnq/" />"

                            In other words, move the "lexicon" declaration out of fusebox.xml and into the circuit(s) that use it...

                            Thoughts?

                            Sean A Corfield
                            An Architect's View -- http://corfield.org/

                            "I have always wished that my computer would be as easy to use as my telephone. My wish has come true - I no longer know how to use my telephone."
                            -- Bjarne Stroustrup


                          Your message has been successfully submitted and would be delivered to recipients shortly.