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-15 21:07:56
|
>right, but isn't there still special logic in Context.java in .get() that >says "oh, we don't have <keyname>, let me see if we have a ContextTool by >that name"? Yes, there is. Now it asks the Broker instead of the context (which is a big win because now the context starts out truly empty, instead of populated with tools.) But that's really it for special tool logic. There's no way to add a tool to the context -- you only get the tools loaded through the broker's configuration. Of course, you can put objects in the context. -- 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-15 21:03:23
|
On Tuesday, July 15, 2003, at 04:55 PM, Brian Goetz wrote:
>> Can we simply get rid of ContextTools completely?
>>
>> I've always found ContextTools to be too limiting to be useful. In
>> many cases, I've wanted CT's (specified via wm.properties) to have
>> access to my application data. Using the Context as a means to
>> communicate back to my application seemed like a hack, so I just end
>> up doing this:
>>
>> context.put ("MyGreatTool", new MyGreatTool (_app));
>>
>> So I think we should just nuke CT's completely. Eliminates the need
>> to worry about if/when/how they're destroyed or gc'd.
>
> All of the tools that are in the WM distro are basically repositories
> for functions -- they require little initialization and teardown and
> have little state.
>
> So in some sense, the current refactor "demotes" them in that
> direction.
right, but isn't there still special logic in Context.java in .get()
that says "oh, we don't have <keyname>, let me see if we have a
ContextTool by that name"?
All of this could go away too, if we just dropped ContextTools.
eric
|
|
From: Brian G. <br...@qu...> - 2003-07-15 20:56:10
|
>Can we simply get rid of ContextTools completely?
>
>I've always found ContextTools to be too limiting to be useful. In many
>cases, I've wanted CT's (specified via wm.properties) to have access to my
>application data. Using the Context as a means to communicate back to my
>application seemed like a hack, so I just end up doing this:
>
> context.put ("MyGreatTool", new MyGreatTool (_app));
>
>So I think we should just nuke CT's completely. Eliminates the need to
>worry about if/when/how they're destroyed or gc'd.
All of the tools that are in the WM distro are basically repositories for
functions -- they require little initialization and teardown and have
little state.
So in some sense, the current refactor "demotes" them in that direction.
--
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-15 20:26:51
|
On Tuesday, July 15, 2003, at 03:46 PM, Brian Goetz wrote:
>>> I think we need some solid use cases first, and then can come up
>>> with a strategy. Care to describe what your current tools do?
>>
>> Just because we haven't written X doesn't mean we shouldn't allow X
>> to work well.
>
> Only if we have already
> - agreed what X is AND
> - agreed that X is something we want to work well.
Here's a thought.
Can we simply get rid of ContextTools completely?
I've always found ContextTools to be too limiting to be useful. In
many cases, I've wanted CT's (specified via wm.properties) to have
access to my application data. Using the Context as a means to
communicate back to my application seemed like a hack, so I just end up
doing this:
context.put ("MyGreatTool", new MyGreatTool (_app));
So I think we should just nuke CT's completely. Eliminates the need to
worry about if/when/how they're destroyed or gc'd.
I also think that the only real useful ContextTools that come w/ WM are
$Form and $Type... both of which could be used just as easily via
$topLevelFunctions() (I think $Type is already a top level function).
eric
>
> Right now, it all feels very abstract to me. The fact that I've not
> yet seen a use case that needs it argues that it may well be needless
> abstraction.
>
>> +1 for getting rid of destroy(), but only if it is replaced with a
>> listener mechanism so that CTs can be told when they are no longer
>> needed by WM, without waiting for GC.
>
> Bear in mind that these mechanisms have a cost. You have to keep
> track of your listeners, and you force users into a mode of explicit
> deallocation. I don't want users to have to call Context.destroy -- I
> want to let it get garbage collected.
>
>> -1 for getting rid of destroy() without a replacement. finalizers
>> are not good enough. Components must have the opportunity to tap into
>> their lifecycle.
>
> Lifecycles really only make sense for long-lived objects, like
> Brokers. Contexts should not have a lifecycle -- the overhead of
> maintaining and managing it is too great.
>
>> I think the listener approach gives us the compromise we desire -
>> better performance while retaining useful functionality.
>
> I think you underestimate the cost of the listener approach -- its
> pretty much the whole recycling/pooling crap we want to get rid of.
>
>
>
> --
> Brian Goetz
> Quiotix Corporation
> br...@qu... Tel: 650-843-1300 Fax:
> 650-324-8032
>
> http://www.quiotix.com
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
|
|
From: Brian G. <br...@qu...> - 2003-07-15 20:16:44
|
>>I think we need some solid use cases first, and then can come up with a >>strategy. Care to describe what your current tools do? > >Just because we haven't written X doesn't mean we shouldn't allow X to >work well. Only if we have already - agreed what X is AND - agreed that X is something we want to work well. Right now, it all feels very abstract to me. The fact that I've not yet seen a use case that needs it argues that it may well be needless abstraction. >+1 for getting rid of destroy(), but only if it is replaced with a >listener mechanism so that CTs can be told when they are no longer needed >by WM, without waiting for GC. Bear in mind that these mechanisms have a cost. You have to keep track of your listeners, and you force users into a mode of explicit deallocation. I don't want users to have to call Context.destroy -- I want to let it get garbage collected. >-1 for getting rid of destroy() without a replacement. finalizers are not >good enough. Components must have the opportunity to tap into their lifecycle. Lifecycles really only make sense for long-lived objects, like Brokers. Contexts should not have a lifecycle -- the overhead of maintaining and managing it is too great. >I think the listener approach gives us the compromise we desire - better >performance while retaining useful functionality. I think you underestimate the cost of the listener approach -- its pretty much the whole recycling/pooling crap we want to get rid of. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Marc P. <ma...@an...> - 2003-07-15 19:35:45
|
On Tue, 15 Jul 2003 11:47:27 -0700, Brian Goetz <br...@qu...> wrote:
> Here's some alternatives:
> - have each method in the tool acquire and release the resources it needs
> within the call. That way, no cleanup is needed.
> - Use finalizers in tools that need cleanup. That's ugly, but its at
> least a last-ditch safety net.
>
> I think we need some solid use cases first, and then can come up with a
> strategy. Care to describe what your current tools do?
Just because we haven't written X doesn't mean we shouldn't allow X to work
well.
+1 for getting rid of destroy(), but only if it is replaced with a listener
mechanism so that CTs can be told when they are no longer needed by WM,
without waiting for GC.
-1 for getting rid of destroy() without a replacement. finalizers are not
good enough. Components must have the opportunity to tap into their
lifecycle.
I think the listener approach gives us the compromise we desire - better
performance while retaining useful functionality.
--
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: Brian G. <br...@qu...> - 2003-07-15 19:26:27
|
>Excellent, we use log4j here at CoreTrek in our portal server! ;) But >maybe consider a "pluggable" logging solution, so that not only me get my >"native" logging system. Have you had a look at Apache's Commons Logging >package? Apparently that's supposed to be some kind of "shim" between the >application and a logging system. WM already has a "pluggable" logging system. There's a simple logging implementation, and for Brokers that are servlet-aware, it redirects logging to the servlet logger. I'd kind of like to have the default for standalone WM instances be NO logging. Its pretty annoying when you create a WM and get a flood of logging crap to standard out. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: <web...@st...> - 2003-07-15 19:22:27
|
On Tue, 15 Jul 2003, Brian Goetz wrote: | | >Could you also get rid of all threads while you're at it? ;) The | >System.currentMills() super-thread for improving loggingspeed or | >-whatever- it does should be killed. WM is a library, and threads being | >created here and there w/o me wanting it is annoying! | | That's on my list of things to talk about next. My inclination is to ditch | WM's logging system entirely and move to log4j -- but this will require | some discussion. Excellent, we use log4j here at CoreTrek in our portal server! ;) But maybe consider a "pluggable" logging solution, so that not only me get my "native" logging system. Have you had a look at Apache's Commons Logging package? Apparently that's supposed to be some kind of "shim" between the application and a logging system. There is already some logging systems that have the integration part done, specifically log4j, jdk14 logging and the Apache Avalong LogKit. http://jakarta.apache.org/commons/logging.html -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Keats <ke...@ea...> - 2003-07-15 19:11:30
|
----- Original Message ----- > > ditch WM's logging system entirely and move to log4j > > great idea! I agree -- we don't need to support yet another logging framework (YALF?). It would be nice if we could keep it loosely coupled enough to support JDK1.4 logging or other alternatives as well, but log4j is good enough for me. Keats |
|
From: Eric B. R. <eb...@tc...> - 2003-07-15 18:59:17
|
On Tuesday, July 15, 2003, at 02:48 PM, Brian Goetz wrote: > ditch WM's logging system entirely and move to log4j great idea! eric |
|
From: Brian G. <br...@qu...> - 2003-07-15 18:49:28
|
>Could you also get rid of all threads while you're at it? ;) The >System.currentMills() super-thread for improving loggingspeed or >-whatever- it does should be killed. WM is a library, and threads being >created here and there w/o me wanting it is annoying! That's on my list of things to talk about next. My inclination is to ditch WM's logging system entirely and move to log4j -- but this will require some discussion. -- 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-15 18:49:10
|
>Perhaps we can come up with a better way of handling this, like a >ContextUnbindListener so that tools can register themselves if they need to >be notified when the context is finished with them? I'm open to that. Right now, the context keeps a list of tools its initialized, and then relies on clear() getting called to call the dtors of those tools. It increases the cost of creating and destroying the context, and undermines garbage collection as it keeps extra references around. Here's some alternatives: - have each method in the tool acquire and release the resources it needs within the call. That way, no cleanup is needed. - Use finalizers in tools that need cleanup. That's ugly, but its at least a last-ditch safety net. I think we need some solid use cases first, and then can come up with a strategy. Care to describe what your current tools do? -- 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-15 18:46:11
|
>Also, won't leaving context tool cleanup to the GC possibly leave some >things dangling / make CTs harder to write? i.e. imagine a CT that opens a >file and closes it in cleanup... Yes, but this is a mostly theoretical concern. Of the 10 or so context tools in the WM distro, only 1 had a non-empty destroy() method, and that one was only needed to recycle a Context, which is no longer needed as these are now garbage collected. So in the odd case you talk about, use finalizers, but so far, none have needed to. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: <web...@st...> - 2003-07-15 18:23:19
|
On Tue, 15 Jul 2003, Brian Goetz wrote: | I'm thinking of pruning Justin's home-grown profiling mechanism. It | seems pretty intrusive and certainly adds a lot of code. Any | objections? None at all! | | I've removed the pooling of contexts and am almost done with the | pooling of FastWriters (which are now internal.) I removed the ascii | hack from FW (since its now no longer exposed anyway.) Excellent! | | I've removed the explicit cleanup of context tools and am letting | garbage collection do that for us. I pushed tools loading into the | Broker; as a result, the Context got a lot lighter-weight. | | I'm working on removing the reference counting of Brokers and am | hoping to be able to let garbage collection do it all for us. I don't feel GC'ing should take care of open files, DB connections etc, such resources should have explicit life cycles. | | Then I'll replace ScalableMap with ConcurrentHashMap and I should be | done for this round of refactoring, leaving us with a much slimmer, | easier to navigate WM. This sounds fantastic. Could you also get rid of all threads while you're at it? ;) The System.currentMills() super-thread for improving loggingspeed or -whatever- it does should be killed. WM is a library, and threads being created here and there w/o me wanting it is annoying! Endre. |
|
From: Keats <ke...@ea...> - 2003-07-15 18:01:18
|
> I've removed the explicit cleanup of context tools and am letting > garbage collection do that for us. I pushed tools loading into the > Broker; as a result, the Context got a lot lighter-weight. I'm not sure about removing the call to destroy(). I don't think any of the standard tools need this, but I've built at least one custom tool that relies on this to release database connections. Perhaps we can come up with a better way of handling this, like a ContextUnbindListener so that tools can register themselves if they need to be notified when the context is finished with them? Keats |
|
From: Keats <ke...@ea...> - 2003-07-15 17:47:39
|
> I'm thinking of pruning Justin's home-grown profiling mechanism. It > seems pretty intrusive and certainly adds a lot of code. Any > objections? +1 The profiling stuff is a real kludge -- gut it! Keats |
|
From: Marc P. <ma...@an...> - 2003-07-15 17:40:01
|
On Tue, 15 Jul 2003 10:06:57 -0700, Brian Goetz <br...@qu...> wrote:
> I'm thinking of pruning Justin's home-grown profiling mechanism. It
> seems pretty intrusive and certainly adds a lot of code. Any
> objections?
>
> I've removed the pooling of contexts and am almost done with the
> pooling of FastWriters (which are now internal.) I removed the ascii
> hack from FW (since its now no longer exposed anyway.)
>
> I've removed the explicit cleanup of context tools and am letting
> garbage collection do that for us. I pushed tools loading into the
> Broker; as a result, the Context got a lot lighter-weight.
>
> I'm working on removing the reference counting of Brokers and am
> hoping to be able to let garbage collection do it all for us.
>
> Then I'll replace ScalableMap with ConcurrentHashMap and I should be
> done for this round of refactoring, leaving us with a much slimmer,
> easier to navigate WM.
Nice! This sounds like great stuff.
Will you be doing performance comparisons before putting it back into CVS?
Also, won't leaving context tool cleanup to the GC possibly leave some
things dangling / make CTs harder to write? i.e. imagine a CT that opens a
file and closes it in cleanup...
I await enlightenment, and really appreciate your efforts to refine WM :)
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: Brian G. <br...@qu...> - 2003-07-15 17:07:09
|
I'm thinking of pruning Justin's home-grown profiling mechanism. It seems pretty intrusive and certainly adds a lot of code. Any objections? I've removed the pooling of contexts and am almost done with the pooling of FastWriters (which are now internal.) I removed the ascii hack from FW (since its now no longer exposed anyway.) I've removed the explicit cleanup of context tools and am letting garbage collection do that for us. I pushed tools loading into the Broker; as a result, the Context got a lot lighter-weight. I'm working on removing the reference counting of Brokers and am hoping to be able to let garbage collection do it all for us. Then I'll replace ScalableMap with ConcurrentHashMap and I should be done for this round of refactoring, leaving us with a much slimmer, easier to navigate WM. |
|
From: Marc P. <ma...@an...> - 2003-07-14 17:43:20
|
On Mon, 14 Jul 2003 13:26:50 -0400, Keats <ke...@ea...> wrote:
> [Hey all. I'm just returning from vacation an trying to catch up.]
>
> I can look at this again. I spent some time on this a while back, but I
> was
> unable to create a simple test case that consistently reproduced the
> problem. Now that we apparently have one, I'll poke at it a bit.
Pah! Apparently eh?! It's 100% verbatim man!
I was thinking about replacing all Vector usage with ArrayList in there
which -should-give us some performance benefits because ArrayList is not
synchronised, but I am wary of this now, because I am not sure how/if
access to PropertyOperatorCache is synchronized - and that perhaps POC is
taking advantage of Vector's synchro.
Keats - I can show you where the problem is in the code:
PropertyOperatorCache.java line 892:
// if we're at the binary-settable parent, try direct first
if (pos == binPos)
{
// try direct -- move to direct parent and try from there
Object parent = null;
try
{
parent = getProperty(context, instance, names, pos, pos);
The above line is the problem. For binary set (versus hash put) this line
is broken. If you change the "end" parameter to "pos + 1" then binary set
will work because getProperty will successfully find the property.
However if you do that, hash "put" breaks - watch the unit test TestGetSet
to see it break if you put the +1 in, whereas TestBinaryAccessor will run
fine with the "+1" in.
It's "well nasty".
For what it's worth I really think if we could come up with a better design
for POC we would get some serious performance wins. Currently it often does
lots of complex "get" operations when you do a binary "set" - just to see
if the property exists.
I'm not sure all of these are needed, but I appreciate that the dynamic
nature of property resolution means that a lot of the time this is
required. However, most of the "set" code relies on exceptions not
occurring, rather than the result of the "get"s which makes me think that
we can get some performance wins here.
Also, binary "set" is slow according to the docs as it always expects and
exception to occur, and then just swallows it.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
* Available For Hire *
See my CV at http://www.anyware.co.uk/marc/
|
|
From: Keats <ke...@ea...> - 2003-07-14 17:26:57
|
[Hey all. I'm just returning from vacation an trying to catch up.] I can look at this again. I spent some time on this a while back, but I was unable to create a simple test case that consistently reproduced the problem. Now that we apparently have one, I'll poke at it a bit. Keats ----- Original Message ----- From: "Marc Palmer" <ma...@an...> To: <web...@li...> Sent: Friday, July 11, 2003 8:37 PM Subject: Re: [Webmacro-devel] Help - the binary operator bug is weird > On Sat, 12 Jul 2003 01:22:27 +0100, Marc Palmer <ma...@an...> wrote: > > > > > My guess is that the search for setMyProp is failing, and it is using > > put() . The getMyProp is also failing, and it is using get() instead, and > > this is hiding the bug that I have found, because the script appears to > > work but it is not doing that the test intended. The test needs > > improvement. I will see if I can do this. > > ROFL. I'm completely talking out of my arse here - please forgive me. > > It's "not possible" for the above to occur, because put would only be able > to set "Parameters" to a value, not "Parameters.Name", or at least that's > what my frazzled brain is currently telling me. > > I'm still completely clueless about this bug. > > > -- > Marc Palmer > Contract Java Consultant/Developer > > * Available For Hire * > > See my CV at http://www.anyware.co.uk/marc/ > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Keats <ke...@ea...> - 2003-07-14 17:23:05
|
...
> For example, I discovered (partly to my horror) that WM supports
> "PropertyMethod" - a way of getting a property NAME from a function:
>
> #set $propnameProvider.SomeProp = "marc"
> #set $var = $propnameProvider.get("SomeProp").SomeOtherProp
>
> This looks somewhat bizarre and horrendous to me. Does -anybody-actually
> use it?
>
I'm not sure what you're talking about. Do you mean the .get()? If so,
this is what is known as the "round bracket hack" and it is necessary to
deal with dynamic property names ($var.get($propName)) or non-compliant
property names ($var.get("Some wacky property!?@#$%!")).
[BTW, AFAICT, the above code will fail since the string "marc" doesn't have
a "SomeOtherProp".]
Keats
|
|
From: Marc P. <ma...@an...> - 2003-07-14 17:11:42
|
On Mon, 14 Jul 2003 17:48:01 +0100, Marc Palmer <ma...@an...> wrote:
> #set $propnameProvider.SomeProp = "marc"
> #set $var = $propnameProvider.get("SomeProp").SomeOtherProp
>
> This looks somewhat bizarre and horrendous to me. Does -anybody-actually
> use it?
Let me clarify that example - the WM docs for PropertyMethod say that the
above code is basically equivalent to:
#set $var = $propnameProvider.marc.SomeOtherProp
Which looks an ambiguity from beyond hell to me, in terms of:
#set $var = $propnameProvider.get("SomeProp").SomeOtherProp
...is get("SomeProp") going to get me an object that I can use to read
SomeOtherProp, or is it going to get me an object to use as a Name for a
property on which I can get SomeOtherProp. It seems quite obscure.
--
Marc Palmer
Contract Java Consultant/Developer
* Available For Hire *
See my CV at http://www.anyware.co.uk/marc/
|
|
From: Marc P. <ma...@an...> - 2003-07-14 16:49:15
|
Hi,
I'm trying to find a solution to this longstanding binary operator set bug
in WM.
It is painfully difficult to modify PropertyOperatorCache. It's a very
important part of WM and it is bordering on unmaintainable due to the
complex interactions and recursion that occurs to attempt to locate direct
or binary accessors.
I really think this needs to be reshaped for 2.0 - and I'd like to be able
to do it myself (right now, because I really need this bug fixed) but I
just don't have the in-depth knowledge of WM to get this right.
For example, I discovered (partly to my horror) that WM supports
"PropertyMethod" - a way of getting a property NAME from a function:
#set $propnameProvider.SomeProp = "marc"
#set $var = $propnameProvider.get("SomeProp").SomeOtherProp
This looks somewhat bizarre and horrendous to me. Does -anybody-actually
use it?
Marc
--
Marc Palmer
Contract Java Consultant/Developer
* Available For Hire *
See my CV at http://www.anyware.co.uk/marc/
|
|
From: Marc P. <ma...@an...> - 2003-07-14 09:47:54
|
Hi, I just committed an updated TestParseInclude that shows the new bug where #include as macro results in the template name being output to the stream. I also added the bug to the SF bug tracker. As far as I know this didn't occur prior to Brian's changes to hide FastWriter, and I've shown where the output is occurring but I don't know whether: * Blockbuilder should never be getting a Template object in its list of elements, and somehow this is now happening * Blockbuilder should be detecting elements that are Templates and not calling .toString on them, calling getString instead (I doubt this - the previous revs in CVS show no such code, and the meaning of Template.toString has not changed as far as I can see) I'd appreciate any help on this issue - it seems to be a very obtuse issue, and all you folks who use #include as macro better listen up because the current CVS head will -not-be want you want! Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
|
From: Marc P. <ma...@an...> - 2003-07-14 09:06:14
|
On Mon, 14 Jul 2003 10:31:56 +0200 (CEST), Endre Stølsvik <web...@st...> wrote: > On Fri, 11 Jul 2003, Marc Palmer wrote: > > | > | I've updated NextRelease to start honing the list of real 2.0 > requirements: > | > | http://www.webmacro.org/NextRelease > > Is this the top part, "Agreed..."? > > Does this mean that (most of) my suggestions didn't make it? NO! It means "agreed so far". As I said, we can keep moving stuff up when there is concensus that they should be part of it. > Especially, I'd like all "magic threads" and stuff to go away, and to > have rendering options (I'd like my output to appear as it is rendered.. - > I > believe it now is cached, and not ouput before everything is cached? At > least I remember that original WM guy did something like this once.. I think this is more likely to be FastWriter. FW is still there, it is just hidden. I you have specific issues you want to raise for 2.0 then I suggest you taken them over to the DeveloperVotes page and get people to vote on them. It seems to be about the only way to get things moving around here... > And btw, why doesn't this page: http://www.webmacro.org/WhatIsWebMacro > credit that guy for inventing the WM language and the initial tech etc. > etc. ...because it was a page that someone wrote without putting it in there. It may even be Justin who wrote the page. Marc -- Marc Palmer Contract Java Consultant/Developer * Available For Hire * See my CV at http://www.anyware.co.uk/marc/ |
237 messages has been excluded from this view by a project administrator.
