Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian G. <br...@qu...> - 2003-07-17 19:00:29
|
> I'm just asking for some help with the parser bug because that is a very > complex area, and if it's in the parser .jj file then there's a hell of a > lot of a learning curve for me to fix it. I already spent days learning > about and fixing an old PropertyOperatorCache bug. OK, but like I said, I haven't touched the parser in probably a year. Also, I'm not convinced that the test case is even right! Did it ever work? When? When did it stop? |
|
From: Marc P. <ma...@an...> - 2003-07-17 15:10:44
|
OK I see from the WM site: Directives all begin with a '#' character at the beginning of a line or after one or more whitespace characters. Which is as clear as you can get. However, I have never come across this problem before. I tested with an old WM build and the behaviour is the same, so no bug here. The rules do look suspiciously like a hack to support colours and anchor tags to HTML bookmark links: #if (true) It works#end ---> OK "#if (true) It works#end ---> Dumps out script " #if (true) It works#end ---> OK a#if (true) It works#end ---> Dumps out script '#if (true) It works#end ---> Dumps out script I'll retract my overly hasty unit test - or rather correct it to assert this behaviour (see it's not all wasted!) but is this something we can re- examine now we have relaxed directive parsing? Marc |
|
From: Marc P. <ma...@an...> - 2003-07-17 14:58:17
|
On Thu, 17 Jul 2003 10:52:23 -0400, Eric B. Ridge <eb...@tc...> wrote:
>
> why not? just put a space before the #macroName. The space will be
> eaten by WM.
Well, it's not very friendly to the template write is it?
Forget a single space and your code is exposed instead of being executed?
I think that if this is something that has always existed, we should look
at removing it for 2.0 if the parser can handle it and it doesn't break
anything else.
My gut tells me this really is there just to handle:
<font color="#ffffff">
...which doesn't seem like a valid concern now we have relaxed directive
processing.
Although, I'm not 100% sold on the relaxed directive approach though I see
that it, or another solution, is required.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-17 14:52:31
|
On Thursday, July 17, 2003, at 10:44 AM, Marc Palmer wrote: > On Thu, 17 Jul 2003 10:24:43 -0400, Eric B. Ridge <eb...@tc...> wrote: > >> On Thursday, July 17, 2003, at 10:18 AM, ke...@su... wrote: >> >>> I'd be surprised if the second case worked in any version of WM -- >>> it's not supposed to. The parser should only recognize a directive >>> that is preceded by whitespace or a newline. (The preceding >>> whitespace and newline are then removed.) >> >> I was thinking the same thing. hasn't it always been like this? > > Erm, I don't think so. I am sure I have done: > > value="#if (something) ... #end" > > ...before. > > Maybe I've lost my mind. I think you have. :) > If this is the way it -should-be why isn't it supported? I can only > think of HTML color related issues, and those are surely taken care of > now with the relaxed directive processing? legacy reasons perhaps? > It's very annoying if it is the way "it should be", particularly in > the context of #macro because you can't call macros inline in some > HTML. why not? just put a space before the #macroName. The space will be eaten by WM. eric > > Marc > > -- > Marc Palmer > Contract Java Consultant/Developer > > w a n g j a m m e r s > > java and web software design > experts with an ethical outlook > > http://www.wangjammers.org > |
|
From: Marc P. <ma...@an...> - 2003-07-17 14:49:51
|
On Thu, 17 Jul 2003 15:40:58 +0100, Marc Palmer <ma...@an...> wrote:
>
> Perhaps he means "form thread".
I meant "forum thread".
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-17 14:47:48
|
On Thu, 17 Jul 2003 10:24:43 -0400, Eric B. Ridge <eb...@tc...> wrote:
> On Thursday, July 17, 2003, at 10:18 AM, ke...@su... wrote:
>
>> I'd be surprised if the second case worked in any version of WM -- it's
>> not supposed to. The parser should only recognize a directive that is
>> preceded by whitespace or a newline. (The preceding whitespace and
>> newline are then removed.)
>
> I was thinking the same thing. hasn't it always been like this?
Erm, I don't think so. I am sure I have done:
value="#if (something) ... #end"
...before.
Maybe I've lost my mind.
If this is the way it -should-be why isn't it supported? I can only think
of HTML color related issues, and those are surely taken care of now with
the relaxed directive processing?
It's very annoying if it is the way "it should be", particularly in the
context of #macro because you can't call macros inline in some HTML.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-17 14:43:38
|
On Thu, 17 Jul 2003 16:11:06 +0200 (MEST), Endre Stølsvik
<web...@st...> wrote:
> Understanding that this might be a relevant use-case, I'm just wondering
> if it would be possible to code this slightly different to work
> around/away from having explicit closing/destruction.
>
> Firstly, there's the GC - why can't those objects be collected by it?
The database connections would stay open for too long.
> Then one could get the Connection and close it on every method call,
> instead of at the tool creation and closing it at the tool destruction.
Indeed, but there might be excessive overhead associated with this.
> Also, why do you have to close these? As they're apparently scoped for
> threads, they will simply be reused the next time that same thread will
> render such a page - do you have to do anything explicit with the db
> connection then?
Perhaps he means "form thread".
> | > If I have misunderstood your intentions please forgive me but I would
> | > be sad not to be able to go on to the next release of webmacro.
>
> You probably haven't misunderstood the intention. Unless, of course, I've
> misundestood it too, which is entirely possible! ;)
>
> Also, folks, remeber that this IS supposed to be a "major release", thus
> actually pointing out that "major" things might change.
Of course, but feature regressions are not normally seen in major releases.
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-17 14:24:53
|
On Thursday, July 17, 2003, at 10:18 AM, ke...@su... wrote: > I'd be surprised if the second case worked in any version of WM -- > it's not supposed to. The parser should only recognize a directive > that is preceded by whitespace or a newline. (The preceding > whitespace and newline are then removed.) I was thinking the same thing. hasn't it always been like this? eric > > Keats > > -------Original Message------- > From: Marc Palmer <ma...@an...> > Sent: 07/17/03 08:58 AM > To: web...@li... > Subject: [Webmacro-devel] ACK! Bad new parser bug > >> >> > I haven't synced with Brians latest optimisations, but my CVS is > current > to > Brian's last set of changes and we have a BAAAAAAAAAD bug that has got > in, > > probably in the parser. > > It is not caught by existing tests, so I have added new ones to > TestDirectiveParser, but perhaps they belong in a whitespace test > class. > > Take the following tests: > > assertStringTemplateEquals( "#if (true) ok #end", "ok"); > assertStringTemplateEquals( "x#if (true) ok #end", "xok" ); > > Line 1 completes, but line 2 fails because the output is incorrectly: > > x#if (true) ok #end > > I just found this because I was tracking down some new problems (over > the > last couple of weeks) that had entered my previously OK Ignition > templates. > Calling a macro was outputing the macro call text, not actually calling > the > macro: > > <input name="xxx" value="#myMacro($fld)"> > > That incorrectly outputs: > > <input name="xxx" value="#myMacro($fld.toString value here)"> > > But if you introduce some whitespace it works: > > <input name="xxx" value=" #myMacro($fld)"> > > > So... we have a serious whitespace/parser problem! Possibly related to > relaxed directive parsing changes? > > Who knows. The one thing we know is the head revision of WM is b0rked > at > the moment! > > I'd appreciate it if someone with parser knowledge can look at this as > soon > as possible. Unfortunately this is yet another thing holding up my new > Ignition release :( > > Thanks. > Marc > -- > Marc Palmer > Contract Java Consultant/Developer > > w a n g j a m m e r s > > java and web software design > experts with an ethical outlook > > http://www.wangjammers.org > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel >> > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: <ke...@su...> - 2003-07-17 14:19:02
|
I'd be surprised if the second case worked in any version of WM -- it's not supposed to. The parser should only recognize a directive that is preceded by whitespace or a newline. (The preceding whitespace and newline are then removed.)
Keats
-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 07/17/03 08:58 AM
To: web...@li...
Subject: [Webmacro-devel] ACK! Bad new parser bug
>
>
I haven't synced with Brians latest optimisations, but my CVS is current
to
Brian's last set of changes and we have a BAAAAAAAAAD bug that has got in,
probably in the parser.
It is not caught by existing tests, so I have added new ones to
TestDirectiveParser, but perhaps they belong in a whitespace test class.
Take the following tests:
assertStringTemplateEquals( "#if (true) ok #end", "ok");
assertStringTemplateEquals( "x#if (true) ok #end", "xok" );
Line 1 completes, but line 2 fails because the output is incorrectly:
x#if (true) ok #end
I just found this because I was tracking down some new problems (over the
last couple of weeks) that had entered my previously OK Ignition
templates.
Calling a macro was outputing the macro call text, not actually calling
the
macro:
<input name="xxx" value="#myMacro($fld)">
That incorrectly outputs:
<input name="xxx" value="#myMacro($fld.toString value here)">
But if you introduce some whitespace it works:
<input name="xxx" value=" #myMacro($fld)">
So... we have a serious whitespace/parser problem! Possibly related to
relaxed directive parsing changes?
Who knows. The one thing we know is the head revision of WM is b0rked at
the moment!
I'd appreciate it if someone with parser knowledge can look at this as
soon
as possible. Unfortunately this is yet another thing holding up my new
Ignition release :(
Thanks.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-17 14:18:21
|
Begin forwarded message: > From: bri...@us... > Date: Thu Jul 17, 2003 1:34:02 AM America/New_York > To: web...@li... > Subject: [WebMacro-cvs] webmacro/src/org/webmacro/util > IntMap.java,1.4,NONE QueueWriter.java,1.8,NONE > SimpleStack.java,1.5,NONE SparseArrayIterator.java,1.4,NONE > SparseProperties.java,1.2,NONE > > Update of /cvsroot/webmacro/webmacro/src/org/webmacro/util > In directory sc8-pr-cvs1:/tmp/cvs-serv29972/src/org/webmacro/util > > Removed Files: > IntMap.java QueueWriter.java SimpleStack.java > SparseArrayIterator.java SparseProperties.java > Log Message: > Eliminate misc unused classes Brian, I'm not sure, but I seem to remember Lane mentioning a while back something about using SparseProperties. I don't know if he was talking about this one, or something of his own, or whatever, but I'm mentioning it here so Lane can chime in if he still needs this class. eric > > --- IntMap.java DELETED --- > > --- QueueWriter.java DELETED --- > > --- SimpleStack.java DELETED --- > > --- SparseArrayIterator.java DELETED --- > > --- SparseProperties.java DELETED --- > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Webmacro-cvs mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-cvs |
|
From: <web...@st...> - 2003-07-17 14:18:09
|
On Thu, 17 Jul 2003, Marc Palmer wrote: | On Thu, 17 Jul 2003 15:50:48 +0200 (MEST), Endre St=F8lsvik | <web...@st...> wrote: | | | > | I'd appreciate it if someone with parser knowledge can look at this= as | > soon | > | as possible. Unfortunately this is yet another thing holding up my = new | > | Ignition release :( | > | > You must remember that WM is in a pre-alpha stage now, given Brian's | > large | > overhauls - I don't think its fair to demand "immediate attention" to | > problems that arise in such situations.. Use the proper release inste= ad, | > then. | | You're entirely right, but if you look at my wording there is no "deman= d". | I have done a lot of debugging and some fixing of the new WM code so fa= r as | an "early adopter" which has taken a lot of my time also - it's just no= t as | glamourous as revamping whole parts of WM ;-) I definately know that you've used a helluva time on debugging - early adopting - the new WM, and the Ignition "tool" definately looks interesting too! - I thank all of you main WM developers for the cool product WM is! | | I have added a specific test for this problem. I don't want to spend al= l | day writing new tests... imagine all the bugs we might find ;-) ;-D Endre. |
|
From: <web...@st...> - 2003-07-17 14:11:10
|
On Thu, 17 Jul 2003, Marc Palmer wrote: | | Guys, this is forwarded from a WM user who cannot post to the list for some | reason. | | They require destroyContext, which seems to currently be removed from | Context.java in CVS. | | Will the addDestructor(Destructor d) mechanism work for this? Probably..? | > | > We use this as a guarantee that once a page is rendered all pooled | > resources are cleaned up properly . | > As you can see we use an object mapping tool called vbsf that lazily | > instantiates related classes. If it can't find the object in the | > cache | > it gets a database off a thread table etc. It's imporant for us to | > close | > these. Understanding that this might be a relevant use-case, I'm just wondering if it would be possible to code this slightly different to work around/away from having explicit closing/destruction. Firstly, there's the GC - why can't those objects be collected by it? Then one could get the Connection and close it on every method call, instead of at the tool creation and closing it at the tool destruction. Also, why do you have to close these? As they're apparently scoped for threads, they will simply be reused the next time that same thread will render such a page - do you have to do anything explicit with the db connection then? | | > If I have misunderstood your intentions please forgive me but I would | > be sad not to be able to go on to the next release of webmacro. You probably haven't misunderstood the intention. Unless, of course, I've misundestood it too, which is entirely possible! ;) Also, folks, remeber that this IS supposed to be a "major release", thus actually pointing out that "major" things might change. Endre. |
|
From: Marc P. <ma...@an...> - 2003-07-17 14:10:14
|
On Thu, 17 Jul 2003 15:50:48 +0200 (MEST), Endre Stølsvik
<web...@st...> wrote:
> | I'd appreciate it if someone with parser knowledge can look at this as
> soon
> | as possible. Unfortunately this is yet another thing holding up my new
> | Ignition release :(
>
> You must remember that WM is in a pre-alpha stage now, given Brian's
> large
> overhauls - I don't think its fair to demand "immediate attention" to
> problems that arise in such situations.. Use the proper release instead,
> then.
You're entirely right, but if you look at my wording there is no "demand".
I have done a lot of debugging and some fixing of the new WM code so far as
an "early adopter" which has taken a lot of my time also - it's just not as
glamourous as revamping whole parts of WM ;-)
Unfortunately I can't use the 1.1 release, because features added to WM
since 1.1 are required by Ignition. For example, the new WM ctors that take
a Properties class, improvements to WMServlet to make it more reusable and
so on.
...and besides, if it wasn't for Ignition we would have found a bunch of
bugs for which we now have fixes in most cases, and in all cases new unit
tests for. Ignition, it is hoped, will be a companion/sister project to WM
2.0 to increase WM's user base and as such the two do need to develop
closely together. We can't wait for WM 2.0 to be ready and then start
developing Ignition 1.0.
I'm just asking for some help with the parser bug because that is a very
complex area, and if it's in the parser .jj file then there's a hell of a
lot of a learning curve for me to fix it. I already spent days learning
about and fixing an old PropertyOperatorCache bug.
It should be an easy fix for someone with knowledge in the parser area, and
if we know what files it is likely to be in we can diff them to find it.
My plea for help as soon as possible is because these things can take weeks
for someone to fix if it's not regarded as important - like the 5 unit test
failures in TestParseInclude that have been there for a long time.
The thing is this bug should really have been caught by unit tests because
it is such a fundamental parser issue, but it's so hard to cover all the
bases with tests.
I have added a specific test for this problem. I don't want to spend all
day writing new tests... imagine all the bugs we might find ;-)
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: <web...@st...> - 2003-07-17 13:50:54
|
On Thu, 17 Jul 2003, Marc Palmer wrote: | | I haven't synced with Brians latest optimisations, but my CVS is current to | Brian's last set of changes and we have a BAAAAAAAAAD bug that has got in, | probably in the parser. | .. | I'd appreciate it if someone with parser knowledge can look at this as soon | as possible. Unfortunately this is yet another thing holding up my new | Ignition release :( You must remember that WM is in a pre-alpha stage now, given Brian's large overhauls - I don't think its fair to demand "immediate attention" to problems that arise in such situations.. Use the proper release instead, then. Endre. |
|
From: Marc P. <ma...@an...> - 2003-07-17 13:00:19
|
I haven't synced with Brians latest optimisations, but my CVS is current to
Brian's last set of changes and we have a BAAAAAAAAAD bug that has got in,
probably in the parser.
It is not caught by existing tests, so I have added new ones to
TestDirectiveParser, but perhaps they belong in a whitespace test class.
Take the following tests:
assertStringTemplateEquals( "#if (true) ok #end", "ok");
assertStringTemplateEquals( "x#if (true) ok #end", "xok" );
Line 1 completes, but line 2 fails because the output is incorrectly:
x#if (true) ok #end
I just found this because I was tracking down some new problems (over the
last couple of weeks) that had entered my previously OK Ignition templates.
Calling a macro was outputing the macro call text, not actually calling the
macro:
<input name="xxx" value="#myMacro($fld)">
That incorrectly outputs:
<input name="xxx" value="#myMacro($fld.toString value here)">
But if you introduce some whitespace it works:
<input name="xxx" value=" #myMacro($fld)">
So... we have a serious whitespace/parser problem! Possibly related to
relaxed directive parsing changes?
Who knows. The one thing we know is the head revision of WM is b0rked at
the moment!
I'd appreciate it if someone with parser knowledge can look at this as soon
as possible. Unfortunately this is yet another thing holding up my new
Ignition release :(
Thanks.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-17 09:55:19
|
Guys, this is forwarded from a WM user who cannot post to the list for some
reason.
They require destroyContext, which seems to currently be removed from
Context.java in CVS.
Will the addDestructor(Destructor d) mechanism work for this?
------- Forwarded message -------
From: Nick Sanderson <NSa...@ms...>
To: <ma...@an...>
Subject: Hi Marc
Date: Thu, 17 Jul 2003 09:14:41 +0100
> Hi Marc
>
> I'm afraid I my mail server won't seem to mail direct to the
> development lists but you seem very active so I hope you don't mind me
> writing directly to you.
>
> I may be misunderstanding this but there seems to be a suggestion no
> longer want to support context.destroy() as nobody uses it.
> I use this all the time in the framework that we use at work.
> Any pooled resources are automatically added to the context and then
> checked and destroyed in the context destroy call.
> For example - from one of our several large web applications that use
> this aproach (and webmacro :) )
>
>
>
> public void destroyContext(WebContext webContext) throws
> HandlerException
> {
> siteServices.runDestroy(webContext);
> Database db = Server.getCurrentThreadDatabase();
> try
> {
>
> if (db != null) {
> category.debug("Closing connection on server");
> db.close();
> }
> }
> catch (BODBException e)
> {
> log.error("Error closing database",e);
> }
> try
> {
> PooledHttpForm f = (PooledHttpForm)
> webContext.get(FORM_KEY);
> if (f != null)
> {
> f.close();
> }
> }
> catch (Exception e)
> {
> log.error("Pooled Form error",e);
> }
> finally
> {
> super.destroyContext(webContext);
> }
>
>
> }
>
> We use this as a guarantee that once a page is rendered all pooled
> resources are cleaned up properly .
> As you can see we use an object mapping tool called vbsf that lazily
> instantiates related classes. If it can't find the object in the
> cache
> it gets a database off a thread table etc. It's imporant for us to
> close
> these.
> If I have misunderstood your intentions please forgive me but I would
> be sad not to be able to go on to the next release of webmacro.
> Regards
> Nick Sanderson
>
>
> This Message has been Checked at MSXI for all known Viruses.
> You open this at your own risk. Please make sure all replies are also
> virus free.
> Also we do not accept or send Attachments of the type .exe, .vbs,
> scr, or .bat due to the virus risk they can contain. These types of
> attachments will be stripped from the message.
>
> MSXI
>
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: <web...@st...> - 2003-07-17 07:39:52
|
On Wed, 16 Jul 2003, Marc Palmer wrote: | On Wed, 16 Jul 2003 09:51:57 -0700, Brian Goetz <br...@qu...> wrote: | | >> How about a totally trivial solution. Add a new method to ContextTool: | >> | >> | >> boolean isDestroyRequired(); | >> | >> CTs implement this and return true if they want their destroy() called. | >> This way we have a complete contract for it - implement destroy() | >> accordingly if you return true from isDestroyRequired, and if you never | >> need it just return false and don't do anything in destroy(). | > | > You are missing the hard part -- how does the Context know when its | > done? The question is whether we have to make the user explicitly | > destroy the context, which I don't want to force all users to do just | > because some tools I've never seen want this. | | Hmmm, well why not have explicity Context "close()" paradigm? It's standard | resource allocation stuff. Worst case scenario, we end up with the GC | collecting the Context and close() getting called implicitly from the | finalizer. | | That's a worst case the same as what we have now (no recycle() method any | more), and a best case where the programmer reads the docs and calls | context.close() in a finally block just like they close streams. | | I don't see a problem here. Either way it will go away eventually, and for | those of us with brain cells, it will go away quickly. It is annoying. try-finallies are very, very annoying. And I do agree totally with Brian that as long as there aren't any good reasons for having it (a proper use case or ten), then it is "unfair" forcing me to do resource-deallocation that will most often be totally useless. Endre. |
|
From: Brian G. <br...@qu...> - 2003-07-17 05:25:44
|
I've eliminated all the classes associated with pooling and profiling. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 19:52:32
|
On Wednesday, July 16, 2003, at 03:44 PM, Brian Goetz wrote:
>
>> what about when template.write() throws an exception?
>
> public void write(Writer w, Context c) {
> c.beginEval();
> try {
> // do the expansion
> }
> finally {
> c.endEval();
> }
> }
okay, so it cleans up wether the .write() was successful or not? hmm.
eric
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 19:47:24
|
On Wednesday, July 16, 2003, at 03:45 PM, Brian Goetz wrote: > >> and what if, in a standalone environment, you want to use the same >> Context to .write() a bunch of templates? > > The use of the reference count was to support things like #include, > where in the course of expanding one template you want to expand a > subtemplate. > > So in the case above, you'd have a few choices. The first would be do > nothing, in which case the tool gets reinitalized and destroyed on > each evaluation, which might be OK. The second would be to bracket > the series of calls with beginEval/endEval. fair enough. eric |
|
From: Brian G. <br...@qu...> - 2003-07-16 19:46:06
|
>and what if, in a standalone environment, you want to use the same Context >to .write() a bunch of templates? The use of the reference count was to support things like #include, where in the course of expanding one template you want to expand a subtemplate. So in the case above, you'd have a few choices. The first would be do nothing, in which case the tool gets reinitalized and destroyed on each evaluation, which might be OK. The second would be to bracket the series of calls with beginEval/endEval. Again, the use of the begin/end are optional in the sense that they only affect the behavior of "stateful" tools. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Brian G. <br...@qu...> - 2003-07-16 19:44:16
|
>what about when template.write() throws an exception?
public void write(Writer w, Context c) {
c.beginEval();
try {
// do the expansion
}
finally {
c.endEval();
}
}
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 19:43:05
|
On Wednesday, July 16, 2003, at 03:40 PM, Eric B. Ridge wrote: > what about when template.write() throws an exception? and what if, in a standalone environment, you want to use the same Context to .write() a bunch of templates? eric |
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 19:40:27
|
On Wednesday, July 16, 2003, at 03:38 PM, Brian Goetz wrote: > >> But seriously, how about cleanupTools()? > > A better name. > > Here's a thought that occurred to me on the drive over to work (see, > traffic is good for something.) > > We have an implicit bracketing of "use the context" in > Template.write() and Template.evaluate(). So how about adding the > following to Context: > > - addCleanupHandler (added by tools which need cleanup) > - beginEval (used ONLY by Template.write/evaluate) > - endEval (used ONLY by Template/write/evaluate) > > beginEval would increment a count, endEval would decrement it -- when > the count reached zero, cleanup handlers would be called. Since the > open/close calls would live only in Template.write and > Template.evaluate, users need not worry about it at all. But we'd > still get automatic cleanup of things registered with the context, > with the user having to be involved. what about when template.write() throws an exception? eric |
|
From: Brian G. <br...@qu...> - 2003-07-16 19:39:03
|
>But seriously, how about cleanupTools()? A better name. Here's a thought that occurred to me on the drive over to work (see, traffic is good for something.) We have an implicit bracketing of "use the context" in Template.write() and Template.evaluate(). So how about adding the following to Context: - addCleanupHandler (added by tools which need cleanup) - beginEval (used ONLY by Template.write/evaluate) - endEval (used ONLY by Template/write/evaluate) beginEval would increment a count, endEval would decrement it -- when the count reached zero, cleanup handlers would be called. Since the open/close calls would live only in Template.write and Template.evaluate, users need not worry about it at all. But we'd still get automatic cleanup of things registered with the context, with the user having to be involved. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
237 messages has been excluded from this view by a project administrator.
