Re: concurrency problem with #include as template

Marc Palmer <[email protected]> Tue, 7 Feb 2006 16:05:50 +0000
Newsgroups gmane.comp.java.webmacro.user
Message-ID <[email protected]>
On 7 Feb 2006, at 14:26, Endre Stølsvik wrote:

> On Mon, 6 Feb 2006, Eric B. Ridge wrote:
>
> | I'm also considering taking my laptop and the WM sources with  
> me.  I want to
> | play with the parser.  I hate our whitespace handing rules and  
> have some ideas
> | on making it better.
>
> I think changing the whitespace rules now is a very bad idea. They do
> work, and changes to such fundamental parts of the system is _not_  
> welcome
> by pretty much anyone, I believe.

Actually not true. WM's whitespace handling is REALLY REALLY BAD.  
I've used it in some propery production environments now with split  
teams and it is hard to justify some of the behaviour, and producing  
nicely formatted plain text is painful.

I would be very happy for the whitespace to be improved BUT it  
depends what Eric calls improvement :)

> | The long plane flights will probably give me enough time
> | to work it out.
>
> It will be interesting to se what you come up with - but I believe  
> you at
> least should have _full_ configurable fallbacks to "as they are now"
> situation.
>

Definitely. Perhaps this means branching the parser source into two  
packages... o.w.parser and o.w.parser2 so that we can just specify in  
the WM properties which to use :)

> Really, everyone's output will be changed!! That just ain't no good  
> for
> adoption.
>

I don't imagine Eric would propose such wreckage... although if you  
make it "WM 3" then you might mitigate this to a degree... especially  
if we could provide a script that would 100% reliably alter existing  
templates to produce the same results with the new parser.

> | I've also discovered a few classes that should probably implement  
> the
> | Visitable interface that don't.  I've been working on a little  
> static analysis
> | tool to find usages of variables and such in templates and link  
> them back up
> | to known object types... as a way to find and head off template- 
> level bugs.  I
> | had to revert to some reflection trickery while visiting a few  
> Template node
> | types.
>
> For my own part, the thing about WebMacro is that there is _Way_ to  
> much
> cruft. It should be _entirely_ ripped apart, and then about 90% of it
> should be deleted, and then the remaining parts should be put together
> again as a tight little API. The big idea with the Broker and all  
> those
> little annoying caching elements and whatnot is just plain  
> annoying. Then
> one have logging.

You know you have my agreement there :)

WM's strengths are:

* The introspection engine
* The parser
* The template rendering

All the rest is basically bloat... existing template providers,  
caching providers and tools separated out from the core and  
reorganised a bit would make it a much more attractive package.

The thing is - are there enough good men to do the work? Is there  
enough agreement and will to make these tough changes for WM 3? What  
value can we add with these changes in WM 3?

For the latter, as I've stated before, I think we can add quite a bit:

* JSP integration
* Spring MVC integration
* Bean-style configuration WM instances
* Run-time (mutable) access to all directives, tools, providers and  
other config, so that you can change properties at runtime, on a new  
WM instance, and swap that for your current instance (hot swapping  
the references to avoid threading/sync issues within WM itself)... so  
that applications can -conditionally- add custom directives etc as  
beans created by the application not WM, without manipulating  
property lists etc

>   And the license should be changed. GPL is bad for business when  
> combined
> with Java, and "advertising clause" is just too "last century".

Last time I checked WM was not just GPL, you can chose the license  
you want.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642