webmacro-devel — Discuss development issues related to the core of WebMacro

[Webmacro-devel] RE: Passing a block to a macro?

[<kea...@na...>]

Dario,

I'm not the macro expert, so someone else should probably chime in.  I'm
pretty sure you only need to declare your macro once per context (i.e.,
request).  Using an #include is probably the preferred way. There has been
discussion of implementing global macros, but this is still in the
discussion stage.  

You are correct that you cannot directly use a block as an argument to a
macro call.  (Your #setblock work-around is right on.)  You might want to
consider changing your macro to a directive, which would allow you to use a
block.  E.g.,

#xsltranform stylesheet="/myFile.xsl" {
    <xmltag name="hello" value="$myvar"/>
}

This could make a pretty cool addition to WM.  Directives aren't really too
hard to create.  See http://www.webmacro.org/PluggableDirectiveMechanism and
look at the source for some simple directives.

Hope this helps.

Keats


-----Original Message-----
From: Dario Liberman [mailto:lib...@in...]
Sent: Wednesday, March 05, 2003 2:26 PM
To: kea...@na...; web...@li...
Subject: Re: [Webmacro-devel] special characters - now slash directory
separator problem


Keats, Thank you very very much.

By the way... I am using macros now :-)

I am supposed to include the macro file in all my files???
Also, including it in the main wm, does not heredate it to its internal
included files. So it seems that not only the main wms, but really all wms
need the macro include statement, right?

It would be nice to have it included in my configuration file or something
for global access.

Also, is there any way to make a macro with body?

by now, instead of for example doing:

#ApplyXSL ("http://myfile.xsl") {
    <xmltag name="hello" value="$myvar"/>
}

I am doing this:

#setblock as macro $thebodyblk { 
    <xmltag name="hello" value="$myvar"/>
}
#ApplyXSL ("/myfile.xsl", $thebodyblk) 

The first sintax is much nicer I beleave. There shoud be a directive that
creates a macro with body, say.. #macrowb
the people at freemarker, I think use the word "nested" to refer to the
bodyblock during the macro definition.


When I finish this ApplyXSL tool (I hope to have the time to do it), I will
expose it to the list, maybe someone likes it.

Cheers,
Dario.

Re: [Webmacro-devel] special characters - now slash directory separator problem

[Dario L. <lib...@in...>]

RE: [Webmacro-devel] special characters - now slash directory separator =
problemKeats, Thank you very very much.

By the way... I am using macros now :-)

I am supposed to include the macro file in all my files???
Also, including it in the main wm, does not heredate it to its internal =
included files. So it seems that not only the main wms, but really all =
wms need the macro include statement, right?

It would be nice to have it included in my configuration file or =
something for global access.

Also, is there any way to make a macro with body?

by now, instead of for example doing:

#ApplyXSL ("http://myfile.xsl") {
    <xmltag name=3D"hello" value=3D"$myvar"/>
}

I am doing this:

#setblock as macro $thebodyblk {=20
    <xmltag name=3D"hello" value=3D"$myvar"/>
}
#ApplyXSL ("/myfile.xsl", $thebodyblk)=20

The first sintax is much nicer I beleave. There shoud be a directive =
that creates a macro with body, say.. #macrowb
the people at freemarker, I think use the word "nested" to refer to the =
bodyblock during the macro definition.


When I finish this ApplyXSL tool (I hope to have the time to do it), I =
will expose it to the list, maybe someone likes it.

Cheers,
Dario.

RE: [Webmacro-devel] special characters - now slash directory sep arator problem

[<kea...@na...>]

Error handling is now configurable by setting the EvaluationExceptionHandler
implementation in the WebMacro.properties.  The default is:

ExceptionHandler: org.webmacro.engine.DefaultEvaluationExceptionHandler

other options are the CrankyEvaluationExceptionHandler and the
DebugEvaluationExceptionHandler.  Or you can easily create your own.  See
http://www.webmacro.org/EvaluationExceptionHandler for more info.

The DefaultEEH is actually pretty lenient, and should behave pretty much
like the old WM.  One area where things are more strict is with parsing
exceptions.  This may be what you are seeing.  I think you pretty much have
to fix these.  Most other errors can be suppressed by the EEH.

There is an Ant task that included in the distro to help find compile time
errors in your templates.  It's called org.webmacro.tools.WMTemplateAntTask.
See:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/web
macro/tools/WMTemplateAntTask.java?rev=1.4&content-type=text/vnd.viewcvs-mar
kup

Good luck.

Keats

-----Original Message-----
From: Dario Liberman [mailto:lib...@in...]
Sent: Tuesday, March 04, 2003 3:53 PM
To: kea...@na...; web...@li...
Subject: Re: [Webmacro-devel] special characters - now slash directory
separator problem


Keats , thank you a lot for your help. the special characters work fine now.
as of point 2), "session is invalid"... I managed to overcome it by asking
the WebContext the HttpServletRequest, and then asking it the session
instead of taking it directly. It seems to be working now. I guess that the
WebContext beheaves differently, or something, perhaps it does not create a
new one if there isnt one.

The only problem I am facing now, is the error handling.
Before, there was a silent <!-- error description --> pattern.
Now I get the whole page thown away and instead I get an error page. even
with simple errors.
I know I should correct them, but I would like them to behave quietly, and
also get them appended in a log file.

Is it posible?


    
----- Original Message ----- 
From: kea...@na... 
To: lib...@in... ; web...@li... 
Cc: ar...@ci... 
Sent: Tuesday, March 04, 2003 13:59
Subject: RE: [Webmacro-devel] special characters


Dario, 
Finally getting around to upgrading, huh?  I can barely remember back that
far but I think I may be able to help you out.
1) WM now uses UTF-8 as its default input file encoding.  This was a
controversial decision, since most Westerners use ISO8859_1 (aka Latin-1).
Most likely your files are stored using Latin-1, so you should set the
TemplateEncoding in your WebMacro.properties:
TemplateEncoding: ISO8859_1 
Alternatively you could set this as a parameter in your templates: 
#param $TemplateEncoding="ISO8859_1" 
2) I'm not sure about this one, but I'm guessing that your $Session tool is
not getting loaded properly.  Crank your logging up do DEBUG and check your
log to see if this is the case.  Usually these kinds of problems are due to
old WebMacro.properties files.  Most of the settings have been moved into
the jar file now (in WebMacro.defaults) so you should need few if any
settings in the properties file.
Hope this helps. 
Keats 
> Hello, 
> 
> I am moving from a previous webmacro version. One that had the sintax 
> "implements Handler" instead of the new "extends WMServlet". 
> I moved to jsdk1.3 and changed the class name from 
> "org.webmacro.servlet.Reactor" to my servlet name in the 
> servlets definition 
> of my Jrun 3.1 
> 
> And I am having 2 problems now that do not let me make the full move: 
> 
> 1) acentuated characters seem to make the parser crash: 
> -- secondary stack trace -- 
> sun.io.MalformedInputException 
>         at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152) 
>         at 
> java.io.InputStreamReader.convertInto(InputStreamReader.java:137) 
>         at java.io.InputStreamReader.fill(InputStreamReader.java:186) 
>         at java.io.InputStreamReader.read(InputStreamReader.java:249) 
>         at java.io.BufferedReader.fill(BufferedReader.java:139) 
>         at java.io.BufferedReader.read1(BufferedReader.java:187) 
>         at java.io.BufferedReader.read(BufferedReader.java:261) 
>         at 
> org.webmacro.parser.BackupCharStream.FillBuff(BackupCharStream 
> .java:95) 
> 
> Here is somebody with a similar problem, but I havent found 
> there any answer 
> to the problem. 
> http://spitfire.velocet.net/pipermail/webmacro/2001-April/005210.html 
> 
> 2) I get a "session is invalid" exception whenever I want to use the 
> httpsession, a code that run for years with no problem with 
> the previous 
> webmacro. 
> Does anybody have a clue to what this may be? 
> 
> The stack trace: 
> 
> :Exception!!! 
> java.lang.IllegalStateException: Session is invalid 
>         at 
> allaire.jrun.session.JRunSession.checkSessionValidity(../sessi 
> on/JRunSession 
> .java:318) 
>         at 
> allaire.jrun.session.JRunSession.removeValue(../session/JRunSe 
> ssion.java:251 
> ) 
>         at 
> com.ineba_servletframework.CServletApp.handle(CServletApp.java:543) 
>         at 
> org.webmacro.servlet.WMServlet.doRequest(WMServlet.java:255) 
> 
> 
> The code is: 
> 
>             // Get the user session if it exists. If it doesn't, this 
> creates a new one. 
>             HttpSession session = c.getSession(); 
> 
>             // if the "userinfo" key exits, that means the 
> user should be 
> logged 
>             CUserDataInSession userdata = 
> (CUserDataInSession)retValues.get("userinfo"); 
>             if(userdata != null) { 
> 
> session.putValue(getSessionPrefix()+CUserDataInSession.ID_STRI 
> NG, userdata); 
>             }else { 
>                 // Ensure the user is not logged 
>                 // NOTE: We do NOT detroy the session. 
> Instead, we remove 
> the CUserDataInSession object 
>                 //       from the session. 
> 
> session.removeValue(getSessionPrefix()+CUserDataInSession.ID_STRING); 
>             } 
>             if(session.isNew()) { 
>                 int maxInactiveInterval = 
> CUtils.parseInt(getProperty("user.sessionMaxInactiveInterval") 
> ,600000); 
>                 session.setMaxInactiveInterval(maxInactiveInterval); 
>             } 
> 
> 
> 
> Please Help!!! 
> 
> Best regards, 
> Dario Liberman. 
> 

Re: [Webmacro-devel] special characters - now slash directory separator problem

[Dario L. <lib...@in...>]

RE: [Webmacro-devel] special charactersKeats , thank you a lot for your =
help. the special characters work fine now.

as of point 2), "session is invalid"... I managed to overcome it by =
asking the WebContext the HttpServletRequest, and then asking it the =
session instead of taking it directly. It seems to be working now. I =
guess that the WebContext beheaves differently, or something, perhaps it =
does not create a new one if there isnt one.

The only problem I am facing now, is the error handling.
Before, there was a silent <!-- error description --> pattern.
Now I get the whole page thown away and instead I get an error page. =
even with simple errors.
I know I should correct them, but I would like them to behave quietly, =
and also get them appended in a log file.

Is it posible?


   =20
  ----- Original Message -----=20
  From: kea...@na...=20
  To: lib...@in... ; web...@li...=20
  Cc: ar...@ci...=20
  Sent: Tuesday, March 04, 2003 13:59
  Subject: RE: [Webmacro-devel] special characters


  Dario,=20

  Finally getting around to upgrading, huh?  I can barely remember back =
that far but I think I may be able to help you out.

  1) WM now uses UTF-8 as its default input file encoding.  This was a =
controversial decision, since most Westerners use ISO8859_1 (aka =
Latin-1).  Most likely your files are stored using Latin-1, so you =
should set the TemplateEncoding in your WebMacro.properties:

  TemplateEncoding: ISO8859_1=20

  Alternatively you could set this as a parameter in your templates:=20

  #param $TemplateEncoding=3D"ISO8859_1"=20

  2) I'm not sure about this one, but I'm guessing that your $Session =
tool is not getting loaded properly.  Crank your logging up do DEBUG and =
check your log to see if this is the case.  Usually these kinds of =
problems are due to old WebMacro.properties files.  Most of the settings =
have been moved into the jar file now (in WebMacro.defaults) so you =
should need few if any settings in the properties file.

  Hope this helps.=20

  Keats=20

  > Hello,=20
  >=20
  > I am moving from a previous webmacro version. One that had the =
sintax=20
  > "implements Handler" instead of the new "extends WMServlet".=20
  > I moved to jsdk1.3 and changed the class name from=20
  > "org.webmacro.servlet.Reactor" to my servlet name in the=20
  > servlets definition=20
  > of my Jrun 3.1=20
  >=20
  > And I am having 2 problems now that do not let me make the full =
move:=20
  >=20
  > 1) acentuated characters seem to make the parser crash:=20
  > -- secondary stack trace --=20
  > sun.io.MalformedInputException=20
  >         at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)=20
  >         at=20
  > java.io.InputStreamReader.convertInto(InputStreamReader.java:137)=20
  >         at =
java.io.InputStreamReader.fill(InputStreamReader.java:186)=20
  >         at =
java.io.InputStreamReader.read(InputStreamReader.java:249)=20
  >         at java.io.BufferedReader.fill(BufferedReader.java:139)=20
  >         at java.io.BufferedReader.read1(BufferedReader.java:187)=20
  >         at java.io.BufferedReader.read(BufferedReader.java:261)=20
  >         at=20
  > org.webmacro.parser.BackupCharStream.FillBuff(BackupCharStream=20
  > .java:95)=20
  >=20
  > Here is somebody with a similar problem, but I havent found=20
  > there any answer=20
  > to the problem.=20
  > =
