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