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: Keats <ke...@su...> - 2003-07-26 22:06:28
|
Marc, #macro's don't have a separate context, but #templets do, so you
could easily do what you are trying to do with a #templet/#eval. Check
it out -- I haven't gotten any feedback on this yet.
(I'm not trying to say it's better; it's just different. #macro's are
generally faster while #templet's may be easier to understand.)
Keats
Brian Goetz wrote:
>>I've just spent a long time tracking down an obscure template bug, caused
>>by the non-intuitive way #macro works.
>
>
>>...even though there is never an assignment to $fieldValue in the macro.
>>This is caused by the usage of the variable $value inside the macro, which
>>is inadvertently clashing with the global scope $value - it is of course
>>supposed to be a local variable, which is not supported by #macro.
>
>
> You can't possibly think that its a local value, could you? Have you
> ever written a macro in C? The semantics of WM's #macro are totally
> modeled on that. THey are expanded at runtime. There are no
> macro-scoped variables, or any other sort of local variables in WM.
>
> Every well-written C macro uses names like __value instead of value to
> avoid capture problems.
>
> I agree that this is a more subtle capture problem than usual, but the
> core of thie problem is that any macro that does this:
>
> #set $value = "blah"
>
> is asking for problems.
>
> The reason for the pass-by-reference is that macro expansion should be
> transparent -- variables that are passed in as l-values can be
> l-values in the macro body. Otherwise, macros would just be
> functions.
>
> So you can do this:
>
> #macro mset($a, $b) {
> #set $a = $b
> }
>
> and the expected thing happens. By the way, the above is immune to
> this particular capture problem:
>
> #macro mset($a, $b) {
> #set $a = $b
> }
>
> #set $a=1
> #set $b=2
> #set $c=3
> #set $d=4
> #mset($c, $d)
>
> After execution, $a will _not_ be modified -- beacuse $a in the mset
> body is a macro formal, not the $a in the global context. The result
> will be a=1, b=2, c=4, d=4. So you can use any names you like for
> macro formals without fear of capture.
>
> BTW, macros do all sorts of cool compile time optimization, too, since
> they are expanded against the build context. So with
>
> #const debug=false
> #macro foo {
> #if (debug) { blah blah blah }
> }
>
> ...
>
> Ya ya #foo ya
>
> the #foo reference gets totally eaten at compile time and doesn't even
> make it into the compiled template -- it is totally optimized away.
>
>
>>I'm not sure what we can do about this. I mistakenly thought #macro would
>>have a separate context for its arguments, and as such changes to an outer
>>variable would not suddently change the value of a differently named
>>parameter to the macro.
>
>
> Nope, not how it works, nor how it was intended to work -- otherwise
> you couldn't have macros that modified their arguments.
>
>
>>So, is this a bug or a "feature"?
>
>
> Feature. Just like C macros. If you intend to have local variables,
> name them in such a way as to never conflict, just like in C.
>
> Macro-local variables would be nice -- want to add them?
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
|
|
From: Keats <ke...@su...> - 2003-07-26 21:57:05
|
There are so many points to respond to here it's a bit daunting but let me mention a couple things. Marc, I think you have missed a crucial part of the ContextTool mechanism. ContextTool *is* a lazy loading factory mechanism. The init() method is not void; it returns an object. Many tools just return themselves, but this is just a convenience. A context tool provides arbitrary objects to the context, which may or may not have "context awareness". I see three major shortcomings to the ContextTool mechanism: 1) Tools can only be configured through properties and can't be dynamically deployed. This can be easily fixed using a the ConcurrentMap. 2) A ContextTool implementation (factory) class gets instantiated on each request in which it is referenced. Although they are generally lightweight classes, this is still unnecessary overhead. Factories should generally be static. This should be easy to fix as well. 3) ContextTools are too magical, i.e, it's not clear to a developer/scripter what's available and how to use them. This was a primary motivation for developing the #beam mechanism. But the bean mechanism is flawed as well. A #bean basically does two things that should be separate: Configuring an object and pulling the object into the context. Most people seem to agree that configuring the object should not happen in the template. On the other hand creating the reference to the object probably *should* happen in the template. This makes it clear to the template developer that these things are there and will be used in the template. So maybe the answer to problem 3) is to require tools to be declared in the template before they are used. Maybe a directive like #tool, or #import, or #use. E.g., #use $Math or #use "MathTool" as $Math or something and then, $Math would get put into the context (assuming that MathTool had been deployed to the app previously somehow). This would simplify the context logic: get() wouldn't need to know about tools at all. And templates would become more readable. On the downside, lot's of old templates would break and some people might be annoyed at having to declare commonly used tools in every template. The latter problem could be mitigated by #including "header" templates that declare common tools (like $Request, $Response, $Session, $Form, etc.). To deal with the backwards-compatability issue we could allow users to define "AutoLoadingTools" which get put into every context. This would be less efficient than the current mechanism, but it wouldn't be too bad and it would ease the transition to the new paradigm. What do y'all think? Keats |
|
From: Eric B. R. <eb...@tc...> - 2003-07-26 20:56:44
|
Been thinking about this more, and here's yet another different
approach.
My main issue swith ContextTools are: 1) they're configuration options,
2) definition of which tools are available is hard to find, 3) and WM
has some magical code to handle them.
Keats said something in an earlier post that got me thinking: "Why
would we want to load every tool into every request when nothing is
referencing it?"
You wouldn't. That's a given. But what if a template could define
which tools it uses, similar to how it defines each #macro it uses.
Example (syntax open for discussion):
#use "org.webmacro.servlet.tools.FormTool" as tool named $Form
#use "org.webmacro.servlet.tools.RequestTool" as tool named $Request
#use "org.webmacro.tools.TypeTool" as tool named $Type
#use is a "build-time" directive similar to #const and #macro in that
during the build phase of the template a list (or map?) of the defined
tools is stored in the template (similar to #macro's).
If these tools implement the ContextTool method, they are stuffed into
the context somewhere at the start of the template evaluation at
*run-time* (either template.write(), .getTemplate(), or even a new
wm.getContext(template) method). If these tools do NOT implement
ContextTool, we can do some build time optimization by creating a new
instance of the object and putting it into the Template during *build
time* (similiar to #const).
Another build-time optimization (post-build, really) could be to walk
the Template elements and make sure the defined #use variables are
actually referenced. If they're not, don't bother creating instances
of them at all.
Advantages to this idea:
1) #use definitions could be #included globally across an entire site
2) "as tool" would allow us to do other things like "as foo", "as bar",
"as whatever" in the future ("as function", maybe???)
3) Definition of the tools is *explicit* per template... in the place
one would like to know what is available
4) It maintains a bit of backwards compatibility with pre-2.0. We
might need to allow for a "globals.wm" template configuration option,
but we've wanted to do that for awhile now anyways
5) It takes all the magic out of Context.java... and might even allow
us to get rid of WebContext too (ie, standalone-globals.wm v/s
servlet-globals.wm)
6) It gives us the ability to do build-time optimizations based on if
these things are actually referenced
7) It puts the power of tool use into the hands of the template
designer (this could be a disadvantage too)
8) With the addition of a Template.getToolList() method and a
"TemplateTool" object, it makes the available tools (in a template)
discoverable by Ignition's fancy auto-documentation thingie.
9) A 3rd party developer doesn't need (unless he wants Context access)
to implement a WebMacro-specific interface at all
10) I was hoping for a "top 10" list, but could only come up with 9
thoughts?
eric
|
|
From: Brian G. <br...@qu...> - 2003-07-26 20:55:29
|
> Why do we need any of this magical stuff in WebMacro?
>
> > So - magic everywhere, or nowhere?
>
> Come on Marc, who's side are you on here? :) Magic *nowhere*
>
This seems like a conversation worth having. I think that while you
and Marc agree on the idea of ditching (or at least demoting) CT, your
motivations are different.
Lets talk about this magic thing. I have always thought that the
magic "architect selects tools { X, Y, Z } and makes them available
transparently in all contexts" to be a powerful feature. Velocity has
a similar mechanism for loading global macros (which we should have
too.)
You seem to think its bad, and not in the user's best interest.
Explain.
|
|
From: Brian G. <br...@qu...> - 2003-07-26 20:49:31
|
> I give up. We're chasing in circles. After all this effort, I am really wondering what concrete gain the user community gets out of this. No one has (yet) put forward compelling use cases for why we would want lazy-loading for anything other than tools, or why the tools interface is inadequate, or what other context-aware thingies besides tools there are. That's not to say there aren't any -- but I think the thing we're all struggling with is that we don't know why we're talking about this. At least I don't. I know that there are things about ContextTool which are aesthetically displeasing. But I'm struggling to see how the WM user community will be better off in a year if we do this now. (Making the code incrementally cleaner is not a strong enough motivator.) I think this is the problem -- I guess I need to see how the users will benefit, but I don't yet. And therein is the problem. I think it is just premature to talk about code changes without a clear, shared idea of how the users will benefit. Anything else is putting the code before the horse. |
|
From: Lane S. <la...@op...> - 2003-07-26 20:45:47
|
Brian Goetz wrote: >>Precisely, which is the problem. This should be moved out into the >>provider's impl, OR left in and also applied to all variables added with >>put(). >> >> > >Well, the current implementation seems perfect to me. I don't think >Lane's proposal was going to touch that -- but instead abstract it >into a lazy-loading mechnaism and change how it is configured, right >Lane? > righto. I never envisioned hacking Context.put(Object, Object) or adding a new method. However, in thinking about it some, the Context.put(Object, ContextAware) method, if not used, will not add any overhead to the general path of Context.put(Object, Object). Right? Further, there are cases where the Context become the object backplane and thus an object implementing ContextAware, gets automatically a reference to the context when put() into the context. I can seem some benefits to this. -Lane > >As far as the latter, you are so far from convincing me (and I think >everyone else) that we need to inspect and potentially call methods on >everything that gets put() into the context that you should probably >consider that concept vetoed. > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga |
|
From: Brian G. <br...@qu...> - 2003-07-26 20:40:21
|
> > My proposal (ContextTool is empty, extends ContextAware) means that no > > existing code is broken. > > I'm really confused. > > If I have a "tool" that I'm going .put into the context and I want it > to be "context aware", then why can't/shouldn't I just call .init() on > it before I .put() it? Right. I am still not seeing the value of the auto-magic init for ordinary context objects. > context-aware variables == tool, no? If you want a *variable* to be > truly context aware, it should implement org.webmacro.Macro, shouldn't > it? Seems that way to me too. |
|
From: Brian G. <br...@qu...> - 2003-07-26 20:32:22
|
> ...then how do we explain all the people flocking to Velocity instead of > WM? It's not just the PR and better docs, IMO. More visibility (Apache) Better docs More contributors Larger user base More understandable license More understandable community dynamics add this up, and it spells Network effect. > A lot of people who use open source will check out the source, > especially if they are "precious" people about code quality. You are > probably one of these people, and I am pretty sure Eric is. I would really love it if the world worked that way! But it doesn't. I think you WAY overestimate the effect of this among the general population. I would expect that "size of user base" is a much more commonly used metric for how safe it is to use a particular package of code (and also, easier to evaluate -- just look at the number of distinct poeple posting on mailing lists.) People want code that works, and want to know that if it doesn't work, someone will fix it. 99% of users of open source software have no intention to EVER modify it. That said, if I had to list our problems (oh, wait, I did), code maintainability would not be anywhere near the top. And, with the recent "cull out the dead stuff", it got much easier. That's not to say that we should not try to write maintainable code -- its jsut that I don't see a maintainability problem as being anywhere near our top priority. |
|
From: Lane S. <la...@op...> - 2003-07-26 20:30:51
|
Marc Palmer wrote: > On Fri, 25 Jul 2003 16:23:54 -0700, Lane Sharman <la...@op...> > wrote: > > > We only need one setting, for the auto tool provider. Negative. You need an explicit boolean property and then a dependent value. The null value means in many settings "no class defined, use the default.". > > -- Lane Sharman Learn About Conga, All Java GUI Builder: http://opendoors.com/conga |
|
From: Lane S. <la...@op...> - 2003-07-26 20:28:33
|
my comments...
First: We WILL have Context Tools operational in Release 2. Period.
Second: I will only defer to Marc's implementation if he keeps to the
originally laid out spec. For example, I want an explicit boolean
property as well as the class name because this makes things more clear
to the property editor and allows for some optimizations.
Third, Marc is seeking to slip a new feature into the put operation
which is a replacement for Keats function proposal of
MethodObject(Context, PrimaryObject). We need to keep things separate. I
know that Keats proposal has merit: it allows static, stateless use of
the context. I am not sure we are ready to bail on this proposal without
some further debate. So, do not add Context.put(Object, ContextAware)
quite yet unless Keats is ready to accept the possibility for both
stateless and statul use of the Context.
Brian is right-on about the put operation. Do NOT change the signature
Context.put(Object, Object). Rather, add Context.put(Object,
ContextAware) allowing method dispatching to eliminate unneeded
conditional processing. This provides a nice wrapper around objects
which need the context as a part of their state.
Lastly, this item is not about some general LazyVariableProvider. It is
about AutoContextLoading or AutoContextHandling. So, use a name like
that. Why use a name that harkens to some other Provider abstraction in
WM? With this implementation, meet the requirements, no more, no less.
Are we there yet???
-Lane
Brian Goetz wrote:
>>However all these changes really are relatively trivial - moving loadTools
>>from Broker is the "biggest" job. I'm happy to do all this if you guys
>>agree on the plan, if Lane isn't fussed about doing it. It would seem
>>fitting that I have to do is, since I was the main protagonist in all this
>>rucus.
>>
>>
>
>This seems mostly reasonable, see comments inline. However, this
>seems nothing like your original proposal. What you've done is
>renamed ContextTool, not gotten rid of it. Now, perhaps that's what
>you meant all along, but that's certainly not what it sounded like you
>were proposing.
>
>
>
>>--- New file: ContextAware.java
>>
>>
>
>What does "context aware" mean? Can any provide three examples of
>something that is context aware that is not context tools? I still
>don't get the need for this concept beyond the existing tool
>mechanism.
>
Marc is seeking a generalization so that any object in the context will be
>
>
>
>>--- New file: LazyVariableProvider.java I think this is the name that fits
>>the functionality best, getting away from the ContextTool terminology,
>>using WM provider terminology
>>
>>public interface LazyVariableProvider extends Provider
>>{
>> Object getVariable( String name, Context context);
>>}
>>
>>
>
>Good concept, but took a wrong turn somewhere. If you are going to be
>a Provider, be a Provider. Implement the Provider interface and
>that's it. Me, I personally think that the Provider framework is a
>terrible abstraction (I think you think this too) because it forces
>everyone who uses it to make all sort of hidden casting assumptions.
>This one is even worse -- its not really even a provider, since the
>meat of it is in an extra method that is outside Provider.
>
>In other words, either use Provider the way the rest of WM does
>(personally, I'd like to see the rest of WM use it less, until it gets
>to the point where it withers and dies on its own) or just define
>the factory you need.
>
>In any case, I don't think Context belongs in this interface.
>
>
>
>>--- New file: DefaultContextToolProvider.java The default impl providing
>>existing CT functionality by excised from core of WM
>>
>>
>
>Why? Why can't you just LEAVE IT THERE? If its so worthless, it will
>die of its own.
>
>
>
>>--- Context.java Modifications....
>>
>>
>
>
>
>> Object tool = null;
>> if (lazyVariableProvider != null)
>> tool = lazyVariableProvider.getVariable( name, this);
>>
>> if (tool != null) {
>>// Remove this code if we decide Context will not handle this kind of thing
>> if (tool instanceof ContextAware)
>> ((ContextAware)tool).init(this);
>> }
>>
>>
>
>I think this is OK here, but not in the put() call. Putting it in the
>put() call is totally magic! (If the object implements this
>interface, then this magic thing happens.)
>
>
>
>> /**
>> * Add an object to the context returning the object that was
>> * there previously under the same name, if any.
>> */
>> public final Object put (Object name, Object value)
>> {
>>// Remove this code if we decide Context will not handle this kind of thing
>> if (value instanceof ContextAware)
>> ((ContextAware)value).init( this);
>> return _variables.put(name, value);
>>
>>
>
>You can't put this here.
>
>However, you could add this:
> public Object put(Object name, ContextAware value) {
> }
>
>like the auto-wrapping we have for int and other primitives.
>
>
>
>
--
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
|
|
From: Brian G. <br...@qu...> - 2003-07-26 20:24:55
|
> I've just spent a long time tracking down an obscure template bug, caused
> by the non-intuitive way #macro works.
> ...even though there is never an assignment to $fieldValue in the macro.
> This is caused by the usage of the variable $value inside the macro, which
> is inadvertently clashing with the global scope $value - it is of course
> supposed to be a local variable, which is not supported by #macro.
You can't possibly think that its a local value, could you? Have you
ever written a macro in C? The semantics of WM's #macro are totally
modeled on that. THey are expanded at runtime. There are no
macro-scoped variables, or any other sort of local variables in WM.
Every well-written C macro uses names like __value instead of value to
avoid capture problems.
I agree that this is a more subtle capture problem than usual, but the
core of thie problem is that any macro that does this:
#set $value = "blah"
is asking for problems.
The reason for the pass-by-reference is that macro expansion should be
transparent -- variables that are passed in as l-values can be
l-values in the macro body. Otherwise, macros would just be
functions.
So you can do this:
#macro mset($a, $b) {
#set $a = $b
}
and the expected thing happens. By the way, the above is immune to
this particular capture problem:
#macro mset($a, $b) {
#set $a = $b
}
#set $a=1
#set $b=2
#set $c=3
#set $d=4
#mset($c, $d)
After execution, $a will _not_ be modified -- beacuse $a in the mset
body is a macro formal, not the $a in the global context. The result
will be a=1, b=2, c=4, d=4. So you can use any names you like for
macro formals without fear of capture.
BTW, macros do all sorts of cool compile time optimization, too, since
they are expanded against the build context. So with
#const debug=false
#macro foo {
#if (debug) { blah blah blah }
}
...
Ya ya #foo ya
the #foo reference gets totally eaten at compile time and doesn't even
make it into the compiled template -- it is totally optimized away.
> I'm not sure what we can do about this. I mistakenly thought #macro would
> have a separate context for its arguments, and as such changes to an outer
> variable would not suddently change the value of a differently named
> parameter to the macro.
Nope, not how it works, nor how it was intended to work -- otherwise
you couldn't have macros that modified their arguments.
> So, is this a bug or a "feature"?
Feature. Just like C macros. If you intend to have local variables,
name them in such a way as to never conflict, just like in C.
Macro-local variables would be nice -- want to add them?
|
|
From: Marc P. <ma...@an...> - 2003-07-26 20:12:20
|
On Sat, 26 Jul 2003 12:35:48 -0700, Brian Goetz <br...@qu...> wrote:
>> See how we now seem to be agreeing on a re-worded version of my original
>> proposal?
>
> Perhaps I don't see it, but yours looks nothing like Lane's to me!
> Yours seems entirely oriented around "get rid of context tool"; Lane's
> appears to be is a more incremental one which abstracts the mechanism
> and exposes a finer-grained configuration. Yours seems pretty
> extreme; Lane's seems incremental. Maybe its a presentation thing.
>
> They may in fact be more similar than that -- and either you're
> smarter than us and can see it where we can't, or they were just
> communicated in different ways.
I just don't get how you can't see it :(
I give up. We're chasing in circles.
> Regardless, the "yours/my" distinction is something we should leave in
> kindergarten. Its not important that we take YOUR proposal -- we
> should take the proposal that's best for the WM user base. Lets keep
> our eye on the ball.
Oh come on - I wasn't being like that. I'm just frustrated that it seems
nobody seems to understand what I'm trying to get across, even though it is
very simple, and Lane's idea is basically identical it seems.
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-26 20:10:17
|
On Sat, 26 Jul 2003 15:55:40 -0400, Eric B. Ridge <eb...@tc...> wrote:
> But this is what I would expect because you are changing $value in the
> #macro. $value is just a variable in the context. All variables are
> global, there is no scope.
Yes, but the macro did not change $fieldValue, but $fieldValue changed. I
understand this - it is sort of pass by reference - but many template
writers will not understand this.
>> So, is this a bug or a "feature"?
>
> it's "just the way it works". The point of macros, I thought, was to
> pass in all the information they need, and to NOT use any existing
> "global" variables that might be in the context. Think of 'em as C/C++
> #define; they're not callable functions with a scope.
My whole point is that I know this - but that other people do not and
because of this it makes macros hard to write because if you need "local"
variables you have to make sure you name them not to clash with anything
else the template writer who calls you (think third party macros).
It's extremely hard to debug this kind of thing, if you are 3 template
includes down the line and you didn't write the macro.
That's all I was saying...
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-26 20:10:15
|
On Sat, 26 Jul 2003 12:26:59 -0700, Brian Goetz <br...@qu...> wrote:
>> Precisely, which is the problem. This should be moved out into the
>> provider's impl, OR left in and also applied to all variables added with
>> put().
>
> Well, the current implementation seems perfect to me. I don't think
> Lane's proposal was going to touch that -- but instead abstract it
> into a lazy-loading mechnaism and change how it is configured, right
> Lane?
>
> As far as the latter, you are so far from convincing me (and I think
> everyone else) that we need to inspect and potentially call methods on
> everything that gets put() into the context that you should probably
> consider that concept vetoed.
I know - my point is that this should be EITHER/OR. I firmly believe, if
everyone thinks that Context should now do the instanceof ContextAware
thing - alternative overriden put() is a better solution - that Context
should not do a check for ContextTool(s) and init them - the abstracted
factory logic should do this.
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-26 20:07:51
|
On Friday, July 25, 2003, at 12:16 PM, Lane Sharman wrote: > Hopefully, Keats and ebr will sign off on this proposal and we will be > good to go. What is your proposal? I haven't seen it. It never came across my inbox. I swear. eric > > -Lane > > > > > pluggable replacement architecture in which you can drop or not drop > objects into the context. From this loader > > Marc Palmer wrote: > >> On Thu, 24 Jul 2003 20:20:47 -0700, Brian Goetz <br...@qu...> >> wrote: >> >>>> 1) Governing principle 1: Existing WM apps which use a context tool >>>> will not break in the new 2.0 distro. I think we owe that to our >>>> user base. There are a lot of folks who use $Form, $Request, etc, >>>> etc. out of the box. >>> >>> >>> +1 -- total agreement. >> >> >> +1 -- Even I uses $Response and $Form and a couple of others, but I >> don't want people to be able to reconfig them! >> >>>> 2) Governing principle 2: New WM apps and architects can completely >>>> suppress the Context Tool as magic through one directive in >>>> WebMacro.properties: EnableContextToolLoading=false. In >>>> WebMacro.defaults it is true by default. >>> >>> >>> +1 on concept; naming to be hashed out later. We might want to >>> support a list of magic thingie loaders, of which context tools will >>> be one. Something that loads default macros, functions, or >>> directives might be another. >> >> >> -1 -- This is redundant IMO, given point (3) >> >>>> 3) Alternative context tool plug-in types can be plugged into the >>>> context by a tool loader different than the default supplied in the >>>> 2.0 distro. The default tool loader will be refactored to conform >>>> to an interface, AutoContextLoader. Any "architect" can replace >>>> this default tool loader with his own loader to add "magic" objects >>>> to the context by implementing AutoContextLoader. Per the existing >>>> logic, on a ref to a null variable in Context.get(), if >>>> (EnableContextToolLoading==TRUE), the loader's interface will be >>>> invoked with the reference to the broker to locate the supporting >>>> object. AutoContextLoaderImpl: will be the property name. >>> >>> >>> +1 on concept; naming to be hashed out later. >> >> >> +1 only if AutoContextLoader = >> o.w.tools.DefaultLegacyContextToolLoader in WM.defaults, so that if >> we want to suppress auto-stuffing, we can just wipe this attribute in >> WM.properties. This makes (2) redundant. Less code, less config, less >> hassle :) >> >>>> 5) The Context Tool can be documented as a) a convenience with some >>>> standard tools for the entry level WM app, b) easily disabled, or >>>> c) pluggable by an architect seeking tight integration with default >>>> tools as an elective feature of WebMacro. >>> >>> >>> +1 >> >> >> +1 to the principle. I still think context-aware variables should be >> part of this plan though - refactor ContextTool.init up to a >> ContextAwareVariable interface... and do the instanceof...init(this) >> thing when putting any var into the context. I think this is an >> integral part because the smart way to do it is to modify the >> contexttool interface in this way (push up the method to >> ContextAwareVariable). >> >> Cheers > > > -- > Lane Sharman > Learn About Conga, All Java GUI Builder: http://opendoors.com/conga > Java Software Portal: http://opendoors.com > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
|
From: Eric B. R. <eb...@tc...> - 2003-07-26 20:06:22
|
On Friday, July 25, 2003, at 06:43 PM, Marc Palmer wrote:
> On Fri, 25 Jul 2003 09:16:20 -0700, Lane Sharman <la...@op...>
> wrote:
>
>
>> Like I said in my initial proposal, this will not win over everyone
>> on all points but I think it is a workable solution allowing folks
>> like you to roll your own solution if that is what you desire If you
>> implement your own AutoProvider, then you you can look up your own
>> ContextValues from whatever :).
>>
>> If ContextTool is not a friendly interface name, then sure, I suppose
>> we could rename it ContextAware as you have suggested, refactor all
>> the implementations and tell everyone in 2.0 that the impl signature
>> has changed.
>>
>> Hopefully, Keats and ebr will sign off on this proposal and we will
>> be good to go.
>
> My proposal (ContextTool is empty, extends ContextAware) means that no
> existing code is broken.
I'm really confused.
If I have a "tool" that I'm going .put into the context and I want it
to be "context aware", then why can't/shouldn't I just call .init() on
it before I .put() it?
{
Context ctx = wm.getContext();
MyTool tool = new MyTool(ctx); // heh, no need to even call an init()
method
ctx.put ("MyTool", tool);
}
Why do we need any of this magical stuff in WebMacro?
Here's a really stupid thought: make the active context available as a
ThreadLocal... then it'll be accessible to anyone that needs it,
regardless of which interface they implement.
> It also means we can add context-awareness to variables put into the
> context by the application (not the AutoContextProvider):
context-aware variables == tool, no? If you want a *variable* to be
truly context aware, it should implement org.webmacro.Macro, shouldn't
it?
> So - magic everywhere, or nowhere?
Come on Marc, who's side are you on here? :) Magic *nowhere*
eric
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-26 19:55:49
|
On Saturday, July 26, 2003, at 08:39 AM, Marc Palmer wrote: > Most viewers of this code would expect it to output: > > Value before macro: Hello > Now $fieldValue is: Hello > Value after macro: modified Hello I would not have expected this > However this is not the case. Some obscure "pass by reference" effects > are occurring in #macro such that the result is: > > Value before macro: Hello > Now $fieldValue is: modified Hello > Value after macro: modified Hello But this is what I would expect because you are changing $value in the #macro. $value is just a variable in the context. All variables are global, there is no scope. > So, is this a bug or a "feature"? it's "just the way it works". The point of macros, I thought, was to pass in all the information they need, and to NOT use any existing "global" variables that might be in the context. Think of 'em as C/C++ #define; they're not callable functions with a scope. eric |
|
From: Brian G. <br...@qu...> - 2003-07-26 19:55:12
|
> However all these changes really are relatively trivial - moving loadTools
> from Broker is the "biggest" job. I'm happy to do all this if you guys
> agree on the plan, if Lane isn't fussed about doing it. It would seem
> fitting that I have to do is, since I was the main protagonist in all this
> rucus.
This seems mostly reasonable, see comments inline. However, this
seems nothing like your original proposal. What you've done is
renamed ContextTool, not gotten rid of it. Now, perhaps that's what
you meant all along, but that's certainly not what it sounded like you
were proposing.
> --- New file: ContextAware.java
What does "context aware" mean? Can any provide three examples of
something that is context aware that is not context tools? I still
don't get the need for this concept beyond the existing tool
mechanism.
> --- New file: LazyVariableProvider.java I think this is the name that fits
> the functionality best, getting away from the ContextTool terminology,
> using WM provider terminology
>
> public interface LazyVariableProvider extends Provider
> {
> Object getVariable( String name, Context context);
> }
Good concept, but took a wrong turn somewhere. If you are going to be
a Provider, be a Provider. Implement the Provider interface and
that's it. Me, I personally think that the Provider framework is a
terrible abstraction (I think you think this too) because it forces
everyone who uses it to make all sort of hidden casting assumptions.
This one is even worse -- its not really even a provider, since the
meat of it is in an extra method that is outside Provider.
In other words, either use Provider the way the rest of WM does
(personally, I'd like to see the rest of WM use it less, until it gets
to the point where it withers and dies on its own) or just define
the factory you need.
In any case, I don't think Context belongs in this interface.
> --- New file: DefaultContextToolProvider.java The default impl providing
> existing CT functionality by excised from core of WM
Why? Why can't you just LEAVE IT THERE? If its so worthless, it will
die of its own.
> --- Context.java Modifications....
> Object tool = null;
> if (lazyVariableProvider != null)
> tool = lazyVariableProvider.getVariable( name, this);
>
> if (tool != null) {
> // Remove this code if we decide Context will not handle this kind of thing
> if (tool instanceof ContextAware)
> ((ContextAware)tool).init(this);
> }
I think this is OK here, but not in the put() call. Putting it in the
put() call is totally magic! (If the object implements this
interface, then this magic thing happens.)
> /**
> * Add an object to the context returning the object that was
> * there previously under the same name, if any.
> */
> public final Object put (Object name, Object value)
> {
> // Remove this code if we decide Context will not handle this kind of thing
> if (value instanceof ContextAware)
> ((ContextAware)value).init( this);
> return _variables.put(name, value);
You can't put this here.
However, you could add this:
public Object put(Object name, ContextAware value) {
}
like the auto-wrapping we have for int and other primitives.
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-26 19:48:38
|
On Saturday, July 26, 2003, at 08:48 AM, Marc Palmer wrote: > > Guys, > > Can I change #count to support counting down as well as up, without > specifying "step -1" ? That's fine by me. In fact, I thought it already did this... eric |
|
From: Brian G. <br...@qu...> - 2003-07-26 19:41:33
|
> > interface ContextTools extends ContextAware, LazyLoaderFactory { }
>
> I think this is incorrect. The "s" at the end of ContextTool might mean you
> are trying to describe something else getting lost in a typo here.
The s is a typo; ignore it.
> interface ContextTool extends ContextAware
>
> Then we also add:
>
> class DefaultContextToolFactory implements LazyLoaderFactory { }
>
> Which is the implementation containing the existing CT logic.
>
> There is no reason for ContextTool itself to implement the factory
> interface - a ContextTool is just a single object placed into the context,
> and is not responsible for loading other objects.
There are two concepts here -- context-aware, and lazy-loaded. The
"classic" context tools have both. (I'm still waiting for a sensible
use case for context-aware in any other situation, btw.) We're
abstracting both out from under the existing context tools, but since
the two are independent attributes, it makes sense for them each to
have their own interface (if they are each of any value at all.)
|
|
From: Brian G. <br...@qu...> - 2003-07-26 19:36:07
|
> See how we now seem to be agreeing on a re-worded version of my original > proposal? Perhaps I don't see it, but yours looks nothing like Lane's to me! Yours seems entirely oriented around "get rid of context tool"; Lane's appears to be is a more incremental one which abstracts the mechanism and exposes a finer-grained configuration. Yours seems pretty extreme; Lane's seems incremental. Maybe its a presentation thing. They may in fact be more similar than that -- and either you're smarter than us and can see it where we can't, or they were just communicated in different ways. Regardless, the "yours/my" distinction is something we should leave in kindergarten. Its not important that we take YOUR proposal -- we should take the proposal that's best for the WM user base. Lets keep our eye on the ball. |
|
From: Brian G. <br...@qu...> - 2003-07-26 19:27:14
|
> Precisely, which is the problem. This should be moved out into the > provider's impl, OR left in and also applied to all variables added with > put(). Well, the current implementation seems perfect to me. I don't think Lane's proposal was going to touch that -- but instead abstract it into a lazy-loading mechnaism and change how it is configured, right Lane? As far as the latter, you are so far from convincing me (and I think everyone else) that we need to inspect and potentially call methods on everything that gets put() into the context that you should probably consider that concept vetoed. |
|
From: Brian G. <br...@qu...> - 2003-07-26 19:24:10
|
> Keats, you've misunderstood. I never proposed that. I agree with the > existing logic, HOWEVER as far as I am aware "initialize" is only performed > on CONTEXT TOOLS - i.e. not on context VARIABLES added with context.put. > > That's all I'm getting at. We should have consistency. This doesn't seem like consistency to me. When a user puts something in the context, it is OWNED by the user. We shouldn't do anything to it. When a user requests an automagic load-on-demand variable that isn't in the context, then we initialize it. > 2. Context is modified to do this instanceof work and call init on BOTH > tools returned from an tool provider/factory AND variables placed into the > context with context.put() This doesn't sit well with me. Can you present a use case where this seems natural? > Consistency is what I'm all about here. WIthout a compelling set of use cases, this seems like consistency for its own sake. > OK - but the thread-safe map is not a strong requirement at this time. Speaking of requirements, what requirement is the "call init on anything I put in the context" supposed to satisfy? I think the problem we're having is that you have a specific idea of what code you want to add, but you've not convinced any of us what requirements it is in aid of. In other words, it's (gack) putting the code before the horse. |
|
From: Marc P. <ma...@an...> - 2003-07-26 12:58:23
|
On Sat, 26 Jul 2003 13:48:14 +0100, Marc Palmer <ma...@an...> wrote: > The docs on wm.org do not indicate that it only counts up but, or that a > step is required to count doen: Typo attack due to frantic high-speed coding ;-) "The docs on wm.org do not indicate that it only counts up, or that a step is required to count down" Apologies. -- 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-26 12:58:23
|
On Sat, 26 Jul 2003 13:39:18 +0100, Marc Palmer <ma...@an...> wrote:
> ...even though there is never an assignment to $fieldValue in the macro.
> This is caused by the usage of the variable $value inside the macro,
> which is inadvertently clashing with the global scope $value - it is of
> course supposed to be a local variable, which is not supported by #macro.
A workaround for this situation is to always tell people who use #macro to
use a special naming convention for "local" variables used in a #macro
body, but this is not ideal.
I will be trying out the #templet/#eval stuff shortly as I hope this will
obviate the need for #macro.
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
|
237 messages has been excluded from this view by a project administrator.