http://spitfire.velocet.net/pipermail/webmacro/2001-April/005210.html=20
  >=20
  > 2) I get a "session is invalid" exception whenever I want to use the =

  > httpsession, a code that run for years with no problem with=20
  > the previous=20
  > webmacro.=20
  > Does anybody have a clue to what this may be?=20
  >=20
  > The stack trace:=20
  >=20
  > :Exception!!!=20
  > java.lang.IllegalStateException: Session is invalid=20
  >         at=20
  > allaire.jrun.session.JRunSession.checkSessionValidity(../sessi=20
  > on/JRunSession=20
  > .java:318)=20
  >         at=20
  > allaire.jrun.session.JRunSession.removeValue(../session/JRunSe=20
  > ssion.java:251=20
  > )=20
  >         at=20
  > com.ineba_servletframework.CServletApp.handle(CServletApp.java:543)=20
  >         at=20
  > org.webmacro.servlet.WMServlet.doRequest(WMServlet.java:255)=20
  >=20
  >=20
  > The code is:=20
  >=20
  >             // Get the user session if it exists. If it doesn't, =
this=20
  > creates a new one.=20
  >             HttpSession session =3D c.getSession();=20
  >=20
  >             // if the "userinfo" key exits, that means the=20
  > user should be=20
  > logged=20
  >             CUserDataInSession userdata =3D=20
  > (CUserDataInSession)retValues.get("userinfo");=20
  >             if(userdata !=3D null) {=20
  >=20
  > session.putValue(getSessionPrefix()+CUserDataInSession.ID_STRI=20
  > NG, userdata);=20
  >             }else {=20
  >                 // Ensure the user is not logged=20
  >                 // NOTE: We do NOT detroy the session.=20
  > Instead, we remove=20
  > the CUserDataInSession object=20
  >                 //       from the session.=20
  >=20
  > =
session.removeValue(getSessionPrefix()+CUserDataInSession.ID_STRING);=20
  >             }=20
  >             if(session.isNew()) {=20
  >                 int maxInactiveInterval =3D=20
  > CUtils.parseInt(getProperty("user.sessionMaxInactiveInterval")=20
  > ,600000);=20
  >                 session.setMaxInactiveInterval(maxInactiveInterval); =

  >             }=20
  >=20
  >=20
  >=20
  > Please Help!!!=20
  >=20
  > Best regards,=20
  > Dario Liberman.=20
  >=20

RE: [Webmacro-devel] special characters

[<kea...@na...>]

Dario,

Finally getting around to upgrading, huh?  I can barely remember back that
far but I think I may be able to help you out.

1) WM now uses UTF-8 as its default input file encoding.  This was a
controversial decision, since most Westerners use ISO8859_1 (aka Latin-1).
Most likely your files are stored using Latin-1, so you should set the
TemplateEncoding in your WebMacro.properties:

TemplateEncoding: ISO8859_1

Alternatively you could set this as a parameter in your templates:

#param $TemplateEncoding="ISO8859_1"

2) I'm not sure about this one, but I'm guessing that your $Session tool is
not getting loaded properly.  Crank your logging up do DEBUG and check your
log to see if this is the case.  Usually these kinds of problems are due to
old WebMacro.properties files.  Most of the settings have been moved into
the jar file now (in WebMacro.defaults) so you should need few if any
settings in the properties file.

Hope this helps.

Keats

> Hello,
> 
> I am moving from a previous webmacro version. One that had the sintax
> "implements Handler" instead of the new "extends WMServlet".
> I moved to jsdk1.3 and changed the class name from
> "org.webmacro.servlet.Reactor" to my servlet name in the 
> servlets definition
> of my Jrun 3.1
> 
> And I am having 2 problems now that do not let me make the full move:
> 
> 1) acentuated characters seem to make the parser crash:
> -- secondary stack trace --
> sun.io.MalformedInputException
>         at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)
>         at 
> java.io.InputStreamReader.convertInto(InputStreamReader.java:137)
>         at java.io.InputStreamReader.fill(InputStreamReader.java:186)
>         at java.io.InputStreamReader.read(InputStreamReader.java:249)
>         at java.io.BufferedReader.fill(BufferedReader.java:139)
>         at java.io.BufferedReader.read1(BufferedReader.java:187)
>         at java.io.BufferedReader.read(BufferedReader.java:261)
>         at
> org.webmacro.parser.BackupCharStream.FillBuff(BackupCharStream
> .java:95)
> 
> Here is somebody with a similar problem, but I havent found 
> there any answer
> to the problem.
> http://spitfire.velocet.net/pipermail/webmacro/2001-April/005210.html
> 
> 2) I get a "session is invalid" exception whenever I want to use the
> httpsession, a code that run for years with no problem with 
> the previous
> webmacro.
> Does anybody have a clue to what this may be?
> 
> The stack trace:
> 
> :Exception!!!
> java.lang.IllegalStateException: Session is invalid
>         at
> allaire.jrun.session.JRunSession.checkSessionValidity(../sessi
> on/JRunSession
> .java:318)
>         at
> allaire.jrun.session.JRunSession.removeValue(../session/JRunSe
> ssion.java:251
> )
>         at
> com.ineba_servletframework.CServletApp.handle(CServletApp.java:543)
>         at 
> org.webmacro.servlet.WMServlet.doRequest(WMServlet.java:255)
> 
> 
> The code is:
> 
>             // Get the user session if it exists. If it doesn't, this
> creates a new one.
>             HttpSession session = c.getSession();
> 
>             // if the "userinfo" key exits, that means the 
> user should be
> logged
>             CUserDataInSession userdata =
> (CUserDataInSession)retValues.get("userinfo");
>             if(userdata != null) {
> 
> session.putValue(getSessionPrefix()+CUserDataInSession.ID_STRI
> NG, userdata);
>             }else {
>                 // Ensure the user is not logged
>                 // NOTE: We do NOT detroy the session. 
> Instead, we remove
> the CUserDataInSession object
>                 //       from the session.
> 
> session.removeValue(getSessionPrefix()+CUserDataInSession.ID_STRING);
>             }
>             if(session.isNew()) {
>                 int maxInactiveInterval =
> CUtils.parseInt(getProperty("user.sessionMaxInactiveInterval")
> ,600000);
>                 session.setMaxInactiveInterval(maxInactiveInterval);
>             }
> 
> 
> 
> Please Help!!!
> 
> Best regards,
> Dario Liberman.
> 

[Webmacro-devel] special characters

[Dario L. <lib...@in...>]

Hello,

I am moving from a previous webmacro version. One that had the sintax
"implements Handler" instead of the new "extends WMServlet".
I moved to jsdk1.3 and changed the class name from
"org.webmacro.servlet.Reactor" to my servlet name in the servlets definition
of my Jrun 3.1

And I am having 2 problems now that do not let me make the full move:

1) acentuated characters seem to make the parser crash:
-- secondary stack trace --
sun.io.MalformedInputException
        at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)
        at java.io.InputStreamReader.convertInto(InputStreamReader.java:137)
        at java.io.InputStreamReader.fill(InputStreamReader.java:186)
        at java.io.InputStreamReader.read(InputStreamReader.java:249)
        at java.io.BufferedReader.fill(BufferedReader.java:139)
        at java.io.BufferedReader.read1(BufferedReader.java:187)
        at java.io.BufferedReader.read(BufferedReader.java:261)
        at
org.webmacro.parser.BackupCharStream.FillBuff(BackupCharStream.java:95)

Here is somebody with a similar problem, but I havent found there any answer
to the problem.
http://spitfire.velocet.net/pipermail/webmacro/2001-April/005210.html

2) I get a "session is invalid" exception whenever I want to use the
httpsession, a code that run for years with no problem with the previous
webmacro.
Does anybody have a clue to what this may be?

The stack trace:

:Exception!!!
java.lang.IllegalStateException: Session is invalid
        at
allaire.jrun.session.JRunSession.checkSessionValidity(../session/JRunSession
.java:318)
        at
allaire.jrun.session.JRunSession.removeValue(../session/JRunSession.java:251
)
        at
com.ineba_servletframework.CServletApp.handle(CServletApp.java:543)
        at org.webmacro.servlet.WMServlet.doRequest(WMServlet.java:255)


The code is:

            // Get the user session if it exists. If it doesn't, this
creates a new one.
            HttpSession session = c.getSession();

            // if the "userinfo" key exits, that means the user should be
logged
            CUserDataInSession userdata =
(CUserDataInSession)retValues.get("userinfo");
            if(userdata != null) {

session.putValue(getSessionPrefix()+CUserDataInSession.ID_STRING, userdata);
            }else {
                // Ensure the user is not logged
                // NOTE: We do NOT detroy the session. Instead, we remove
the CUserDataInSession object
                //       from the session.

session.removeValue(getSessionPrefix()+CUserDataInSession.ID_STRING);
            }
            if(session.isNew()) {
                int maxInactiveInterval =
CUtils.parseInt(getProperty("user.sessionMaxInactiveInterval"),600000);
                session.setMaxInactiveInterval(maxInactiveInterval);
            }



Please Help!!!

Best regards,
Dario Liberman.

RE: [Webmacro-devel] Webmacro and Resin - upgrade issues

[<kea...@na...>]

Jason,

All the classes listed below have been either moved or removed from WM long
ago.  This most likely means that your application is picking up and old
version of the WebMacro.properties file.  Check your classpath and blow away
any old copies of this file.  

Good luck.

Keats

> -----Original Message-----
> From: Jason Chodakowski [mailto:ja...@hy...]
> Sent: Thursday, February 27, 2003 3:07 PM
> To: web...@li...
> Subject: [Webmacro-devel] Webmacro and Resin - upgrade issues
> 
> 
> After some minor changes, it would seem I've gotten my upgrade working
> pretty tidy, but...
> 
> It would seem I'm throwing all kinds of class loader 
> exceptions at runtime.
> Here are a few -
> 
> 11:56:05 AM	broker	ERROR	Provider 
> (org.webmacro.resource.HandlerProvider)
> failed to load
> java.lang.ClassNotFoundException: 
> org.webmacro.resource.HandlerProvider
> 
> 11:56:05 AM	broker	ERROR	Provider 
> (org.webmacro.engine.DirectiveProvider)
> failed to load
> java.lang.ClassNotFoundException: 
> org.webmacro.engine.DirectiveProvider
> 
> 11:56:05 AM	engine	ERROR	Could not load parser: 
> org.webmacro.engine.WMParser
> org.webmacro.engine.IntrospectionException: No class
> org.webmacro.engine.WMParser
> 
> 11:56:05 AM	directive	WARNING	Exception loading directive
> org.webmacro.engine.IncludeDirective
> org.webmacro.engine.IntrospectionException: No class
> org.webmacro.engine.IncludeDirective
> java.lang.ClassNotFoundException: org.webmacro.engine.IncludeDirective
> 
> 
> The list goes on and on... all this from a call to new.WM()
> 
> Does anyone have any experience with this, or seen something 
> similar before?
> 
> Thanks.
> 
> J --
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 

[Webmacro-devel] Webmacro and Resin - upgrade issues

[Jason C. <ja...@hy...>]

After some minor changes, it would seem I've gotten my upgrade working
pretty tidy, but...

It would seem I'm throwing all kinds of class loader exceptions at runtime.
Here are a few -

11:56:05 AM	broker	ERROR	Provider (org.webmacro.resource.HandlerProvider)
failed to load
java.lang.ClassNotFoundException: org.webmacro.resource.HandlerProvider

11:56:05 AM	broker	ERROR	Provider (org.webmacro.engine.DirectiveProvider)
failed to load
java.lang.ClassNotFoundException: org.webmacro.engine.DirectiveProvider

11:56:05 AM	engine	ERROR	Could not load parser: org.webmacro.engine.WMParser
org.webmacro.engine.IntrospectionException: No class
org.webmacro.engine.WMParser

11:56:05 AM	directive	WARNING	Exception loading directive
org.webmacro.engine.IncludeDirective
org.webmacro.engine.IntrospectionException: No class
org.webmacro.engine.IncludeDirective
java.lang.ClassNotFoundException: org.webmacro.engine.IncludeDirective


The list goes on and on... all this from a call to new.WM()

Does anyone have any experience with this, or seen something similar before?

Thanks.

J --

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

or
#macro.MacroName(arglist)
just a thought.

macros are not in widespread adoption. It would impact me probably the 
most. I can live with what we decide is the cleanest solution.

Personally, I would rather not fool with macro invocation syntax and 
just allow an unknown directive to pass through when strict type 
checking is off.

-Lane

kea...@na... wrote:

> It occurs to me that the white space issue may not be a big deal, 
> since the whole unknown directive handling problem is mainly just an 
> issue for HTML generation (DreamWeaver, et al), where white space 
> isn't significant.  Ergo, my initial suggestion may not be too 
> terrible, ie, just dump the directive name and arg list out (and don't 
> worry about lost white space).
>
> Another approach, which would be cleaner but not backwards-compatable, 
> would be to change the syntax for macro invocation.  For example, if 
> macros calls started with #$macroname or, Velocity-like: #(macroname), 
> the parser could determine what is a valid directive and could decide 
> what to do about other things that look like directives at parse time.
>
> Keats
>
>  
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

It occurs to me that the white space issue may not be a big deal, since the
whole unknown directive handling problem is mainly just an issue for HTML
generation (DreamWeaver, et al), where white space isn't significant.  Ergo,
my initial suggestion may not be too terrible, ie, just dump the directive
name and arg list out (and don't worry about lost white space).

Another approach, which would be cleaner but not backwards-compatable, would
be to change the syntax for macro invocation.  For example, if macros calls
started with #$macroname or, Velocity-like: #(macroname), the parser could
determine what is a valid directive and could decide what to do about other
things that look like directives at parse time.

Keats

 

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

macro invocations do not have blocks. The macro name cannot have 
embedded <WS>.

calling: #ccBasicTransaction( $Tran, $App )

results in:

calling:<FORM ACTION="https:....

note: the <WS> before the #ccBasicTransaction() is now eaten.

-Lane

kea...@na... wrote:

> So I guess a MacroBuilder needs to have enough information to 
> reconstitute the original text.  (This is similar to the issue of 
> reconstructing shredded XML documents from a database.)  This means 
> we'd have to save references to all the <WS> or just the entire 
> unparsed text.  Fortunately macro calls can't have blocks (right?) so 
> it shouldn't be too horrible -- just one line of text plus preceding 
> <WS> I think.  But it's still a parser hack.
>
> Keats
>
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Wednesday, February 12, 2003 5:40 PM
> > To: kea...@na...
> > Cc: la...@op...; br...@qu...; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > On Wednesday, February 12, 2003, at 05:35  PM,
> > kea...@na... wrote:
> >
> > > This is where we enter the world of javacc which is terra
> > incognito to
> > > me, but AFAICT we'd need to make a "lookahead production" that
> > > determines if something is indeed a directive/macro and
> > then push it
> > > back on the stream if it isn't.  Along the way the EEH could decide
> > > whether to spew, or let this stand as text.
> >
> > Problem is, this is a "buildtime" problem, not a "parsetime" problem.
> >
> > Because of the #macro business, unknown directives can't be
> > determined
> > until after everything has been parsed.
> >
> > eric
> >
> > >
> > > Any idea how to do this?
> > >
> > > Keats
> > >
> > > > -----Original Message-----
> > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > Sent: Wednesday, February 12, 2003 5:29 PM
> > > > To: kea...@na...
> > > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > > web...@li...
> > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > >
> > > >
> > > > On Wednesday, February 12, 2003, at 05:26  PM,
> > > > kea...@na... wrote:
> > > >
> > > > > I guess I was a bit hasty in my post ... it appears the
> > solution is
> > > > > not quite as trivial as I had thought.  The problem is how
> > > > to recreate
> > > > > the original template text after it has already been
> > > > parsed, with all
> > > > > the proper whitespace, etc.  This seems like a parser hack,
> > > > i.e., if
> > > > > the MacroBuilder spews a NoSuchDirectiveException, then
> > the parser
> > > > > needs to push back all the whitespace and the # directive name. 
> > > > >
> > > > > Bleck!
> > > >
> > > > eww, I didn't even consider the <WS> eating.  Bleck! is right.
> > > >
> > > > Now what?
> > > >
> > > > eric
> > > >
> > > > >
> > > > > Keats
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Keats Kirsch
> > > > > > Sent: Wednesday, February 12, 2003 5:10 PM
> > > > > > To: 'Eric B. Ridge'; Keats Kirsch
> > > > > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > > > > web...@li...
> > > > > > Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > >
> > > > > >
> > > > > > You're right, I was mislead by some apparently dead code in
> > > > > > the parser:
> > > > > >
> > > > > >     throw new ParseException("No such directive #" +
> > directive);
> > > > > >
> > > > > > Apparently, this now gets handled by the
> > > > > > MacroBuilder.build(), which throws:
> > > > > >
> > > > > >          throw new BuildException ("#" + name + ": no such
> > > > > > Macro or Directive");
> > > > > >  
> > > > > > This should make things much simpler.
> > > > > >
> > > > > > So you could just say:
> > > > > >
> > > > > >          
> > bc.getEvaluationExceptionHandler().evaluate(null, bc,
> > > > > >             new BuildException ("#" + name + ": no such Macro
> > > > > > or Directive"));
> > > > > >
> > > > > > This would actually fail with the DefaultEEH, as it currently
> > > > > > doesn't check for a null variable arg.  Easily fixed, but
> > > > > > better would be to create a new PropertyException, like
> > > > > > PropertyException.NoSuchDirectiveOrMacro and throw that.
> > > > > >
> > > > > > I could try to make these changes if you'd like.
> > > > > >
> > > > > > Keats
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > > Sent: Wednesday, February 12, 2003 4:36 PM
> > > > > > > To: kea...@na...
> > > > > > > Cc: la...@op...; br...@qu...;
> > ma...@an...;
> > > > > > > web...@li...
> > > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > > >
> > > > > > >
> > > > > > > On Wednesday, February 12, 2003, at 04:01  PM,
> > > > > > > kea...@na... wrote:
> > > > > > >
> > > > > > > > I think using the EEH would be great, but it does present
> > > some
> > > > > > > > challenges as Eric has pointed out.  The unknown directive
> > > > > > > exceptions
> > > > > > > > are thrown by the parser.  The parser does have a
> > > > > > reference to the
> > > > > > > > broker, so it should be able to get the EEH and pass
> > > > > > > exceptions back
> > > > > > > > to it.
> > > > > > >
> > > > > > > Technically, it's a BuildException, not a ParseException.
> > > > > > >
> > > > > > > >
> > > > > > > > Unfortunately the EEH interface was designed to
> > > > handle evaluation
> > > > > > > > exceptions (hence the name).  To handle parse
> > > > exceptions we would
> > > > > > > > probably want a new method in the interface (like
> > > > > > "parse()").  This
> > > > > > > > would require a change in all existing EEH
> > implementations. 
> > > > > > >  Probably
> > > > > > > > not a huge problem, but something to consider. 
> > > > > > > >
> > > > > > > > Also the name wouldn't be quite appropriate if we expand
> > > > > > > the scope of
> > > > > > > > this.  It should probably be just ExceptionHandler or
> > > > > > > > WMExceptionHandler.  Maybe an o.w.ExceptionHandler
> > > > > > interface could
> > > > > > > > extend EvaluationExceptionHandler and add the new method. 
> > > > > > > Then if you
> > > > > > > > configure an ExceptionHandler, it would automatically set
> > > > > > > the EEH as
> > > > > > > > well.  This should preserve backwards compatability.
> > > > > > >
> > > > > > > I don't think we'll need to change the interface for
> > > > EEH.  But we
> > > > > > > could/should change the name...
> > > > > > >
> > > > > > > >
> > > > > > > > In any case, someone would need to tweek the parser -- and
> > > > > > > I know of
> > > > > > > > only two candidates ...
> > > > > > >
> > > > > > > The parser won't need to be touched.  I don't believe.
> > > > > > >
> > > > > > > >
> > > > > > > > Keats
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > > > > > > To: la...@op...
> > > > > > > > > Cc: Brian Goetz; ma...@an...;
> > > > > > > > > web...@li...
> > > > > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tuesday, February 11, 2003, at 04:12  PM,
> > Lane Sharman
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > ebr:
> > > > > > > > > >
> > > > > > > > > > Can you make a stab at modifying eeh so that
> > we can try
> > > > > > > this out?
> > > > > > > > >
> > > > > > > > > I can, yes... when I find the time.
> > > > > > > > >
> > > > > > > > > The issue here is that EEH is used as a "runtime"
> > > > thing, not a
> > > > > > > > > "buildtime" thing, so I'm not sure how it will
> > > > interact with
> > > > > the
> > > > > > > > > BuildContext (if it all).
> > > > > > > > >
> > > > > > > > > Assuming I can work that out, I guess we want:
> > > > > > > > >       CrankyEEH to *always* throw on #unknown directives
> > > > > > > > >       DefaultEEH to *always* pass #unknown
> > directives to
> > > the
> > > > > > > > > stream as
> > > > > > > > > string literals
> > > > > > > > >           MarcEEH to do whatever Marc wants, to be
> > > > > > > written by him. 
> > > > > > > > :)
> > > > > > > > >
> > > > > > > > > eric
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -l
> > > > > > > > > >
> > > > > > > > > > Eric B. Ridge wrote:
> > > > > > > > > >
> > > > > > > > > >> On Tuesday, February 11, 2003, at 03:35  PM, Brian
> > > > > > Goetz wrote:
> > > > > > > > > >>
> > > > > > > > > >>>> This problem is elegantly solved thru the
> > > > introduction of
> > > > > a
> > > > > > > > > >>>> property,
> > > > > > > > > >>>> StrictDirectiveTypeChecking. Invariably,
> > there will be
> > > > > > > > > times when
> > > > > > > > > >>>> you
> > > > > > > > > >>>> cannot "include as text" a DW file because you will
> > > > > > > want to add
> > > > > > > > > >>>> some WM
> > > > > > > > > >>>> var reference to it!
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>> I'd rather see "strict directive checking"
> > > > rolled in with
> > > > > > > > > other forms
> > > > > > > > > >>> of strict checking (like the Cranky EEH),
> > rather than
> > > > > > > have seven
> > > > > > > > > >>> different
> > > > > > > > > >>> things a user would have to do to get
> > strict checking.
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> Better yet (maybe), roll this thing through EEH... if
> > > > > > > that's even
> > > > > > > > > >> possible.
> > > > > > > > > >>
> > > > > > > > > >> eric
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > -------------------------------------------------------
> > > > > > > > > >> This SF.NET email is sponsored by:
> > > > > > > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =
> > > > > > > > > Something 2 See!
> > > > > > > > > >> http://www.vasoftware.com
> > > > > > > > > >> _______________________________________________
> > > > > > > > > >> Webmacro-devel mailing list
> > > > > > > > > >> Web...@li...
> > > > > > > > > >>
> > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lane Sharman
> > > > > > > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > > > > > > Hosting Services
> > > > > > > > > > http://opendoors.com/lane.pdf BIO
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > -------------------------------------------------------
> > > > > > > > > > This SF.NET email is sponsored by:
> > > > > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =
> > > > > > Something 2
> > > > > > > > See!
> > > > > > > > > > http://www.vasoftware.com
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Webmacro-devel mailing list
> > > > > > > > > > Web...@li...
> > > > > > > > > >
> > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -------------------------------------------------------
> > > > > > > > > This SF.NET email is sponsored by:
> > > > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =
> > > > > > > Something 2 See!
> > > > > > > > > http://www.vasoftware.com
> > > > > > > > > _______________________________________________
> > > > > > > > > Webmacro-devel mailing list
> > > > > > > > > Web...@li...
> > > > > > > > >
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

So I guess a MacroBuilder needs to have enough information to =
reconstitute
the original text.  (This is similar to the issue of reconstructing =
shredded
XML documents from a database.)  This means we'd have to save =
references to
all the <WS> or just the entire unparsed text.  Fortunately macro calls
can't have blocks (right?) so it shouldn't be too horrible -- just one =
line
of text plus preceding <WS> I think.  But it's still a parser hack.

Keats

> -----Original Message-----
> From: Eric B. Ridge [mailto:eb...@tc...]
> Sent: Wednesday, February 12, 2003 5:40 PM
> To: kea...@na...
> Cc: la...@op...; br...@qu...; ma...@an...;
> web...@li...
> Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
>=20
>=20
> On Wednesday, February 12, 2003, at 05:35  PM,=20
> kea...@na... wrote:
>=20
> > This is where we enter the world of javacc which is terra=20
> incognito to=20
> > me, but AFAICT we'd need to make a "lookahead production" that=20
> > determines if something is indeed a directive/macro and=20
> then push it=20
> > back on the stream if it isn't.=A0 Along the way the EEH could =
decide=20
> > whether to spew, or let this stand as text.
>=20
> Problem is, this is a "buildtime" problem, not a "parsetime" problem.
>=20
> Because of the #macro business, unknown directives can't be=20
> determined=20
> until after everything has been parsed.
>=20
> eric
>=20
> >
> > Any idea how to do this?
> >
> > Keats
> >
> > > -----Original Message-----
> > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > Sent: Wednesday, February 12, 2003 5:29 PM
> > > To: kea...@na...
> > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > web...@li...
> > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > >
> > >
> > > On Wednesday, February 12, 2003, at 05:26=A0 PM,
> > > kea...@na... wrote:
> > >
> > > > I guess I was a bit hasty in my post ... it appears the=20
> solution is
> > > > not quite as trivial as I had thought.=A0 The problem is how
> > > to recreate
> > > > the original template text after it has already been
> > > parsed, with all
> > > > the proper whitespace, etc.=A0 This seems like a parser hack,
> > > i.e., if
> > > > the MacroBuilder spews a NoSuchDirectiveException, then=20
> the parser
> > > > needs to push back all the whitespace and the # directive =
name.=A0
> > > >
> > > > Bleck!
> > >
> > > eww, I didn't even consider the <WS> eating.=A0 Bleck! is right.
> > >
> > > Now what?
> > >
> > > eric
> > >
> > > >
> > > > Keats
> > > >
> > > > > -----Original Message-----
> > > > > From: Keats Kirsch
> > > > > Sent: Wednesday, February 12, 2003 5:10 PM
> > > > > To: 'Eric B. Ridge'; Keats Kirsch
> > > > > Cc: la...@op...; br...@qu...; =
ma...@an...;
> > > > > web...@li...
> > > > > Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
> > > > >
> > > > >
> > > > > You're right, I was mislead by some apparently dead code in
> > > > > the parser:
> > > > >
> > > > >=A0=A0=A0=A0 throw new ParseException("No such directive #" +=20
> directive);
> > > > >
> > > > > Apparently, this now gets handled by the
> > > > > MacroBuilder.build(), which throws:
> > > > >
> > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0 throw new BuildException ("#" + =
name + ": no such
> > > > > Macro or Directive");
> > > > >=A0=A0
> > > > > This should make things much simpler.
> > > > >
> > > > > So you could just say:
> > > > >
> > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
> bc.getEvaluationExceptionHandler().evaluate(null, bc,
> > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new BuildException ("#" + =
name + ": no such Macro
> > > > > or Directive"));
> > > > >
> > > > > This would actually fail with the DefaultEEH, as it currently
> > > > > doesn't check for a null variable arg.=A0 Easily fixed, but
> > > > > better would be to create a new PropertyException, like
> > > > > PropertyException.NoSuchDirectiveOrMacro and throw that.
> > > > >
> > > > > I could try to make these changes if you'd like.
> > > > >
> > > > > Keats
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > Sent: Wednesday, February 12, 2003 4:36 PM
> > > > > > To: kea...@na...
> > > > > > Cc: la...@op...; br...@qu...;=20
> ma...@an...;
> > > > > > web...@li...
> > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > >
> > > > > >
> > > > > > On Wednesday, February 12, 2003, at 04:01=A0 PM,
> > > > > > kea...@na... wrote:
> > > > > >
> > > > > > > I think using the EEH would be great, but it does present =

> > some
> > > > > > > challenges as Eric has pointed out.=A0 The unknown =
directive
> > > > > > exceptions
> > > > > > > are thrown by the parser.=A0 The parser does have a
> > > > > reference to the
> > > > > > > broker, so it should be able to get the EEH and pass
> > > > > > exceptions back
> > > > > > > to it.
> > > > > >
> > > > > > Technically, it's a BuildException, not a ParseException.
> > > > > >
> > > > > > >
> > > > > > > Unfortunately the EEH interface was designed to
> > > handle evaluation
> > > > > > > exceptions (hence the name).=A0 To handle parse
> > > exceptions we would
> > > > > > > probably want a new method in the interface (like
> > > > > "parse()").=A0 This
> > > > > > > would require a change in all existing EEH=20
> implementations.=A0
> > > > > >=A0 Probably
> > > > > > > not a huge problem, but something to consider.=A0
> > > > > > >
> > > > > > > Also the name wouldn't be quite appropriate if we expand
> > > > > > the scope of
> > > > > > > this.=A0 It should probably be just ExceptionHandler or
> > > > > > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler
> > > > > interface could
> > > > > > > extend EvaluationExceptionHandler and add the new =
method.=A0
> > > > > > Then if you
> > > > > > > configure an ExceptionHandler, it would automatically set
> > > > > > the EEH as
> > > > > > > well.=A0 This should preserve backwards compatability.
> > > > > >
> > > > > > I don't think we'll need to change the interface for
> > > EEH.=A0 But we
> > > > > > could/should change the name...
> > > > > >
> > > > > > >
> > > > > > > In any case, someone would need to tweek the parser -- =
and
> > > > > > I know of
> > > > > > > only two candidates ...
> > > > > >
> > > > > > The parser won't need to be touched.=A0 I don't believe.
> > > > > >
> > > > > > >
> > > > > > > Keats
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > > > > > To: la...@op...
> > > > > > > > Cc: Brian Goetz; ma...@an...;
> > > > > > > > web...@li...
> > > > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver =
stuff
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tuesday, February 11, 2003, at 04:12=A0 PM,=20
> Lane Sharman
> > > > wrote:
> > > > > > > >
> > > > > > > > > ebr:
> > > > > > > > >
> > > > > > > > > Can you make a stab at modifying eeh so that=20
> we can try
> > > > > > this out?
> > > > > > > >
> > > > > > > > I can, yes... when I find the time.
> > > > > > > >
> > > > > > > > The issue here is that EEH is used as a "runtime"
> > > thing, not a
> > > > > > > > "buildtime" thing, so I'm not sure how it will
> > > interact with
> > > > the
> > > > > > > > BuildContext (if it all).
> > > > > > > >
> > > > > > > > Assuming I can work that out, I guess we want:
> > > > > > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > > > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown=20
> directives to=20
> > the
> > > > > > > > stream as
> > > > > > > > string literals
> > > > > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever =
Marc wants, to be
> > > > > > written by him.=A0
> > > > > > > :)
> > > > > > > >
> > > > > > > > eric
> > > > > > > >
> > > > > > > > >
> > > > > > > > > -l
> > > > > > > > >
> > > > > > > > > Eric B. Ridge wrote:
> > > > > > > > >
> > > > > > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian
> > > > > Goetz wrote:
> > > > > > > > >>
> > > > > > > > >>>> This problem is elegantly solved thru the
> > > introduction of
> > > > a
> > > > > > > > >>>> property,
> > > > > > > > >>>> StrictDirectiveTypeChecking. Invariably,=20
> there will be
> > > > > > > > times when
> > > > > > > > >>>> you
> > > > > > > > >>>> cannot "include as text" a DW file because you =
will
> > > > > > want to add
> > > > > > > > >>>> some WM
> > > > > > > > >>>> var reference to it!
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> I'd rather see "strict directive checking"
> > > rolled in with
> > > > > > > > other forms
> > > > > > > > >>> of strict checking (like the Cranky EEH),=20
> rather than
> > > > > > have seven
> > > > > > > > >>> different
> > > > > > > > >>> things a user would have to do to get=20
> strict checking.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Better yet (maybe), roll this thing through EEH... =
if
> > > > > > that's even
> > > > > > > > >> possible.
> > > > > > > > >>
> > > > > > > > >> eric
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>=20
> -------------------------------------------------------
> > > > > > > > >> This SF.NET email is sponsored by:
> > > > > > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =
=3D
> > > > > > > > Something 2 See!
> > > > > > > > >> http://www.vasoftware.com
> > > > > > > > >> _______________________________________________
> > > > > > > > >> Webmacro-devel mailing list
> > > > > > > > >> Web...@li...
> > > > > > > > >>
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Lane Sharman
> > > > > > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > > > > > Hosting Services
> > > > > > > > > http://opendoors.com/lane.pdf BIO
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >=20
> -------------------------------------------------------
> > > > > > > > > This SF.NET email is sponsored by:
> > > > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > Something 2
> > > > > > > See!
> > > > > > > > > http://www.vasoftware.com
> > > > > > > > > _______________________________________________
> > > > > > > > > Webmacro-devel mailing list
> > > > > > > > > Web...@li...
> > > > > > > > >
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > This SF.NET email is sponsored by:
> > > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > > Something 2 See!
> > > > > > > > http://www.vasoftware.com
> > > > > > > > _______________________________________________
> > > > > > > > Webmacro-devel mailing list
> > > > > > > > Web...@li...
> > > > > > > >=20
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Eric B. R. <eb...@tc...>]

On Wednesday, February 12, 2003, at 05:35  PM,=20
kea...@na... wrote:

> This is where we enter the world of javacc which is terra incognito to=20=

> me, but AFAICT we'd need to make a "lookahead production" that=20
> determines if something is indeed a directive/macro and then push it=20=

> back on the stream if it isn't.=A0 Along the way the EEH could decide=20=

> whether to spew, or let this stand as text.

Problem is, this is a "buildtime" problem, not a "parsetime" problem.

Because of the #macro business, unknown directives can't be determined=20=

until after everything has been parsed.

eric

>
> Any idea how to do this?
>
> Keats
>
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Wednesday, February 12, 2003 5:29 PM
> > To: kea...@na...
> > Cc: la...@op...; br...@qu...; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > On Wednesday, February 12, 2003, at 05:26=A0 PM,
> > kea...@na... wrote:
> >
> > > I guess I was a bit hasty in my post ... it appears the solution =
is
> > > not quite as trivial as I had thought.=A0 The problem is how
> > to recreate
> > > the original template text after it has already been
> > parsed, with all
> > > the proper whitespace, etc.=A0 This seems like a parser hack,
> > i.e., if
> > > the MacroBuilder spews a NoSuchDirectiveException, then the parser
> > > needs to push back all the whitespace and the # directive name.=A0
> > >
> > > Bleck!
> >
> > eww, I didn't even consider the <WS> eating.=A0 Bleck! is right.
> >
> > Now what?
> >
> > eric
> >
> > >
> > > Keats
> > >
> > > > -----Original Message-----
> > > > From: Keats Kirsch
> > > > Sent: Wednesday, February 12, 2003 5:10 PM
> > > > To: 'Eric B. Ridge'; Keats Kirsch
> > > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > > web...@li...
> > > > Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
> > > >
> > > >
> > > > You're right, I was mislead by some apparently dead code in
> > > > the parser:
> > > >
> > > >=A0=A0=A0=A0 throw new ParseException("No such directive #" + =
directive);
> > > >
> > > > Apparently, this now gets handled by the
> > > > MacroBuilder.build(), which throws:
> > > >
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0 throw new BuildException ("#" + name =
+ ": no such
> > > > Macro or Directive");
> > > >=A0=A0
> > > > This should make things much simpler.
> > > >
> > > > So you could just say:
> > > >
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
bc.getEvaluationExceptionHandler().evaluate(null, bc,
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new BuildException ("#" + =
name + ": no such Macro
> > > > or Directive"));
> > > >
> > > > This would actually fail with the DefaultEEH, as it currently
> > > > doesn't check for a null variable arg.=A0 Easily fixed, but
> > > > better would be to create a new PropertyException, like
> > > > PropertyException.NoSuchDirectiveOrMacro and throw that.
> > > >
> > > > I could try to make these changes if you'd like.
> > > >
> > > > Keats
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > Sent: Wednesday, February 12, 2003 4:36 PM
> > > > > To: kea...@na...
> > > > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > > > web...@li...
> > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > >
> > > > >
> > > > > On Wednesday, February 12, 2003, at 04:01=A0 PM,
> > > > > kea...@na... wrote:
> > > > >
> > > > > > I think using the EEH would be great, but it does present=20
> some
> > > > > > challenges as Eric has pointed out.=A0 The unknown directive
> > > > > exceptions
> > > > > > are thrown by the parser.=A0 The parser does have a
> > > > reference to the
> > > > > > broker, so it should be able to get the EEH and pass
> > > > > exceptions back
> > > > > > to it.
> > > > >
> > > > > Technically, it's a BuildException, not a ParseException.
> > > > >
> > > > > >
> > > > > > Unfortunately the EEH interface was designed to
> > handle evaluation
> > > > > > exceptions (hence the name).=A0 To handle parse
> > exceptions we would
> > > > > > probably want a new method in the interface (like
> > > > "parse()").=A0 This
> > > > > > would require a change in all existing EEH implementations.=A0=

> > > > >=A0 Probably
> > > > > > not a huge problem, but something to consider.=A0
> > > > > >
> > > > > > Also the name wouldn't be quite appropriate if we expand
> > > > > the scope of
> > > > > > this.=A0 It should probably be just ExceptionHandler or
> > > > > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler
> > > > interface could
> > > > > > extend EvaluationExceptionHandler and add the new method.=A0
> > > > > Then if you
> > > > > > configure an ExceptionHandler, it would automatically set
> > > > > the EEH as
> > > > > > well.=A0 This should preserve backwards compatability.
> > > > >
> > > > > I don't think we'll need to change the interface for
> > EEH.=A0 But we
> > > > > could/should change the name...
> > > > >
> > > > > >
> > > > > > In any case, someone would need to tweek the parser -- and
> > > > > I know of
> > > > > > only two candidates ...
> > > > >
> > > > > The parser won't need to be touched.=A0 I don't believe.
> > > > >
> > > > > >
> > > > > > Keats
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > > > > To: la...@op...
> > > > > > > Cc: Brian Goetz; ma...@an...;
> > > > > > > web...@li...
> > > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > > >
> > > > > > >
> > > > > > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane =
Sharman
> > > wrote:
> > > > > > >
> > > > > > > > ebr:
> > > > > > > >
> > > > > > > > Can you make a stab at modifying eeh so that we can try
> > > > > this out?
> > > > > > >
> > > > > > > I can, yes... when I find the time.
> > > > > > >
> > > > > > > The issue here is that EEH is used as a "runtime"
> > thing, not a
> > > > > > > "buildtime" thing, so I'm not sure how it will
> > interact with
> > > the
> > > > > > > BuildContext (if it all).
> > > > > > >
> > > > > > > Assuming I can work that out, I guess we want:
> > > > > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown =
directives to=20
> the
> > > > > > > stream as
> > > > > > > string literals
> > > > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc =
wants, to be
> > > > > written by him.=A0
> > > > > > :)
> > > > > > >
> > > > > > > eric
> > > > > > >
> > > > > > > >
> > > > > > > > -l
> > > > > > > >
> > > > > > > > Eric B. Ridge wrote:
> > > > > > > >
> > > > > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian
> > > > Goetz wrote:
> > > > > > > >>
> > > > > > > >>>> This problem is elegantly solved thru the
> > introduction of
> > > a
> > > > > > > >>>> property,
> > > > > > > >>>> StrictDirectiveTypeChecking. Invariably, there will =
be
> > > > > > > times when
> > > > > > > >>>> you
> > > > > > > >>>> cannot "include as text" a DW file because you will
> > > > > want to add
> > > > > > > >>>> some WM
> > > > > > > >>>> var reference to it!
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> I'd rather see "strict directive checking"
> > rolled in with
> > > > > > > other forms
> > > > > > > >>> of strict checking (like the Cranky EEH), rather than
> > > > > have seven
> > > > > > > >>> different
> > > > > > > >>> things a user would have to do to get strict checking.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Better yet (maybe), roll this thing through EEH... if
> > > > > that's even
> > > > > > > >> possible.
> > > > > > > >>
> > > > > > > >> eric
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> -------------------------------------------------------
> > > > > > > >> This SF.NET email is sponsored by:
> > > > > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > > > Something 2 See!
> > > > > > > >> http://www.vasoftware.com
> > > > > > > >> _______________________________________________
> > > > > > > >> Webmacro-devel mailing list
> > > > > > > >> Web...@li...
> > > > > > > >>
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > > >>
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lane Sharman
> > > > > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > > > > Hosting Services
> > > > > > > > http://opendoors.com/lane.pdf BIO
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > This SF.NET email is sponsored by:
> > > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > Something 2
> > > > > > See!
> > > > > > > > http://www.vasoftware.com
> > > > > > > > _______________________________________________
> > > > > > > > Webmacro-devel mailing list
> > > > > > > > Web...@li...
> > > > > > > >
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This SF.NET email is sponsored by:
> > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > Something 2 See!
> > > > > > > http://www.vasoftware.com
> > > > > > > _______________________________________________
> > > > > > > Webmacro-devel mailing list
> > > > > > > Web...@li...
> > > > > > > =
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

This is where we enter the world of javacc which is terra incognito to =
me,
but AFAICT we'd need to make a "lookahead production" that determines =
if
something is indeed a directive/macro and then push it back on the =
stream if
it isn't.  Along the way the EEH could decide whether to spew, or let =
this
stand as text.

Any idea how to do this?

Keats

> -----Original Message-----
> From: Eric B. Ridge [mailto:eb...@tc...]
> Sent: Wednesday, February 12, 2003 5:29 PM
> To: kea...@na...
> Cc: la...@op...; br...@qu...; ma...@an...;
> web...@li...
> Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
>=20
>=20
> On Wednesday, February 12, 2003, at 05:26  PM,=20
> kea...@na... wrote:
>=20
> > I guess I was a bit hasty in my post ... it appears the solution is =

> > not quite as trivial as I had thought.=A0 The problem is how=20
> to recreate=20
> > the original template text after it has already been=20
> parsed, with all=20
> > the proper whitespace, etc.=A0 This seems like a parser hack,=20
> i.e., if=20
> > the MacroBuilder spews a NoSuchDirectiveException, then the parser=20
> > needs to push back all the whitespace and the # directive name.=A0
> >
> > Bleck!
>=20
> eww, I didn't even consider the <WS> eating.  Bleck! is right.
>=20
> Now what?
>=20
> eric
>=20
> >
> > Keats
> >
> > > -----Original Message-----
> > > From: Keats Kirsch
> > > Sent: Wednesday, February 12, 2003 5:10 PM
> > > To: 'Eric B. Ridge'; Keats Kirsch
> > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > web...@li...
> > > Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
> > >
> > >
> > > You're right, I was mislead by some apparently dead code in
> > > the parser:
> > >
> > >=A0=A0=A0=A0 throw new ParseException("No such directive #" + =
directive);
> > >
> > > Apparently, this now gets handled by the
> > > MacroBuilder.build(), which throws:
> > >
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0 throw new BuildException ("#" + name + =
": no such
> > > Macro or Directive");
> > >=A0=A0
> > > This should make things much simpler.
> > >
> > > So you could just say:
> > >
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
bc.getEvaluationExceptionHandler().evaluate(null, bc,
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new BuildException ("#" + =
name + ": no such Macro
> > > or Directive"));
> > >
> > > This would actually fail with the DefaultEEH, as it currently
> > > doesn't check for a null variable arg.=A0 Easily fixed, but
> > > better would be to create a new PropertyException, like
> > > PropertyException.NoSuchDirectiveOrMacro and throw that.
> > >
> > > I could try to make these changes if you'd like.
> > >
> > > Keats
> > >
> > > > -----Original Message-----
> > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > Sent: Wednesday, February 12, 2003 4:36 PM
> > > > To: kea...@na...
> > > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > > web...@li...
> > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > >
> > > >
> > > > On Wednesday, February 12, 2003, at 04:01=A0 PM,
> > > > kea...@na... wrote:
> > > >
> > > > > I think using the EEH would be great, but it does present =
some
> > > > > challenges as Eric has pointed out.=A0 The unknown directive
> > > > exceptions
> > > > > are thrown by the parser.=A0 The parser does have a
> > > reference to the
> > > > > broker, so it should be able to get the EEH and pass
> > > > exceptions back
> > > > > to it.
> > > >
> > > > Technically, it's a BuildException, not a ParseException.
> > > >
> > > > >
> > > > > Unfortunately the EEH interface was designed to=20
> handle evaluation
> > > > > exceptions (hence the name).=A0 To handle parse=20
> exceptions we would
> > > > > probably want a new method in the interface (like
> > > "parse()").=A0 This
> > > > > would require a change in all existing EEH =
implementations.=A0
> > > >=A0 Probably
> > > > > not a huge problem, but something to consider.=A0
> > > > >
> > > > > Also the name wouldn't be quite appropriate if we expand
> > > > the scope of
> > > > > this.=A0 It should probably be just ExceptionHandler or
> > > > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler
> > > interface could
> > > > > extend EvaluationExceptionHandler and add the new method.=A0
> > > > Then if you
> > > > > configure an ExceptionHandler, it would automatically set
> > > > the EEH as
> > > > > well.=A0 This should preserve backwards compatability.
> > > >
> > > > I don't think we'll need to change the interface for=20
> EEH.=A0 But we
> > > > could/should change the name...
> > > >
> > > > >
> > > > > In any case, someone would need to tweek the parser -- and
> > > > I know of
> > > > > only two candidates ...
> > > >
> > > > The parser won't need to be touched.=A0 I don't believe.
> > > >
> > > > >
> > > > > Keats
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > > > To: la...@op...
> > > > > > Cc: Brian Goetz; ma...@an...;
> > > > > > web...@li...
> > > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > > >
> > > > > >
> > > > > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman =

> > wrote:
> > > > > >
> > > > > > > ebr:
> > > > > > >
> > > > > > > Can you make a stab at modifying eeh so that we can try
> > > > this out?
> > > > > >
> > > > > > I can, yes... when I find the time.
> > > > > >
> > > > > > The issue here is that EEH is used as a "runtime"=20
> thing, not a
> > > > > > "buildtime" thing, so I'm not sure how it will=20
> interact with=20
> > the
> > > > > > BuildContext (if it all).
> > > > > >
> > > > > > Assuming I can work that out, I guess we want:
> > > > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown =
directives to the
> > > > > > stream as
> > > > > > string literals
> > > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc =
wants, to be
> > > > written by him.=A0
> > > > > :)
> > > > > >
> > > > > > eric
> > > > > >
> > > > > > >
> > > > > > > -l
> > > > > > >
> > > > > > > Eric B. Ridge wrote:
> > > > > > >
> > > > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian
> > > Goetz wrote:
> > > > > > >>
> > > > > > >>>> This problem is elegantly solved thru the=20
> introduction of=20
> > a
> > > > > > >>>> property,
> > > > > > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > > > > > times when
> > > > > > >>>> you
> > > > > > >>>> cannot "include as text" a DW file because you will
> > > > want to add
> > > > > > >>>> some WM
> > > > > > >>>> var reference to it!
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> I'd rather see "strict directive checking"=20
> rolled in with
> > > > > > other forms
> > > > > > >>> of strict checking (like the Cranky EEH), rather than
> > > > have seven
> > > > > > >>> different
> > > > > > >>> things a user would have to do to get strict checking.
> > > > > > >>
> > > > > > >>
> > > > > > >> Better yet (maybe), roll this thing through EEH... if
> > > > that's even
> > > > > > >> possible.
> > > > > > >>
> > > > > > >> eric
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> -------------------------------------------------------
> > > > > > >> This SF.NET email is sponsored by:
> > > > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > > Something 2 See!
> > > > > > >> http://www.vasoftware.com
> > > > > > >> _______________________________________________
> > > > > > >> Webmacro-devel mailing list
> > > > > > >> Web...@li...
> > > > > > >>=20
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > > >>
> > > > > > >
> > > > > > > --
> > > > > > > Lane Sharman
> > > > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > > > Hosting Services
> > > > > > > http://opendoors.com/lane.pdf BIO
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This SF.NET email is sponsored by:
> > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > Something 2
> > > > > See!
> > > > > > > http://www.vasoftware.com
> > > > > > > _______________________________________________
> > > > > > > Webmacro-devel mailing list
> > > > > > > Web...@li...
> > > > > > >=20
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This SF.NET email is sponsored by:
> > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > Something 2 See!
> > > > > > http://www.vasoftware.com
> > > > > > _______________________________________________
> > > > > > Webmacro-devel mailing list
> > > > > > Web...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > >
> > > > >
> > > >
> > >
> >
>=20

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Eric B. R. <eb...@tc...>]

On Wednesday, February 12, 2003, at 05:26  PM,=20
kea...@na... wrote:

> I guess I was a bit hasty in my post ... it appears the solution is=20
> not quite as trivial as I had thought.=A0 The problem is how to =
recreate=20
> the original template text after it has already been parsed, with all=20=

> the proper whitespace, etc.=A0 This seems like a parser hack, i.e., if=20=

> the MacroBuilder spews a NoSuchDirectiveException, then the parser=20
> needs to push back all the whitespace and the # directive name.=A0
>
> Bleck!

eww, I didn't even consider the <WS> eating.  Bleck! is right.

Now what?

eric

>
> Keats
>
> > -----Original Message-----
> > From: Keats Kirsch
> > Sent: Wednesday, February 12, 2003 5:10 PM
> > To: 'Eric B. Ridge'; Keats Kirsch
> > Cc: la...@op...; br...@qu...; ma...@an...;
> > web...@li...
> > Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > You're right, I was mislead by some apparently dead code in
> > the parser:
> >
> >=A0=A0=A0=A0 throw new ParseException("No such directive #" + =
directive);
> >
> > Apparently, this now gets handled by the
> > MacroBuilder.build(), which throws:
> >
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 throw new BuildException ("#" + name + ": =
no such
> > Macro or Directive");
> >=A0=A0
> > This should make things much simpler.
> >
> > So you could just say:
> >
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
bc.getEvaluationExceptionHandler().evaluate(null, bc,
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new BuildException ("#" + name + =
": no such Macro
> > or Directive"));
> >
> > This would actually fail with the DefaultEEH, as it currently
> > doesn't check for a null variable arg.=A0 Easily fixed, but
> > better would be to create a new PropertyException, like
> > PropertyException.NoSuchDirectiveOrMacro and throw that.
> >
> > I could try to make these changes if you'd like.
> >
> > Keats
> >
> > > -----Original Message-----
> > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > Sent: Wednesday, February 12, 2003 4:36 PM
> > > To: kea...@na...
> > > Cc: la...@op...; br...@qu...; ma...@an...;
> > > web...@li...
> > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > >
> > >
> > > On Wednesday, February 12, 2003, at 04:01=A0 PM,
> > > kea...@na... wrote:
> > >
> > > > I think using the EEH would be great, but it does present some
> > > > challenges as Eric has pointed out.=A0 The unknown directive
> > > exceptions
> > > > are thrown by the parser.=A0 The parser does have a
> > reference to the
> > > > broker, so it should be able to get the EEH and pass
> > > exceptions back
> > > > to it.
> > >
> > > Technically, it's a BuildException, not a ParseException.
> > >
> > > >
> > > > Unfortunately the EEH interface was designed to handle =
evaluation
> > > > exceptions (hence the name).=A0 To handle parse exceptions we =
would
> > > > probably want a new method in the interface (like
> > "parse()").=A0 This
> > > > would require a change in all existing EEH implementations.=A0
> > >=A0 Probably
> > > > not a huge problem, but something to consider.=A0
> > > >
> > > > Also the name wouldn't be quite appropriate if we expand
> > > the scope of
> > > > this.=A0 It should probably be just ExceptionHandler or
> > > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler
> > interface could
> > > > extend EvaluationExceptionHandler and add the new method.=A0
> > > Then if you
> > > > configure an ExceptionHandler, it would automatically set
> > > the EEH as
> > > > well.=A0 This should preserve backwards compatability.
> > >
> > > I don't think we'll need to change the interface for EEH.=A0 But =
we
> > > could/should change the name...
> > >
> > > >
> > > > In any case, someone would need to tweek the parser -- and
> > > I know of
> > > > only two candidates ...
> > >
> > > The parser won't need to be touched.=A0 I don't believe.
> > >
> > > >
> > > > Keats
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > > To: la...@op...
> > > > > Cc: Brian Goetz; ma...@an...;
> > > > > web...@li...
> > > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > > >
> > > > >
> > > > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman=20
> wrote:
> > > > >
> > > > > > ebr:
> > > > > >
> > > > > > Can you make a stab at modifying eeh so that we can try
> > > this out?
> > > > >
> > > > > I can, yes... when I find the time.
> > > > >
> > > > > The issue here is that EEH is used as a "runtime" thing, not a
> > > > > "buildtime" thing, so I'm not sure how it will interact with=20=

> the
> > > > > BuildContext (if it all).
> > > > >
> > > > > Assuming I can work that out, I guess we want:
> > > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown =
directives to the
> > > > > stream as
> > > > > string literals
> > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc =
wants, to be
> > > written by him.=A0
> > > > :)
> > > > >
> > > > > eric
> > > > >
> > > > > >
> > > > > > -l
> > > > > >
> > > > > > Eric B. Ridge wrote:
> > > > > >
> > > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian
> > Goetz wrote:
> > > > > >>
> > > > > >>>> This problem is elegantly solved thru the introduction of=20=

> a
> > > > > >>>> property,
> > > > > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > > > > times when
> > > > > >>>> you
> > > > > >>>> cannot "include as text" a DW file because you will
> > > want to add
> > > > > >>>> some WM
> > > > > >>>> var reference to it!
> > > > > >>>
> > > > > >>>
> > > > > >>> I'd rather see "strict directive checking" rolled in with
> > > > > other forms
> > > > > >>> of strict checking (like the Cranky EEH), rather than
> > > have seven
> > > > > >>> different
> > > > > >>> things a user would have to do to get strict checking.
> > > > > >>
> > > > > >>
> > > > > >> Better yet (maybe), roll this thing through EEH... if
> > > that's even
> > > > > >> possible.
> > > > > >>
> > > > > >> eric
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> -------------------------------------------------------
> > > > > >> This SF.NET email is sponsored by:
> > > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > > Something 2 See!
> > > > > >> http://www.vasoftware.com
> > > > > >> _______________________________________________
> > > > > >> Webmacro-devel mailing list
> > > > > >> Web...@li...
> > > > > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Lane Sharman
> > > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > > Hosting Services
> > > > > > http://opendoors.com/lane.pdf BIO
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This SF.NET email is sponsored by:
> > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > Something 2
> > > > See!
> > > > > > http://www.vasoftware.com
> > > > > > _______________________________________________
> > > > > > Webmacro-devel mailing list
> > > > > > Web...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.NET email is sponsored by:
> > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > Something 2 See!
> > > > > http://www.vasoftware.com
> > > > > _______________________________________________
> > > > > Webmacro-devel mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > >
> > > >
> > >
> >
>

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Eric B. R. <eb...@tc...>]

On Wednesday, February 12, 2003, at 05:09  PM,=20
kea...@na... wrote:

> You're right, I was mislead by some apparently dead code in the =
parser:
>
> =A0=A0=A0 throw new ParseException("No such directive #" + directive);
>
> Apparently, this now gets handled by the MacroBuilder.build(), which=20=

> throws:
>
> =A0=A0=A0=A0=A0=A0=A0=A0 throw new BuildException ("#" + name + ": no =
such Macro or=20
> Directive");
> =A0
> This should make things much simpler.
>
> So you could just say:
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 =
bc.getEvaluationExceptionHandler().evaluate(null, bc,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 new BuildException ("#" + name + ": =
no such Macro or=20
> Directive"));

Well, the problem is that we have to return something that is to be put=20=

into the Template to replace the unknown directive.

Like, if we just want to output it as a string literal, we'd need to=20
return some kind of new StringMacro(name) from .build()... and EEH=20
doesn't really have the facility for doing that.  This is the tricky=20
part.

>
> This would actually fail with the DefaultEEH, as it currently doesn't=20=

> check for a null variable arg.=A0 Easily fixed, but better would be to=20=

> create a new PropertyException, like=20
> PropertyException.NoSuchDirectiveOrMacro and throw that.

Yeah, we'd need to teach DEEH about this new exception.

> I could try to make these changes if you'd like.

gotta figure out how to get the directive name back into the Template=20
as a String.

eric

>
> Keats
>
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Wednesday, February 12, 2003 4:36 PM
> > To: kea...@na...
> > Cc: la...@op...; br...@qu...; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > On Wednesday, February 12, 2003, at 04:01=A0 PM,
> > kea...@na... wrote:
> >
> > > I think using the EEH would be great, but it does present some
> > > challenges as Eric has pointed out.=A0 The unknown directive
> > exceptions
> > > are thrown by the parser.=A0 The parser does have a reference to =
the
> > > broker, so it should be able to get the EEH and pass
> > exceptions back
> > > to it.
> >
> > Technically, it's a BuildException, not a ParseException.
> >
> > >
> > > Unfortunately the EEH interface was designed to handle evaluation
> > > exceptions (hence the name).=A0 To handle parse exceptions we =
would
> > > probably want a new method in the interface (like "parse()").=A0 =
This
> > > would require a change in all existing EEH implementations.=A0
> >=A0 Probably
> > > not a huge problem, but something to consider.=A0
> > >
> > > Also the name wouldn't be quite appropriate if we expand
> > the scope of
> > > this.=A0 It should probably be just ExceptionHandler or
> > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler interface =
could
> > > extend EvaluationExceptionHandler and add the new method.=A0
> > Then if you
> > > configure an ExceptionHandler, it would automatically set
> > the EEH as
> > > well.=A0 This should preserve backwards compatability.
> >
> > I don't think we'll need to change the interface for EEH.=A0 But we
> > could/should change the name...
> >
> > >
> > > In any case, someone would need to tweek the parser -- and
> > I know of
> > > only two candidates ...
> >
> > The parser won't need to be touched.=A0 I don't believe.
> >
> > >
> > > Keats
> > >
> > > > -----Original Message-----
> > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > To: la...@op...
> > > > Cc: Brian Goetz; ma...@an...;
> > > > web...@li...
> > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > >
> > > >
> > > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman =
wrote:
> > > >
> > > > > ebr:
> > > > >
> > > > > Can you make a stab at modifying eeh so that we can try
> > this out?
> > > >
> > > > I can, yes... when I find the time.
> > > >
> > > > The issue here is that EEH is used as a "runtime" thing, not a
> > > > "buildtime" thing, so I'm not sure how it will interact with the
> > > > BuildContext (if it all).
> > > >
> > > > Assuming I can work that out, I guess we want:
> > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown directives =
to the
> > > > stream as
> > > > string literals
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc wants, =
to be
> > written by him.=A0
> > > :)
> > > >
> > > > eric
> > > >
> > > > >
> > > > > -l
> > > > >
> > > > > Eric B. Ridge wrote:
> > > > >
> > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian Goetz=20
> wrote:
> > > > >>
> > > > >>>> This problem is elegantly solved thru the introduction of a
> > > > >>>> property,
> > > > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > > > times when
> > > > >>>> you
> > > > >>>> cannot "include as text" a DW file because you will
> > want to add
> > > > >>>> some WM
> > > > >>>> var reference to it!
> > > > >>>
> > > > >>>
> > > > >>> I'd rather see "strict directive checking" rolled in with
> > > > other forms
> > > > >>> of strict checking (like the Cranky EEH), rather than
> > have seven
> > > > >>> different
> > > > >>> things a user would have to do to get strict checking.
> > > > >>
> > > > >>
> > > > >> Better yet (maybe), roll this thing through EEH... if
> > that's even
> > > > >> possible.
> > > > >>
> > > > >> eric
> > > > >>
> > > > >>
> > > > >>
> > > > >> -------------------------------------------------------
> > > > >> This SF.NET email is sponsored by:
> > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > Something 2 See!
> > > > >> http://www.vasoftware.com
> > > > >> _______________________________________________
> > > > >> Webmacro-devel mailing list
> > > > >> Web...@li...
> > > > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > >>
> > > > >
> > > > > --
> > > > > Lane Sharman
> > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > Hosting Services
> > > > > http://opendoors.com/lane.pdf BIO
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.NET email is sponsored by:
> > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D =
Something 2
> > > See!
> > > > > http://www.vasoftware.com
> > > > > _______________________________________________
> > > > > Webmacro-devel mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.NET email is sponsored by:
> > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > Something 2 See!
> > > > http://www.vasoftware.com
> > > > _______________________________________________
> > > > Webmacro-devel mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > >
> > >
> >
>

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

I guess I was a bit hasty in my post ... it appears the solution is not
quite as trivial as I had thought.  The problem is how to recreate the
original template text after it has already been parsed, with all the =
proper
whitespace, etc.  This seems like a parser hack, i.e., if the =
MacroBuilder
spews a NoSuchDirectiveException, then the parser needs to push back =
all the
whitespace and the # directive name. =20

Bleck!

Keats

> -----Original Message-----
> From: Keats Kirsch=20
> Sent: Wednesday, February 12, 2003 5:10 PM
> To: 'Eric B. Ridge'; Keats Kirsch
> Cc: la...@op...; br...@qu...; ma...@an...;
> web...@li...
> Subject: RE: [Webmacro-devel] Handling Dreamweaver stuff
>=20
>=20
> You're right, I was mislead by some apparently dead code in=20
> the parser:
>=20
>     throw new ParseException("No such directive #" + directive);
>=20
> Apparently, this now gets handled by the=20
> MacroBuilder.build(), which throws:
>=20
>          throw new BuildException ("#" + name + ": no such=20
> Macro or Directive");
>  =20
> This should make things much simpler.
>=20
> So you could just say:
>=20
>           bc.getEvaluationExceptionHandler().evaluate(null, bc,=20
>             new BuildException ("#" + name + ": no such Macro=20
> or Directive"));
>=20
> This would actually fail with the DefaultEEH, as it currently=20
> doesn't check for a null variable arg.  Easily fixed, but=20
> better would be to create a new PropertyException, like=20
> PropertyException.NoSuchDirectiveOrMacro and throw that.
>=20
> I could try to make these changes if you'd like.
>=20
> Keats
>=20
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Wednesday, February 12, 2003 4:36 PM
> > To: kea...@na...
> > Cc: la...@op...; br...@qu...; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >=20
> >=20
> > On Wednesday, February 12, 2003, at 04:01  PM,=20
> > kea...@na... wrote:
> >=20
> > > I think using the EEH would be great, but it does present some=20
> > > challenges as Eric has pointed out.=A0 The unknown directive=20
> > exceptions=20
> > > are thrown by the parser.=A0 The parser does have a=20
> reference to the=20
> > > broker, so it should be able to get the EEH and pass=20
> > exceptions back=20
> > > to it.
> >=20
> > Technically, it's a BuildException, not a ParseException.
> >=20
> > >
> > > Unfortunately the EEH interface was designed to handle evaluation =

> > > exceptions (hence the name).=A0 To handle parse exceptions we =
would=20
> > > probably want a new method in the interface (like=20
> "parse()").=A0 This=20
> > > would require a change in all existing EEH implementations.=A0
> >  Probably=20
> > > not a huge problem, but something to consider.=A0
> > >
> > > Also the name wouldn't be quite appropriate if we expand=20
> > the scope of=20
> > > this.=A0 It should probably be just ExceptionHandler or=20
> > > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler=20
> interface could=20
> > > extend EvaluationExceptionHandler and add the new method.=A0=20
> > Then if you=20
> > > configure an ExceptionHandler, it would automatically set=20
> > the EEH as=20
> > > well.=A0 This should preserve backwards compatability.
> >=20
> > I don't think we'll need to change the interface for EEH.  But we=20
> > could/should change the name...
> >=20
> > >
> > > In any case, someone would need to tweek the parser -- and=20
> > I know of=20
> > > only two candidates ...
> >=20
> > The parser won't need to be touched.  I don't believe.
> >=20
> > >
> > > Keats
> > >
> > > > -----Original Message-----
> > > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > > To: la...@op...
> > > > Cc: Brian Goetz; ma...@an...;
> > > > web...@li...
> > > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > > >
> > > >
> > > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman =
wrote:
> > > >
> > > > > ebr:
> > > > >
> > > > > Can you make a stab at modifying eeh so that we can try=20
> > this out?
> > > >
> > > > I can, yes... when I find the time.
> > > >
> > > > The issue here is that EEH is used as a "runtime" thing, not a
> > > > "buildtime" thing, so I'm not sure how it will interact with =
the
> > > > BuildContext (if it all).
> > > >
> > > > Assuming I can work that out, I guess we want:
> > > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown directives =
to the
> > > > stream as
> > > > string literals
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc =
wants, to be=20
> > written by him.=A0=20
> > > :)
> > > >
> > > > eric
> > > >
> > > > >
> > > > > -l
> > > > >
> > > > > Eric B. Ridge wrote:
> > > > >
> > > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian=20
> Goetz wrote:
> > > > >>
> > > > >>>> This problem is elegantly solved thru the introduction of =
a
> > > > >>>> property,
> > > > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > > > times when
> > > > >>>> you
> > > > >>>> cannot "include as text" a DW file because you will=20
> > want to add
> > > > >>>> some WM
> > > > >>>> var reference to it!
> > > > >>>
> > > > >>>
> > > > >>> I'd rather see "strict directive checking" rolled in with
> > > > other forms
> > > > >>> of strict checking (like the Cranky EEH), rather than=20
> > have seven
> > > > >>> different
> > > > >>> things a user would have to do to get strict checking.
> > > > >>
> > > > >>
> > > > >> Better yet (maybe), roll this thing through EEH... if=20
> > that's even
> > > > >> possible.
> > > > >>
> > > > >> eric
> > > > >>
> > > > >>
> > > > >>
> > > > >> -------------------------------------------------------
> > > > >> This SF.NET email is sponsored by:
> > > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > > Something 2 See!
> > > > >> http://www.vasoftware.com
> > > > >> _______________________________________________
> > > > >> Webmacro-devel mailing list
> > > > >> Web...@li...
> > > > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > > >>
> > > > >
> > > > > --
> > > > > Lane Sharman
> > > > > http://opendoors.com Conga, GoodTimes and Application
> > > > Hosting Services
> > > > > http://opendoors.com/lane.pdf BIO
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.NET email is sponsored by:
> > > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D=20
> Something 2=20
> > > See!
> > > > > http://www.vasoftware.com
> > > > > _______________________________________________
> > > > > Webmacro-devel mailing list
> > > > > Web...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.NET email is sponsored by:
> > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D=20
> > Something 2 See!
> > > > http://www.vasoftware.com
> > > > _______________________________________________
> > > > Webmacro-devel mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > >
> > >
> >=20
>=20

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

You're right, I was mislead by some apparently dead code in the parser:

    throw new ParseException("No such directive #" + directive);

Apparently, this now gets handled by the MacroBuilder.build(), which =
throws:

         throw new BuildException ("#" + name + ": no such Macro or
Directive");
 =20
This should make things much simpler.

So you could just say:

          bc.getEvaluationExceptionHandler().evaluate(null, bc,=20
            new BuildException ("#" + name + ": no such Macro or
Directive"));

This would actually fail with the DefaultEEH, as it currently doesn't =
check
for a null variable arg.  Easily fixed, but better would be to create a =
new
PropertyException, like PropertyException.NoSuchDirectiveOrMacro and =
throw
that.

I could try to make these changes if you'd like.

Keats

> -----Original Message-----
> From: Eric B. Ridge [mailto:eb...@tc...]
> Sent: Wednesday, February 12, 2003 4:36 PM
> To: kea...@na...
> Cc: la...@op...; br...@qu...; ma...@an...;
> web...@li...
> Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
>=20
>=20
> On Wednesday, February 12, 2003, at 04:01  PM,=20
> kea...@na... wrote:
>=20
> > I think using the EEH would be great, but it does present some=20
> > challenges as Eric has pointed out.=A0 The unknown directive=20
> exceptions=20
> > are thrown by the parser.=A0 The parser does have a reference to =
the=20
> > broker, so it should be able to get the EEH and pass=20
> exceptions back=20
> > to it.
>=20
> Technically, it's a BuildException, not a ParseException.
>=20
> >
> > Unfortunately the EEH interface was designed to handle evaluation=20
> > exceptions (hence the name).=A0 To handle parse exceptions we would =

> > probably want a new method in the interface (like "parse()").=A0 =
This=20
> > would require a change in all existing EEH implementations.=A0
>  Probably=20
> > not a huge problem, but something to consider.=A0
> >
> > Also the name wouldn't be quite appropriate if we expand=20
> the scope of=20
> > this.=A0 It should probably be just ExceptionHandler or=20
> > WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler interface =
could=20
> > extend EvaluationExceptionHandler and add the new method.=A0=20
> Then if you=20
> > configure an ExceptionHandler, it would automatically set=20
> the EEH as=20
> > well.=A0 This should preserve backwards compatability.
>=20
> I don't think we'll need to change the interface for EEH.  But we=20
> could/should change the name...
>=20
> >
> > In any case, someone would need to tweek the parser -- and=20
> I know of=20
> > only two candidates ...
>=20
> The parser won't need to be touched.  I don't believe.
>=20
> >
> > Keats
> >
> > > -----Original Message-----
> > > From: Eric B. Ridge [mailto:eb...@tc...]
> > > Sent: Tuesday, February 11, 2003 8:05 PM
> > > To: la...@op...
> > > Cc: Brian Goetz; ma...@an...;
> > > web...@li...
> > > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> > >
> > >
> > > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman =
wrote:
> > >
> > > > ebr:
> > > >
> > > > Can you make a stab at modifying eeh so that we can try=20
> this out?
> > >
> > > I can, yes... when I find the time.
> > >
> > > The issue here is that EEH is used as a "runtime" thing, not a
> > > "buildtime" thing, so I'm not sure how it will interact with the
> > > BuildContext (if it all).
> > >
> > > Assuming I can work that out, I guess we want:
> > > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown =
directives
> > > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown directives =
to the
> > > stream as
> > > string literals
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc wants, =
to be=20
> written by him.=A0=20
> > :)
> > >
> > > eric
> > >
> > > >
> > > > -l
> > > >
> > > > Eric B. Ridge wrote:
> > > >
> > > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian Goetz =
wrote:
> > > >>
> > > >>>> This problem is elegantly solved thru the introduction of a
> > > >>>> property,
> > > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > > times when
> > > >>>> you
> > > >>>> cannot "include as text" a DW file because you will=20
> want to add
> > > >>>> some WM
> > > >>>> var reference to it!
> > > >>>
> > > >>>
> > > >>> I'd rather see "strict directive checking" rolled in with
> > > other forms
> > > >>> of strict checking (like the Cranky EEH), rather than=20
> have seven
> > > >>> different
> > > >>> things a user would have to do to get strict checking.
> > > >>
> > > >>
> > > >> Better yet (maybe), roll this thing through EEH... if=20
> that's even
> > > >> possible.
> > > >>
> > > >> eric
> > > >>
> > > >>
> > > >>
> > > >> -------------------------------------------------------
> > > >> This SF.NET email is sponsored by:
> > > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > > Something 2 See!
> > > >> http://www.vasoftware.com
> > > >> _______________________________________________
> > > >> Webmacro-devel mailing list
> > > >> Web...@li...
> > > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > > >>
> > > >
> > > > --
> > > > Lane Sharman
> > > > http://opendoors.com Conga, GoodTimes and Application
> > > Hosting Services
> > > > http://opendoors.com/lane.pdf BIO
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.NET email is sponsored by:
> > > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something =
2=20
> > See!
> > > > http://www.vasoftware.com
> > > > _______________________________________________
> > > > Webmacro-devel mailing list
> > > > Web...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by:
> > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D=20
> Something 2 See!
> > > http://www.vasoftware.com
> > > _______________________________________________
> > > Webmacro-devel mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > >
> >
>=20

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

I don't like to advocate implementations because they are the path of 
least resistance and it sounds to me that we are trying to make an EEH 
the path of least resistance and are now discovering why this is not the 
right point of contact.

Personally, I think strict directive type checking was a rotten decision 
because it foils so many standard web pages into becoming WM maintenance 
bogs. When you start working with Web design teams and each time they 
send you an iteration of a hundred pages, you begin to appreciate that 
everything that is not known to WM's parser should be passed thru. WM 
was designed to co-exist, not shut down WM team development. That was 
our mantra and now we have a parser with strict checking on by default. 
Bad. Really bad.

Further, we are now mired in how to fix it. My vote is to do it in the 
right place and to do the right thing. Make it off by default.

If possible, please vote +1 on this proposal or some better alternative 
by cob today.

-Lane

kea...@na... wrote:

> I think using the EEH would be great, but it does present some 
> challenges as Eric has pointed out.  The unknown directive exceptions 
> are thrown by the parser.  The parser does have a reference to the 
> broker, so it should be able to get the EEH and pass exceptions back 
> to it.
>
> Unfortunately the EEH interface was designed to handle evaluation 
> exceptions (hence the name).  To handle parse exceptions we would 
> probably want a new method in the interface (like "parse()").  This 
> would require a change in all existing EEH implementations.  Probably 
> not a huge problem, but something to consider. 
>
> Also the name wouldn't be quite appropriate if we expand the scope of 
> this.  It should probably be just ExceptionHandler or 
> WMExceptionHandler.  Maybe an o.w.ExceptionHandler interface could 
> extend EvaluationExceptionHandler and add the new method.  Then if you 
> configure an ExceptionHandler, it would automatically set the EEH as 
> well.  This should preserve backwards compatability.
>
> In any case, someone would need to tweek the parser -- and I know of 
> only two candidates ...
>
> Keats
>
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Tuesday, February 11, 2003 8:05 PM
> > To: la...@op...
> > Cc: Brian Goetz; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > On Tuesday, February 11, 2003, at 04:12  PM, Lane Sharman wrote:
> >
> > > ebr:
> > >
> > > Can you make a stab at modifying eeh so that we can try this out?
> >
> > I can, yes... when I find the time.
> >
> > The issue here is that EEH is used as a "runtime" thing, not a
> > "buildtime" thing, so I'm not sure how it will interact with the
> > BuildContext (if it all).
> >
> > Assuming I can work that out, I guess we want:
> >       CrankyEEH to *always* throw on #unknown directives
> >       DefaultEEH to *always* pass #unknown directives to the
> > stream as
> > string literals
> >           MarcEEH to do whatever Marc wants, to be written by him.  :)
> >
> > eric
> >
> > >
> > > -l
> > >
> > > Eric B. Ridge wrote:
> > >
> > >> On Tuesday, February 11, 2003, at 03:35  PM, Brian Goetz wrote:
> > >>
> > >>>> This problem is elegantly solved thru the introduction of a
> > >>>> property,
> > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > times when
> > >>>> you
> > >>>> cannot "include as text" a DW file because you will want to add
> > >>>> some WM
> > >>>> var reference to it!
> > >>>
> > >>>
> > >>> I'd rather see "strict directive checking" rolled in with
> > other forms
> > >>> of strict checking (like the Cranky EEH), rather than have seven
> > >>> different
> > >>> things a user would have to do to get strict checking.
> > >>
> > >>
> > >> Better yet (maybe), roll this thing through EEH... if that's even
> > >> possible.
> > >>
> > >> eric
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> This SF.NET email is sponsored by:
> > >> SourceForge Enterprise Edition + IBM + LinuxWorld =
> > Something 2 See!
> > >> http://www.vasoftware.com
> > >> _______________________________________________
> > >> Webmacro-devel mailing list
> > >> Web...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > >>
> > >
> > > --
> > > Lane Sharman
> > > http://opendoors.com Conga, GoodTimes and Application
> > Hosting Services
> > > http://opendoors.com/lane.pdf BIO
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by:
> > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > > http://www.vasoftware.com
> > > _______________________________________________
> > > Webmacro-devel mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Eric B. R. <eb...@tc...>]

On Wednesday, February 12, 2003, at 04:01  PM,=20
kea...@na... wrote:

> I think using the EEH would be great, but it does present some=20
> challenges as Eric has pointed out.=A0 The unknown directive =
exceptions=20
> are thrown by the parser.=A0 The parser does have a reference to the=20=

> broker, so it should be able to get the EEH and pass exceptions back=20=

> to it.

Technically, it's a BuildException, not a ParseException.

>
> Unfortunately the EEH interface was designed to handle evaluation=20
> exceptions (hence the name).=A0 To handle parse exceptions we would=20
> probably want a new method in the interface (like "parse()").=A0 This=20=

> would require a change in all existing EEH implementations.=A0 =
Probably=20
> not a huge problem, but something to consider.=A0
>
> Also the name wouldn't be quite appropriate if we expand the scope of=20=

> this.=A0 It should probably be just ExceptionHandler or=20
> WMExceptionHandler.=A0 Maybe an o.w.ExceptionHandler interface could=20=

> extend EvaluationExceptionHandler and add the new method.=A0 Then if =
you=20
> configure an ExceptionHandler, it would automatically set the EEH as=20=

> well.=A0 This should preserve backwards compatability.

I don't think we'll need to change the interface for EEH.  But we=20
could/should change the name...

>
> In any case, someone would need to tweek the parser -- and I know of=20=

> only two candidates ...

The parser won't need to be touched.  I don't believe.

>
> Keats
>
> > -----Original Message-----
> > From: Eric B. Ridge [mailto:eb...@tc...]
> > Sent: Tuesday, February 11, 2003 8:05 PM
> > To: la...@op...
> > Cc: Brian Goetz; ma...@an...;
> > web...@li...
> > Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> >
> >
> > On Tuesday, February 11, 2003, at 04:12=A0 PM, Lane Sharman wrote:
> >
> > > ebr:
> > >
> > > Can you make a stab at modifying eeh so that we can try this out?
> >
> > I can, yes... when I find the time.
> >
> > The issue here is that EEH is used as a "runtime" thing, not a
> > "buildtime" thing, so I'm not sure how it will interact with the
> > BuildContext (if it all).
> >
> > Assuming I can work that out, I guess we want:
> > =A0=A0=A0=A0=A0 CrankyEEH to *always* throw on #unknown directives
> > =A0=A0=A0=A0=A0 DefaultEEH to *always* pass #unknown directives to =
the
> > stream as
> > string literals
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MarcEEH to do whatever Marc wants, to =
be written by him.=A0=20
> :)
> >
> > eric
> >
> > >
> > > -l
> > >
> > > Eric B. Ridge wrote:
> > >
> > >> On Tuesday, February 11, 2003, at 03:35=A0 PM, Brian Goetz wrote:
> > >>
> > >>>> This problem is elegantly solved thru the introduction of a
> > >>>> property,
> > >>>> StrictDirectiveTypeChecking. Invariably, there will be
> > times when
> > >>>> you
> > >>>> cannot "include as text" a DW file because you will want to add
> > >>>> some WM
> > >>>> var reference to it!
> > >>>
> > >>>
> > >>> I'd rather see "strict directive checking" rolled in with
> > other forms
> > >>> of strict checking (like the Cranky EEH), rather than have seven
> > >>> different
> > >>> things a user would have to do to get strict checking.
> > >>
> > >>
> > >> Better yet (maybe), roll this thing through EEH... if that's even
> > >> possible.
> > >>
> > >> eric
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> This SF.NET email is sponsored by:
> > >> SourceForge Enterprise Edition + IBM + LinuxWorld =3D
> > Something 2 See!
> > >> http://www.vasoftware.com
> > >> _______________________________________________
> > >> Webmacro-devel mailing list
> > >> Web...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> > >>
> > >
> > > --
> > > Lane Sharman
> > > http://opendoors.com Conga, GoodTimes and Application
> > Hosting Services
> > > http://opendoors.com/lane.pdf BIO
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by:
> > > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2=20=

> See!
> > > http://www.vasoftware.com
> > > _______________________________________________
> > > Webmacro-devel mailing list
> > > Web...@li...
> > > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 =
See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >
>

RE: [Webmacro-devel] Handling Dreamweaver stuff

[<kea...@na...>]

I think using the EEH would be great, but it does present some challenges as
Eric has pointed out.  The unknown directive exceptions are thrown by the
parser.  The parser does have a reference to the broker, so it should be
able to get the EEH and pass exceptions back to it.

Unfortunately the EEH interface was designed to handle evaluation exceptions
(hence the name).  To handle parse exceptions we would probably want a new
method in the interface (like "parse()").  This would require a change in
all existing EEH implementations.  Probably not a huge problem, but
something to consider.  

Also the name wouldn't be quite appropriate if we expand the scope of this.
It should probably be just ExceptionHandler or WMExceptionHandler.  Maybe an
o.w.ExceptionHandler interface could extend EvaluationExceptionHandler and
add the new method.  Then if you configure an ExceptionHandler, it would
automatically set the EEH as well.  This should preserve backwards
compatability.

In any case, someone would need to tweek the parser -- and I know of only
two candidates ...

Keats

> -----Original Message-----
> From: Eric B. Ridge [mailto:eb...@tc...]
> Sent: Tuesday, February 11, 2003 8:05 PM
> To: la...@op...
> Cc: Brian Goetz; ma...@an...;
> web...@li...
> Subject: Re: [Webmacro-devel] Handling Dreamweaver stuff
> 
> 
> On Tuesday, February 11, 2003, at 04:12  PM, Lane Sharman wrote:
> 
> > ebr:
> >
> > Can you make a stab at modifying eeh so that we can try this out?
> 
> I can, yes... when I find the time.
> 
> The issue here is that EEH is used as a "runtime" thing, not a 
> "buildtime" thing, so I'm not sure how it will interact with the 
> BuildContext (if it all).
> 
> Assuming I can work that out, I guess we want:
> 	CrankyEEH to *always* throw on #unknown directives
> 	DefaultEEH to *always* pass #unknown directives to the 
> stream as 
> string literals
>           MarcEEH to do whatever Marc wants, to be written by him.  :)
> 
> eric
> 
> >
> > -l
> >
> > Eric B. Ridge wrote:
> >
> >> On Tuesday, February 11, 2003, at 03:35  PM, Brian Goetz wrote:
> >>
> >>>> This problem is elegantly solved thru the introduction of a 
> >>>> property,
> >>>> StrictDirectiveTypeChecking. Invariably, there will be 
> times when 
> >>>> you
> >>>> cannot "include as text" a DW file because you will want to add 
> >>>> some WM
> >>>> var reference to it!
> >>>
> >>>
> >>> I'd rather see "strict directive checking" rolled in with 
> other forms
> >>> of strict checking (like the Cranky EEH), rather than have seven 
> >>> different
> >>> things a user would have to do to get strict checking.
> >>
> >>
> >> Better yet (maybe), roll this thing through EEH... if that's even 
> >> possible.
> >>
> >> eric
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.NET email is sponsored by:
> >> SourceForge Enterprise Edition + IBM + LinuxWorld = 
> Something 2 See!
> >> http://www.vasoftware.com
> >> _______________________________________________
> >> Webmacro-devel mailing list
> >> Web...@li...
> >> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> >>
> >
> > -- 
> > Lane Sharman
> > http://opendoors.com Conga, GoodTimes and Application 
> Hosting Services
> > http://opendoors.com/lane.pdf BIO
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Webmacro-devel mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

Eric B. Ridge wrote:

> On Tuesday, February 11, 2003, at 04:12  PM, Lane Sharman wrote:
>
>> ebr:
>>
>> Can you make a stab at modifying eeh so that we can try this out?
>
>
> I can, yes... when I find the time. 

I will help out with the testing side :). I've got a lot of web work to 
do in the next 90 days I cannot contemplate making all sorts of one-off 
updates to #this and #that.

-Lane

>
>
> The issue here is that EEH is used as a "runtime" thing, not a 
> "buildtime" thing, so I'm not sure how it will interact with the 
> BuildContext (if it all).
>
> Assuming I can work that out, I guess we want:
>     CrankyEEH to *always* throw on #unknown directives
>     DefaultEEH to *always* pass #unknown directives to the stream as 
> string literals
>          MarcEEH to do whatever Marc wants, to be written by him.  :)
>
> eric
>
>>
>> -l
>>
>> Eric B. Ridge wrote:
>>
>>> On Tuesday, February 11, 2003, at 03:35  PM, Brian Goetz wrote:
>>>
>>>>> This problem is elegantly solved thru the introduction of a property,
>>>>> StrictDirectiveTypeChecking. Invariably, there will be times when you
>>>>> cannot "include as text" a DW file because you will want to add 
>>>>> some WM
>>>>> var reference to it!
>>>>
>>>>
>>>>
>>>> I'd rather see "strict directive checking" rolled in with other forms
>>>> of strict checking (like the Cranky EEH), rather than have seven 
>>>> different
>>>> things a user would have to do to get strict checking.
>>>
>>>
>>>
>>> Better yet (maybe), roll this thing through EEH... if that's even 
>>> possible.
>>>
>>> eric
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.NET email is sponsored by:
>>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>> http://www.vasoftware.com
>>> _______________________________________________
>>> Webmacro-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>
>>
>> -- 
>> Lane Sharman
>> http://opendoors.com Conga, GoodTimes and Application Hosting Services
>> http://opendoors.com/lane.pdf BIO
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by:
>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>> http://www.vasoftware.com
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Eric B. R. <eb...@tc...>]

On Wednesday, February 12, 2003, at 02:58  PM, Lane Sharman wrote:

> Does anyone know if eric's concern will about passing unknown 
> directives to the stream is workable or not?
>
> I am in the middle of a making a significant verisign ecommerce macro 
> contribution to wm/macros. I would like to test both the macros and 
> the pass-through.

#unknownDirectives and #unknownMacros are the same thing to WebMacro.  
There is absolutely no difference.

eric

>
> -Lane
>
> Eric B. Ridge wrote:
>
>> On Tuesday, February 11, 2003, at 04:12  PM, Lane Sharman wrote:
>>
>>> ebr:
>>>
>>> Can you make a stab at modifying eeh so that we can try this out?
>>
>>
>> I can, yes... when I find the time.
>>
>> The issue here is that EEH is used as a "runtime" thing, not a 
>> "buildtime" thing, so I'm not sure how it will interact with the 
>> BuildContext (if it all).
>>
>> Assuming I can work that out, I guess we want:
>>     CrankyEEH to *always* throw on #unknown directives
>>     DefaultEEH to *always* pass #unknown directives to the stream as 
>> string literals
>>          MarcEEH to do whatever Marc wants, to be written by him.  :)
>>
>> eric
>>
>>>
>>> -l
>>>
>>> Eric B. Ridge wrote:
>>>
>>>> On Tuesday, February 11, 2003, at 03:35  PM, Brian Goetz wrote:
>>>>
>>>>>> This problem is elegantly solved thru the introduction of a 
>>>>>> property,
>>>>>> StrictDirectiveTypeChecking. Invariably, there will be times when 
>>>>>> you
>>>>>> cannot "include as text" a DW file because you will want to add 
>>>>>> some WM
>>>>>> var reference to it!
>>>>>
>>>>>
>>>>>
>>>>> I'd rather see "strict directive checking" rolled in with other 
>>>>> forms
>>>>> of strict checking (like the Cranky EEH), rather than have seven 
>>>>> different
>>>>> things a user would have to do to get strict checking.
>>>>
>>>>
>>>>
>>>> Better yet (maybe), roll this thing through EEH... if that's even 
>>>> possible.
>>>>
>>>> eric
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.NET email is sponsored by:
>>>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>>> http://www.vasoftware.com
>>>> _______________________________________________
>>>> Webmacro-devel mailing list
>>>> Web...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>>
>>>
>>> -- 
>>> Lane Sharman
>>> http://opendoors.com Conga, GoodTimes and Application Hosting 
>>> Services
>>> http://opendoors.com/lane.pdf BIO
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.NET email is sponsored by:
>>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>> http://www.vasoftware.com
>>> _______________________________________________
>>> Webmacro-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by:
>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>> http://www.vasoftware.com
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>
>
> -- 
> Lane Sharman
> http://opendoors.com Conga, GoodTimes and Application Hosting Services
> http://opendoors.com/lane.pdf BIO
>
>
>
>

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

Does anyone know if eric's concern will about passing unknown directives 
to the stream is workable or not?

I am in the middle of a making a significant verisign ecommerce macro 
contribution to wm/macros. I would like to test both the macros and the 
pass-through.

-Lane

Eric B. Ridge wrote:

> On Tuesday, February 11, 2003, at 04:12  PM, Lane Sharman wrote:
>
>> ebr:
>>
>> Can you make a stab at modifying eeh so that we can try this out?
>
>
> I can, yes... when I find the time.
>
> The issue here is that EEH is used as a "runtime" thing, not a 
> "buildtime" thing, so I'm not sure how it will interact with the 
> BuildContext (if it all).
>
> Assuming I can work that out, I guess we want:
>     CrankyEEH to *always* throw on #unknown directives
>     DefaultEEH to *always* pass #unknown directives to the stream as 
> string literals
>          MarcEEH to do whatever Marc wants, to be written by him.  :)
>
> eric
>
>>
>> -l
>>
>> Eric B. Ridge wrote:
>>
>>> On Tuesday, February 11, 2003, at 03:35  PM, Brian Goetz wrote:
>>>
>>>>> This problem is elegantly solved thru the introduction of a property,
>>>>> StrictDirectiveTypeChecking. Invariably, there will be times when you
>>>>> cannot "include as text" a DW file because you will want to add 
>>>>> some WM
>>>>> var reference to it!
>>>>
>>>>
>>>>
>>>> I'd rather see "strict directive checking" rolled in with other forms
>>>> of strict checking (like the Cranky EEH), rather than have seven 
>>>> different
>>>> things a user would have to do to get strict checking.
>>>
>>>
>>>
>>> Better yet (maybe), roll this thing through EEH... if that's even 
>>> possible.
>>>
>>> eric
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.NET email is sponsored by:
>>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>> http://www.vasoftware.com
>>> _______________________________________________
>>> Webmacro-devel mailing list
>>> Web...@li...
>>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>>
>>
>> -- 
>> Lane Sharman
>> http://opendoors.com Conga, GoodTimes and Application Hosting Services
>> http://opendoors.com/lane.pdf BIO
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by:
>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>> http://www.vasoftware.com
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO

Re: [Webmacro-devel] Handling Dreamweaver stuff

[Lane S. <la...@op...>]

>
> That's why I was suggesting EEH.  It's somewhat of a pluggable way to  
> do this, for now. 

yeah. So, let's do it. Marc's stuff is a rewrite which is going to take 
6-12 months to get into production. As it stands now, you cannot do 
round-trip editing and deploying with any standard html editor and wm. 
Kinda defeats the name Web in WebMacro. I am about to start calling it 
NoWebMacro.

-lane

>
>
> eric
>
>>
>> in Webmacro.defaults:
>>
>> BrokerProfile.lenient=LaxUnknownDirectiveHandler,DefaultEvaluationExcep 
>> tionHandler
>> BrokerProfile.strict=StrictUnknownDirectiveHandler,CrankyEvaluationExce 
>> ptionHandler
>>
>> in webmacro.properties the user chooses which they want:
>>
>> Broker.Profile=strict
>>
>>
>> ...and it all goes from there. This kind of thing is FAR easier if  
>> -every- WM "component" is accessed via the broker. The only trouble  
>> with the above is that you'd need a BrokerProfile.defaults= property  
>> for any classes that are common to all profiles.
>>
>> You may wonder how the Broker impl would know what kind of service  
>> these classes provide - the idea we use in our projects is that 
>> these  classes are "modules" and they have start/stop methods. When 
>> the  start(BrokerImpl broker) method is called, they register any and 
>> all  services they expose with the broker, so the broker knows what  
>> interfaces they support and what "slots" they should occupy in its  
>> services map.
>>
>> Marc
>> -- 
>> Marc Palmer (Wangjammer5)
>> http://www.wangjammers.org
>> Java Consultants
>>
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by:
>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>> http://www.vasoftware.com
>> _______________________________________________
>> Webmacro-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO