You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Jason van Zyl <jv...@periapt.com> on 2000/09/24 19:39:42 UTC
Appearance of undefined references
Hi,
I wanted to see what people thought of a shorthand
notation to control the appearance of undefined
references. This is something that iSpock does and
I would like to borrow the following feature. If a
logical not symbol immediately follows the dollar
sign in a reference, it takes up no space in the
output if it is undefined.
So if you had the following line:
<input type="text" name="email" value="$!email">
and $email had not yet been defined then the
output would look like this:
<input type="text" name="email" value="">
I tried implementing it this feature and it
works fine. Is it something that should be
added?
Thoughts?
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> "Daniel L. Rall" wrote:
> >
> > Jason van Zyl wrote:
> >
> > SNIP
> >
> > > So if you had the following line:
> > >
> > > <input type="text" name="email" value="$!email">
> > >
> > > and $email had not yet been defined then the
> > > output would look like this:
> > >
> > > <input type="text" name="email" value="">
> > >
> > > I tried implementing it this feature and it
> > > works fine. Is it something that should be
> > > added?
> >
> > I like the idea, but find the use of '!' a little confusing. Of course,
> > I just woke up... ;)
>
> True. Hoping not to wade back into the format-layer debate I watched go
> by, nor rekindle the multiple-syntax idea, how about a preprocessor-like
> facility so we can build things like this w/o making the language
> bigger. For example :
>
> <input type="text" name="email" value="#isNull($email, "")">
>
> where
>
> isNull(x,y) := #if (x) { x } #else { y }
>
> A basic library of these will solve requests for things like $!var, and
> people can extend it themselves.
>
> And with caching, there should be no performance penalty.
>
> I would volunteer to work on this, if it were deemed wanted.
An interesting idea, but my gut says -1 on macros in Velocity. Consider
C vs. Java and our intended audience of web designers. I wouldn't mind
having a shorthand for this particular thing, just don't know if the one
suggested was the clearest.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> "Daniel L. Rall" wrote:
> >
> > "Geir Magnusson Jr." wrote:
> > >
> > > [snip]
> > > And there are many examples (MSFT Win32) where that is done all the
> > > time, for example for threading support (beginthread()), Unicode support
> > > (tchar_t), etc.
> >
> > Heh, referencing MFC isn't lending much support to your argument Geir.
> > ;P
>
> It has nothing to do with MFC. Its the standard Win32 API. (There are
> a few computers that use it... :)
Have you ever looked into the bowels of MFC, Geir?
> MFC would have everything start with
> a 'C', like CFoobar, and would be some awful member function like
> BeginThreadOnAntotherMachineWithClassANetworkAddress() that would
> allocate memory that you might or might not be able to figure out how to
> free.
hehehehe
> > The Right Way to do this is through the use of context objects--this
> > provides clearer definition of the separation between templates and
> > code.
>
> And I thought there are multiple Right Ways. ("There's More than One
> Way To Do It") I would love to take this offlist with someone that can
> help me achieve the Right Right Way Nirvana, because I don't get why
> this is bad, since we aren't allowing the designer to do any more than
> they can achieve with a simple cut and paste.
There are multiple Right Ways, but generally only one given a specific
set of tools and goals. One of my goals for Velocity is to prevent the
designers and artists from having the ability to create programmatic
interfaces. It's not their job.
> To be clear, I understand the need for controlling logic and data model
> to come from elsewhere, but all we are talking about would be things
> rightly in the domain of the View, and I would *never* make Java objects
> that return *any* markup.
+1, no one suggested that they should.
> If what we are talking about is a View responsibility, how can it be
> justified as coming from the other domains?
The View uses the utility objects placed in the context to get its job
done.
> > As anyone who has done it knows, using APIs is quite a different story
> > from defining reusable ones. I do not want my designers attempting to
> > define APIs.
>
> Hope you don't let them use javascript on the client then.
JavaScript is a complete abombination. I limit its use to setting form
field focus, which some browsers unfortunately don't do by default.
> > > Surely someone, maybe not the core engineers, wants to prevent the evil
> > > menace of cut and paste?
> >
> > Use of the context and #include can prevent this completely--no
> > Velocimacros are needed.
>
> Hang on. The art person sets up the template that is included. They
> stuff things into the context (although someone here I remember doesn't
> like even that...). How is that any different than setting up an API,
> other than its incomprehensable to a casual reader?
Heh. The artist doesn't do any stuffing--that's the application
developer's job. The artist can request dynamic values from the
programmer, which is indeed a bit of interface definition. But that's
the extent of it--they can do no more.
> Anyway, I won't belabor this. If anyone wants to help a poor pilgrim on
> his road towards the Right Way(tm), I am eager for the help.
I totally understand your comments on Velocimacros--they're great if
you're both programmer and designer. But the product they produce isn't
maintainable by a pure artist/designer, which is who you really want
maintaining your UI. Velocimacro-style development just doesn't work in
practice. Don't think we haven't already been down that road. ;)
I hope this helps your understanding of how we see things.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Daniel L. Rall" wrote:
>
> "Geir Magnusson Jr." wrote:
> >
> > [snip]
> > And there are many examples (MSFT Win32) where that is done all the
> > time, for example for threading support (beginthread()), Unicode support
> > (tchar_t), etc.
>
> Heh, referencing MFC isn't lending much support to your argument Geir.
> ;P
It has nothing to do with MFC. Its the standard Win32 API. (There are
a few computers that use it... :) MFC would have everything start with
a 'C', like CFoobar, and would be some awful member function like
BeginThreadOnAntotherMachineWithClassANetworkAddress() that would
allocate memory that you might or might not be able to figure out how to
free.
>
> > My point is simply that the language gets richer for the end user in an
> > end-user controllable fashion (they can add velocimacros) w/o making
> > the language bigger internally.
>
> The Right Way to do this is through the use of context objects--this
> provides clearer definition of the separation between templates and
> code.
And I thought there are multiple Right Ways. ("There's More than One
Way To Do It") I would love to take this offlist with someone that can
help me achieve the Right Right Way Nirvana, because I don't get why
this is bad, since we aren't allowing the designer to do any more than
they can achieve with a simple cut and paste.
To be clear, I understand the need for controlling logic and data model
to come from elsewhere, but all we are talking about would be things
rightly in the domain of the View, and I would *never* make Java objects
that return *any* markup.
If what we are talking about is a View responsibility, how can it be
justified as coming from the other domains?
>
> > > > So the art major then sets up look and feel thing, and that is captured
> > > > and formalized into Velocimacros, so his/her art minions can code the
> > > > content templates. Then, when fashion changes, you can modify the
> > > > velocimacros for a wholesale change.
> > >
> > > Who captures and formalizes it? Surely not the art major. I don't want
> > > to have anything to do with that part of the process, I have way too
> > > much work to do on various core engineering activities. Let's stick
> > > with the KISS philosophy.
> >
> > Surely the art major! If the art major can decide, for example, on a
> > given visual representation of something, and is able to use the
> > template engine to express that, using all sorts of things like loops,
> > including other templates, setting variables, checking variables,
> > remembering that $!foo means #if($foo) { $foo } :) , then I believe
> > they could handle defining a macro.
>
> As anyone who has done it knows, using APIs is quite a different story
> from defining reusable ones. I do not want my designers attempting to
> define APIs.
Hope you don't let them use javascript on the client then.
> > Surely someone, maybe not the core engineers, wants to prevent the evil
> > menace of cut and paste?
>
> Use of the context and #include can prevent this completely--no
> Velocimacros are needed.
Hang on. The art person sets up the template that is included. They
stuff things into the context (although someone here I remember doesn't
like even that...). How is that any different than setting up an API,
other than its incomprehensable to a casual reader?
Anyway, I won't belabor this. If anyone wants to help a poor pilgrim on
his road towards the Right Way(tm), I am eager for the help.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> [snip]
> And there are many examples (MSFT Win32) where that is done all the
> time, for example for threading support (beginthread()), Unicode support
> (tchar_t), etc.
Heh, referencing MFC isn't lending much support to your argument Geir.
;P
> My point is simply that the language gets richer for the end user in an
> end-user controllable fashion (they can add velocimacros) w/o making
> the language bigger internally.
The Right Way to do this is through the use of context objects--this
provides clearer definition of the separation between templates and
code.
> > > So the art major then sets up look and feel thing, and that is captured
> > > and formalized into Velocimacros, so his/her art minions can code the
> > > content templates. Then, when fashion changes, you can modify the
> > > velocimacros for a wholesale change.
> >
> > Who captures and formalizes it? Surely not the art major. I don't want
> > to have anything to do with that part of the process, I have way too
> > much work to do on various core engineering activities. Let's stick
> > with the KISS philosophy.
>
> Surely the art major! If the art major can decide, for example, on a
> given visual representation of something, and is able to use the
> template engine to express that, using all sorts of things like loops,
> including other templates, setting variables, checking variables,
> remembering that $!foo means #if($foo) { $foo } :) , then I believe
> they could handle defining a macro.
As anyone who has done it knows, using APIs is quite a different story
from defining reusable ones. I do not want my designers attempting to
define APIs.
> Surely someone, maybe not the core engineers, wants to prevent the evil
> menace of cut and paste?
Use of the context and #include can prevent this completely--no
Velocimacros are needed.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Daniel L. Rall" wrote:
>
> >From a C programmer's view, 'if' is a flow control statement, and 'FOO'
> is a macro.
I am going to drop this, but suppose I had a #include that defined the
macro, and FOO was lowercase. (Poor style, I admit...).
A casual reader of the proggie wouldn't have a clue.
And there are many examples (MSFT Win32) where that is done all the
time, for example for threading support (beginthread()), Unicode support
(tchar_t), etc.
My point is simply that the language gets richer for the end user in an
end-user controllable fashion (they can add velocimacros) w/o making
the language bigger internally.
> > So the art major then sets up look and feel thing, and that is captured
> > and formalized into Velocimacros, so his/her art minions can code the
> > content templates. Then, when fashion changes, you can modify the
> > velocimacros for a wholesale change.
>
> Who captures and formalizes it? Surely not the art major. I don't want
> to have anything to do with that part of the process, I have way too
> much work to do on various core engineering activities. Let's stick
> with the KISS philosophy.
Surely the art major! If the art major can decide, for example, on a
given visual representation of something, and is able to use the
template engine to express that, using all sorts of things like loops,
including other templates, setting variables, checking variables,
remembering that $!foo means #if($foo) { $foo } :) , then I believe
they could handle defining a macro.
Surely someone, maybe not the core engineers, wants to prevent the evil
menace of cut and paste?
> > I guess if this doesn't happen, one can always write a template
> > preprocessor to do exactly this (expand macros into velocicode) but that
> > seems to be one of the purposes of a template engine anyway.
>
> The context is meant to supply the tools to do this sort of thing.
You then move something which can [by definition, if the Velocimacro
expands to velocity directives...] and should be expressed in the
template language away from the template language back into Java code.
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> "Daniel L. Rall" wrote:
> >
> > Your macro would be called as a directive because of the '#' in front of
> > it.
>
> Yes, in the syntax from the view of the designer, I guess it would be.
> On the implementation side, a preprocessing step would be included which
> expands the macros out before being actually processed, which are
> written using the 'regular' directives of the language, so the piece
> that processes the directives wouldn't see anything new.
>
> <aside>
> My language formalism is weak : is it true that in the following C
> program
>
> #define FOO(x) x=x*2
>
> main()
> {
> int x = 1;
>
> if (x)
> FOO(x);
> }
>
> both 'if' and 'FOO' are considered directives? If not, why would they
> both be in my example above?
>
> </aside>
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Daniel L. Rall" wrote:
>
> Jon Stevens wrote:
> >
> > on 9/24/2000 2:46 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> >
> > > I guess if this doesn't happen, one can always write a template
> > > preprocessor to do exactly this (expand macros into velocicode) but that
> > > seems to be one of the purposes of a template engine anyway.
> >
> > Solution 5:
> >
> > <input type=text name=email value="$tool.Value($email,"")">
> >
> > I like this solution the best. It doesn't require ANY changes to Velocity as
> > it stands and is cleanly MVC.
>
> I agree that this is probably the best way to go.
I like this too, after thinking about the MVC implications, but I still
think that it would be useful to allow designers to encapsulate things
that will be repeated into macros.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jon Stevens wrote:
>
> on 9/24/2000 2:46 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > I guess if this doesn't happen, one can always write a template
> > preprocessor to do exactly this (expand macros into velocicode) but that
> > seems to be one of the purposes of a template engine anyway.
>
> Solution 5:
>
> <input type=text name=email value="$tool.Value($email,"")">
>
> I like this solution the best. It doesn't require ANY changes to Velocity as
> it stands and is cleanly MVC.
I agree that this is probably the best way to go.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 2:46 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> I guess if this doesn't happen, one can always write a template
> preprocessor to do exactly this (expand macros into velocicode) but that
> seems to be one of the purposes of a template engine anyway.
Solution 5:
<input type=text name=email value="$tool.Value($email,"")">
I like this solution the best. It doesn't require ANY changes to Velocity as
it stands and is cleanly MVC.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Daniel L. Rall" wrote:
>
> "Geir Magnusson Jr." wrote:
> > [snip]
> > > > isNull(x,y) := #if (x) { x } #else { y }
> > > <snip>
> > >
> > > There is a difference in my mind between directives (#) and variables ($).
> > > For simplicity, I really want to keep the number of directives to as few as
> > > possible because I relate directives to functions. I would however agree
> > > that we should provide a number of tools to go into the context (ie: like
> > > WM's ContextTools).
> > >
> >
> > But we don't add any directives to the language here. I agree with you
> > that the core language should remain small. Real small.
>
> Your macro would be called as a directive because of the '#' in front of
> it.
Yes, in the syntax from the view of the designer, I guess it would be.
On the implementation side, a preprocessing step would be included which
expands the macros out before being actually processed, which are
written using the 'regular' directives of the language, so the piece
that processes the directives wouldn't see anything new.
<aside>
My language formalism is weak : is it true that in the following C
program
#define FOO(x) x=x*2
main()
{
int x = 1;
if (x)
FOO(x);
}
both 'if' and 'FOO' are considered directives? If not, why would they
both be in my example above?
</aside>
> [snip]
> > I mean, if it was argued that adding multiple syntaxes to the language
> > was important to support special tasks and repetitive tasks, here is a
> > way of doing it w/o adding complexity to the engine.
> >
> > Further, this allows an uber-designer to create tools for a design group
> > to use to maintain consistancy in look/feel/design.
>
> Unfortunately, I haven't seen this work all that well in practice. The
> art major that you just hired straight out of college should focus on
> the look and feel of your web site, not on climbing the learning curve
> of how to call Velocimacros. I would prefer not to reinvent PHP or ASP
> style development, and adding Velocimacros would allow this, regardless
> of original intent and usefullness to the uber-designer.
So the art major then sets up look and feel thing, and that is captured
and formalized into Velocimacros, so his/her art minions can code the
content templates. Then, when fashion changes, you can modify the
velocimacros for a wholesale change.
So the art major does what then to address the issue in the current
implementation?
Solution 1 : <input type=text name=email value="$email">
which would spew crap into your textbox under webmacro if $email was
undefined
Solution 2 : <input type=text name=email value=$!email>
because the ! modifier was added, so this is ok, but it has been argued
that is
too perl-like and hard for that art major to remember (or something...)
Solution 3 : <input type=text name=email value="
#if ($email) {
$email
}
">
which has all sorts of problems, including ugliness and having to
repeat the if
construct in multiple places
Solution 4 :
#if ($email) {
<input type=text name=email value="$email">
}
#else {
<input type=text name=email value="">
}
tedious in practice...
or a velocimacro.
I guess if this doesn't happen, one can always write a template
preprocessor to do exactly this (expand macros into velocicode) but that
seems to be one of the purposes of a template engine anyway.
geir
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
> [snip]
> > > isNull(x,y) := #if (x) { x } #else { y }
> > <snip>
> >
> > There is a difference in my mind between directives (#) and variables ($).
> > For simplicity, I really want to keep the number of directives to as few as
> > possible because I relate directives to functions. I would however agree
> > that we should provide a number of tools to go into the context (ie: like
> > WM's ContextTools).
> >
>
> But we don't add any directives to the language here. I agree with you
> that the core language should remain small. Real small.
Your macro would be called as a directive because of the '#' in front of
it.
[snip]
> I mean, if it was argued that adding multiple syntaxes to the language
> was important to support special tasks and repetitive tasks, here is a
> way of doing it w/o adding complexity to the engine.
>
> Further, this allows an uber-designer to create tools for a design group
> to use to maintain consistancy in look/feel/design.
Unfortunately, I haven't seen this work all that well in practice. The
art major that you just hired straight out of college should focus on
the look and feel of your web site, not on climbing the learning curve
of how to call Velocimacros. I would prefer not to reinvent PHP or ASP
style development, and adding Velocimacros would allow this, regardless
of original intent and usefullness to the uber-designer.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> ...and don't really quite understand the drawbacks of a
> user-expandable template engine.
If it can go wrong, it will. If it can be abused, it will. We don't
want the ability to extend Velocity syntax via templates, since this
would become the seductively easy route. The easiest route is not
always the correct one, however. The provided method for extending the
templating engine is through Java classes, which works out quite a bit
better in the long run. =)
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 7:48 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> As I think taglibs are a horrible idea, my thinking has always been
> along the lines of <% %> and using java. I think I will try a
> conversion and see what happens.
:-)
> Except when you are a consultant and you hope and expect to turn a
> system over for others of differing abilities to work on. It's a real
> issue. While my client is very technical and *not* a PHB, that can
> also be an issue as well - people have to be weaned slowly off
> commercial software and onto OSS.
Right, but by the time you turn the project over, the problems have been
solved, right?
>>> Aside from the observation that when you use for the ends of the scale
>>> the things that you are comparing, those things will be far apart, care
>>> to elaborate a bit here?
>>
>> MVC. :-)
>
> That isn't turbine then :)
Right, Turbine itself is the M and C. The template language (ie: VM/WM) is
the V.
> But on the 'get to know the technologies before you' theme,
> understanding the commercial competitors to your web construction tools
> is important.
Actually, no it isn't. We are not considered to be in the same ball game. My
motto is that if you "get it" then you are using Turbine, if you don't
well...that is your problem.
Really, I'm not trying to "convert" people from OSS. I want people to figure
that out on their own. Pushing OSS on people is like trying to talk to a
wall.
> No, east coast, Connecticut.
hmm...bummer...if you are ever out here...
I will be speaking on Scarab in NY in January at LinuxWorld I think...
>> p.s. I'm working on my Turbine MVC/Model 2+1 talk right now for ApacheCon
>> EU. If you are going to be there, come to my talk. :-)
>
> If I could I would, but could only expense that travel to the IRS...
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 6:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > And I am pretty sure (I haven't done it though) that the functionality
> > of each WM directive can be easily implemented in Java within a JSP
> > page, as WM functionality is covered by JSP's functionality.
>
> True, but the methodology for implementing them is different. In JSP, you
> would either use a taglib or implement it in Java itself. What isn't
> possible to do in JSP is something simple like this:
>
> #if ($foo)
> <html> code </html>
> #else
> <html> other code </html>
> #end
>
> In JSP, you would need to do some seriously ugly hacking with <% %> to get
> that to happen. Thing is that the above is something that I would get used
> on about 90% of the pages I write, so it is important to me to have that
> ability.
As I think taglibs are a horrible idea, my thinking has always been
along the lines of <% %> and using java. I think I will try a
conversion and see what happens.
> > I had said nothing about the reverse, converting JSP to WM, which is the
> > problem you correctly identified, as WM doesn't cover JSP's
> > functionality. (Further, it shows me you aren't reading what I am
> > writing, I think, or I am not writing what I am thinking.)
> >
> > I am so happy with WM, I counsel friends considering JSP to try WM
> > first, rather than try the other way, because, as you point out JSP
> > isn't covered by WM, and JSP is a disgusting abomination, in my
> > opinion. (I think the tag libraries make it worse than ASP, which I
> > didn't think possible.) But we are getting a bit off topic here.
> >
> > Remember the context that came from : I chose to use WM in a project for
> > a client because I felt that I was minimizing technology risk as I
> > thought I would be able to move a WM implementation to JSP w/o major
> > headache if problems arose.
>
> Hmmm...I guess that is the disconnect between OSS and commercial software.
> In OSS, if problems arise, you simply fix them. :-) No need to guard against
> the need to switch. :-)
Except when you are a consultant and you hope and expect to turn a
system over for others of differing abilities to work on. It's a real
issue. While my client is very technical and *not* a PHB, that can
also be an issue as well - people have to be weaned slowly off
commercial software and onto OSS.
> > Aside from the observation that when you use for the ends of the scale
> > the things that you are comparing, those things will be far apart, care
> > to elaborate a bit here?
>
> MVC. :-)
That isn't turbine then :)
> > If you are saying that it tries to be 'far away' in that rather than
> > unfettered access to data, control and resources available to the
> > designer of a JSP page, WM contrains the programmatic functionality
> > available to the designer to a small, limited set of actions, and that
> > access to any resources and application 'flow' control is entirely in
> > the domain of the programmer, then I agree.
>
> right. I agree.
>
> > On the other hand, if you say that they are both examples of a java
> > servlet based web application development system that allows dynamic
> > creation of web content, then WM is a lot closer than JSP than what I
> > understand Broadvision to be.
> > On the otherhand, Broadvision may be MVC nervana. (Haven't used it...)
>
> I don't know anything about BV, nor really care. :-) Commercial software.
But on the 'get to know the technologies before you' theme,
understanding the commercial competitors to your web construction tools
is important.
> > It would be interesting to sit down sometime and chat about what you
> > think I am saying, and what I think I am saying. It's pretty apparent
> > that as of this moment, they aren't the same thing.
>
> Yep, seems like we lost that "personal" connection in email. :-( Sorry about
> that. :-( You live in bay area?
No, east coast, Connecticut.
>
> p.s. I'm working on my Turbine MVC/Model 2+1 talk right now for ApacheCon
> EU. If you are going to be there, come to my talk. :-)
If I could I would, but could only expense that travel to the IRS...
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 6:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> And I am pretty sure (I haven't done it though) that the functionality
> of each WM directive can be easily implemented in Java within a JSP
> page, as WM functionality is covered by JSP's functionality.
True, but the methodology for implementing them is different. In JSP, you
would either use a taglib or implement it in Java itself. What isn't
possible to do in JSP is something simple like this:
#if ($foo)
<html> code </html>
#else
<html> other code </html>
#end
In JSP, you would need to do some seriously ugly hacking with <% %> to get
that to happen. Thing is that the above is something that I would get used
on about 90% of the pages I write, so it is important to me to have that
ability.
> I had said nothing about the reverse, converting JSP to WM, which is the
> problem you correctly identified, as WM doesn't cover JSP's
> functionality. (Further, it shows me you aren't reading what I am
> writing, I think, or I am not writing what I am thinking.)
>
> I am so happy with WM, I counsel friends considering JSP to try WM
> first, rather than try the other way, because, as you point out JSP
> isn't covered by WM, and JSP is a disgusting abomination, in my
> opinion. (I think the tag libraries make it worse than ASP, which I
> didn't think possible.) But we are getting a bit off topic here.
>
> Remember the context that came from : I chose to use WM in a project for
> a client because I felt that I was minimizing technology risk as I
> thought I would be able to move a WM implementation to JSP w/o major
> headache if problems arose.
Hmmm...I guess that is the disconnect between OSS and commercial software.
In OSS, if problems arise, you simply fix them. :-) No need to guard against
the need to switch. :-)
> Aside from the observation that when you use for the ends of the scale
> the things that you are comparing, those things will be far apart, care
> to elaborate a bit here?
MVC. :-)
> If you are saying that it tries to be 'far away' in that rather than
> unfettered access to data, control and resources available to the
> designer of a JSP page, WM contrains the programmatic functionality
> available to the designer to a small, limited set of actions, and that
> access to any resources and application 'flow' control is entirely in
> the domain of the programmer, then I agree.
right. I agree.
> On the other hand, if you say that they are both examples of a java
> servlet based web application development system that allows dynamic
> creation of web content, then WM is a lot closer than JSP than what I
> understand Broadvision to be.
> On the otherhand, Broadvision may be MVC nervana. (Haven't used it...)
I don't know anything about BV, nor really care. :-) Commercial software.
> It would be interesting to sit down sometime and chat about what you
> think I am saying, and what I think I am saying. It's pretty apparent
> that as of this moment, they aren't the same thing.
Yep, seems like we lost that "personal" connection in email. :-( Sorry about
that. :-( You live in bay area?
p.s. I'm working on my Turbine MVC/Model 2+1 talk right now for ApacheCon
EU. If you are going to be there, come to my talk. :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 5:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> >> WM is about as far away from JSP as you can get.
> >
> > Come on, this is getting close to sig material. ;-> Converting a WM
> > application to JSP should be trivial and mechanical, though of course
> > you lose the enforcement of the MVC contract... :(
>
> Should be? Why is that? JSP is a fundamentally different technology. You
> cannot embed Java code within a WM template. WM uses embedded directives and
> JSP uses SGML based tag markup.
And I am pretty sure (I haven't done it though) that the functionality
of each WM directive can be easily implemented in Java within a JSP
page, as WM functionality is covered by JSP's functionality.
I had said nothing about the reverse, converting JSP to WM, which is the
problem you correctly identified, as WM doesn't cover JSP's
functionality. (Further, it shows me you aren't reading what I am
writing, I think, or I am not writing what I am thinking.)
I am so happy with WM, I counsel friends considering JSP to try WM
first, rather than try the other way, because, as you point out JSP
isn't covered by WM, and JSP is a disgusting abomination, in my
opinion. (I think the tag libraries make it worse than ASP, which I
didn't think possible.) But we are getting a bit off topic here.
Remember the context that came from : I chose to use WM in a project for
a client because I felt that I was minimizing technology risk as I
thought I would be able to move a WM implementation to JSP w/o major
headache if problems arose.
>
> > I realize that you are an important contributor to many of the projects
> > we are discussing here, (all of you are,) and am thankful that this
> > stuff exists. But I really don't understand what I have done to warrant
> > what I interpret to be a belittling and condescending tone that you,
> > Jon, are using with me. I don't think it adds much to the discussion,
> > but I guess I am an outsider here, so I will respectfully stop here on
> > this particular thread.
>
> Like I said...I'm not trying to be harsh, I'm simply asking you to
> understand the facts before you try to restate them. It isn't belittling or
> condescending, it is pointing out that you are not using factual statements
> and asking you to go back and learn more on your own first before trying to
> use factual statements.
There is a difference between what you wrote and harsh, which I don't
mind - Next time, if you say "You are wrong, you bloviating moron, and
here's why : " I will dance for joy if you tell me why I'm wrong.
> By saying that WM and JSP are close to each other, you are simply showing me
> that you are not aware of the fact that WM really in fact tries to be about
> as far away from JSP as it possibly can. We often display scales of where WM
> and JSP sit together and they are on the furthest sides of the scale that
> you can get.
>
> <---------------------------------------------->
> Velocity Freemarker JSP
> Webmacro
Aside from the observation that when you use for the ends of the scale
the things that you are comparing, those things will be far apart, care
to elaborate a bit here?
If you are saying that it tries to be 'far away' in that rather than
unfettered access to data, control and resources available to the
designer of a JSP page, WM contrains the programmatic functionality
available to the designer to a small, limited set of actions, and that
access to any resources and application 'flow' control is entirely in
the domain of the programmer, then I agree.
On the other hand, if you say that they are both examples of a java
servlet based web application development system that allows dynamic
creation of web content, then WM is a lot closer than JSP than what I
understand Broadvision to be.
On the otherhand, Broadvision may be MVC nervana. (Haven't used it...)
> Those of us who "get it" understand that JSP is a big fat fully automatic
> gun that also happens to be loaded with bullets and the trigger is cocked
> with which you can blow your head off.
Here is another example of what you might think of as 'harsh', and I
think of as rather condescending. Just why do you think I don't
understand that? What do you think made me choose WM in the first
place, and why I would spend this much time arguing for what I think are
improvements in velocity? Why do you think I counsel consulting clients
to not go with the cover-thyne-ass branded solution of JSP from
Sun(tm)(R)(C)(etc) and look at other approaches? What of this thread
made you decide that I don't understand the problems with JSP?
> Whereas WM/VM are simply non-automatic guns that have no bullets and no
> trigger...you have to throw them pretty damn hard and with accurate aim in
> order for them to kill someone.
It would be interesting to sit down sometime and chat about what you
think I am saying, and what I think I am saying. It's pretty apparent
that as of this moment, they aren't the same thing.
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 5:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> WM is about as far away from JSP as you can get.
>
> Come on, this is getting close to sig material. ;-> Converting a WM
> application to JSP should be trivial and mechanical, though of course
> you lose the enforcement of the MVC contract... :(
Should be? Why is that? JSP is a fundamentally different technology. You
cannot embed Java code within a WM template. WM uses embedded directives and
JSP uses SGML based tag markup.
> I realize that you are an important contributor to many of the projects
> we are discussing here, (all of you are,) and am thankful that this
> stuff exists. But I really don't understand what I have done to warrant
> what I interpret to be a belittling and condescending tone that you,
> Jon, are using with me. I don't think it adds much to the discussion,
> but I guess I am an outsider here, so I will respectfully stop here on
> this particular thread.
Like I said...I'm not trying to be harsh, I'm simply asking you to
understand the facts before you try to restate them. It isn't belittling or
condescending, it is pointing out that you are not using factual statements
and asking you to go back and learn more on your own first before trying to
use factual statements.
By saying that WM and JSP are close to each other, you are simply showing me
that you are not aware of the fact that WM really in fact tries to be about
as far away from JSP as it possibly can. We often display scales of where WM
and JSP sit together and they are on the furthest sides of the scale that
you can get.
<---------------------------------------------->
Velocity Freemarker JSP
Webmacro
Those of us who "get it" understand that JSP is a big fat fully automatic
gun that also happens to be loaded with bullets and the trigger is cocked
with which you can blow your head off.
Whereas WM/VM are simply non-automatic guns that have no bullets and no
trigger...you have to throw them pretty damn hard and with accurate aim in
order for them to kill someone.
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 4:27 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > I didn't think the subject changed, but rather we were exploring ways to
> > address it and related issues. And I did look at it about 5 months ago
> > and chose not to use it for various reasons, mostly to respect client
> > sensitivity towards my use of non-major-brandname parts, such as linux,
> > servlets, webmacro, mySQL (for non transactional stuff), etc rather than
> > Sun, WebLogic, JSP, Oracle.
>
> blah blah blah...:-)
<sigh> :)
>
> > Tossing Turbine onto the heap was too much
> > since I had no experience with it. I had no experience at the time with
> > webmacro either, but felt then that it wasn't too far away from JSP to
> > be too big a risk.
>
> WM is about as far away from JSP as you can get.
Come on, this is getting close to sig material. ;-> Converting a WM
application to JSP should be trivial and mechanical, though of course
you lose the enforcement of the MVC contract... :(
> You really should spend
> some more time analyzing and understanding the technologies in front of you.
I realize that you are an important contributor to many of the projects
we are discussing here, (all of you are,) and am thankful that this
stuff exists. But I really don't understand what I have done to warrant
what I interpret to be a belittling and condescending tone that you,
Jon, are using with me. I don't think it adds much to the discussion,
but I guess I am an outsider here, so I will respectfully stop here on
this particular thread.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 4:27 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> I didn't think the subject changed, but rather we were exploring ways to
> address it and related issues. And I did look at it about 5 months ago
> and chose not to use it for various reasons, mostly to respect client
> sensitivity towards my use of non-major-brandname parts, such as linux,
> servlets, webmacro, mySQL (for non transactional stuff), etc rather than
> Sun, WebLogic, JSP, Oracle.
blah blah blah...:-)
> Tossing Turbine onto the heap was too much
> since I had no experience with it. I had no experience at the time with
> webmacro either, but felt then that it wasn't too far away from JSP to
> be too big a risk.
WM is about as far away from JSP as you can get. You really should spend
some more time analyzing and understanding the technologies in front of you.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 3:55 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > Jon Stevens wrote:
> >>
> >> on 9/24/2000 3:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> >
> >>> What about those of us (obviously foolish souls) that don't use Turbine?
> >>
> >> We are providing an excellent solution to solve that problem that you are
> >> discussing. If you don't like it, then you are going to be forced to come up
> >> with your own solution or help us change our solution to match your tastes.
> >
> > Just to make it clear to me, are you saying that Turbine specifically is
> > the solution to allow cleaner handling of an undefined reference in
> > general Velocity template processing?
>
> No. I'm saying that Turbine solves the problems that you changed the subject
> to talk about. :-) Maybe you should go look at what Turbine is so that you
> have a better understanding of what you are trying to discuss. :-)
I didn't think the subject changed, but rather we were exploring ways to
address it and related issues. And I did look at it about 5 months ago
and chose not to use it for various reasons, mostly to respect client
sensitivity towards my use of non-major-brandname parts, such as linux,
servlets, webmacro, mySQL (for non transactional stuff), etc rather than
Sun, WebLogic, JSP, Oracle. Tossing Turbine onto the heap was too much
since I had no experience with it. I had no experience at the time with
webmacro either, but felt then that it wasn't too far away from JSP to
be too big a risk.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 3:55 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Jon Stevens wrote:
>>
>> on 9/24/2000 3:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>>> What about those of us (obviously foolish souls) that don't use Turbine?
>>
>> We are providing an excellent solution to solve that problem that you are
>> discussing. If you don't like it, then you are going to be forced to come up
>> with your own solution or help us change our solution to match your tastes.
>
> Just to make it clear to me, are you saying that Turbine specifically is
> the solution to allow cleaner handling of an undefined reference in
> general Velocity template processing?
No. I'm saying that Turbine solves the problems that you changed the subject
to talk about. :-) Maybe you should go look at what Turbine is so that you
have a better understanding of what you are trying to discuss. :-)
> If so, I don't like it.
>
> Where my thinking came from was that if the solution was cleanly
> expressed within the template language, i.e.
>
> $!email <==> #if($email) { $email }
>
> then why not produce a mechanism that allows one to do that w/o having
> to repeat the code all over the template? That's all.
Right, my proposal was:
$tool.Value($email) <==> #if($email) { $email }
We have come to the conclusion that $!email would be ok.
> Currently, I am not using Turbine, and have run across the issue that
> started this discussion this morning, and used #if(){} rather than
> bringing another framework into my project.
See above.
>> That is exactly what this group is all about. You can either choose to play
>> with us and gain the power from that or choose to play on your own and
>> continually re-invent our wheel.
>>
>> I'm not trying to be harsh, just honest. There is only 24 hours in the day
>> and we are trying our best to come up with solutions that work for the
>> broader whole.
>
> Honestly, harsh is fine. I am also interested in the best solution for
> me and the whole, and don't really quite understand the drawbacks of a
> user-expandable template engine. I appreciate all the effort that
> people go to, and wish I could find the time and a place to contribute.
>
> Anyway, I guess I haven't been reading closely enough, luking on this
> list, nor do I seem to understand what 'playing with you' means. I was
> trying to play with the velocity project. I thought that velocity was
> supposed to be the apache foundation's version of a template engine
> similar to webmacro, and Turbine is an application framework that uses
> it. I don't understand why the inverse should be a requirement.
What I mean by "playing with you" is participating in the Jakarta/Java
Apache projects.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 3:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> > What about those of us (obviously foolish souls) that don't use Turbine?
>
> We are providing an excellent solution to solve that problem that you are
> discussing. If you don't like it, then you are going to be forced to come up
> with your own solution or help us change our solution to match your tastes.
Just to make it clear to me, are you saying that Turbine specifically is
the solution to allow cleaner handling of an undefined reference in
general Velocity template processing?
If so, I don't like it.
Where my thinking came from was that if the solution was cleanly
expressed within the template language, i.e.
$!email <==> #if($email) { $email }
then why not produce a mechanism that allows one to do that w/o having
to repeat the code all over the template? That's all.
Currently, I am not using Turbine, and have run across the issue that
started this discussion this morning, and used #if(){} rather than
bringing another framework into my project.
> That is exactly what this group is all about. You can either choose to play
> with us and gain the power from that or choose to play on your own and
> continually re-invent our wheel.
>
> I'm not trying to be harsh, just honest. There is only 24 hours in the day
> and we are trying our best to come up with solutions that work for the
> broader whole.
Honestly, harsh is fine. I am also interested in the best solution for
me and the whole, and don't really quite understand the drawbacks of a
user-expandable template engine. I appreciate all the effort that
people go to, and wish I could find the time and a place to contribute.
Anyway, I guess I haven't been reading closely enough, luking on this
list, nor do I seem to understand what 'playing with you' means. I was
trying to play with the velocity project. I thought that velocity was
supposed to be the apache foundation's version of a template engine
similar to webmacro, and Turbine is an application framework that uses
it. I don't understand why the inverse should be a requirement.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 3:12 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Sorry. I guess I meant that it wasn't a directive in the formal sense,
> by that I mean adding elements to the language, because my intention was
> interpret-time expansion into a snippet of macro code of 'regular'
> directives.
>
> But yes, structurally its a directive.
There is no formal/informal regular/nonregular here. :-) Don't you see how
that would just add even more confusion? :-)
> That's fine. I use the same pattern in WM to frame content with the
> appropriate navigation and style framework. But there is only one in
> the frame, corresponding to the content body. I don't think you would
> want to scatter $navigation.setTemplate(---) throughout every <input>
> tag where you want to check for a null value, would you?
No, I already stated my suggestion #5 as a solution.
> What about those of us (obviously foolish souls) that don't use Turbine?
We are providing an excellent solution to solve that problem that you are
discussing. If you don't like it, then you are going to be forced to come up
with your own solution or help us change our solution to match your tastes.
That is exactly what this group is all about. You can either choose to play
with us and gain the power from that or choose to play on your own and
continually re-invent our wheel.
I'm not trying to be harsh, just honest. There is only 24 hours in the day
and we are trying our best to come up with solutions that work for the
broader whole.
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 1:54 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > But we don't add any directives to the language here. I agree with you
> > that the core language should remain small. Real small.
>
> How is #isNull not a directive?
Sorry. I guess I meant that it wasn't a directive in the formal sense,
by that I mean adding elements to the language, because my intention was
interpret-time expansion into a snippet of macro code of 'regular'
directives.
But yes, structurally its a directive.
> > #showSmallTitle( "the title", "red")
> >
> > where
> >
> > showSmallTitle(x,y) := <center><b><font color=y>x</font></b></center>
>
> In Turbine, that is:
>
> $navigation.setTemplate("/foo.wm")
>
That's fine. I use the same pattern in WM to frame content with the
appropriate navigation and style framework. But there is only one in
the frame, corresponding to the content body. I don't think you would
want to scatter $navigation.setTemplate(---) throughout every <input>
tag where you want to check for a null value, would you?
> Again, #showSmallTitle is a directive because it is prefixed with a #.
Yes. Agreed.
>
> > I mean, if it was argued that adding multiple syntaxes to the language
> > was important to support special tasks and repetitive tasks, here is a
> > way of doing it w/o adding complexity to the engine.
> >
> > Further, this allows an uber-designer to create tools for a design group
> > to use to maintain consistancy in look/feel/design.
>
> Na...Turbine already does that. You are getting off focus here.
What about those of us (obviously foolish souls) that don't use Turbine?
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 1:54 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> But we don't add any directives to the language here. I agree with you
> that the core language should remain small. Real small.
How is #isNull not a directive?
> #showSmallTitle( "the title", "red")
>
> where
>
> showSmallTitle(x,y) := <center><b><font color=y>x</font></b></center>
In Turbine, that is:
$navigation.setTemplate("/foo.wm")
Again, #showSmallTitle is a directive because it is prefixed with a #.
> I mean, if it was argued that adding multiple syntaxes to the language
> was important to support special tasks and repetitive tasks, here is a
> way of doing it w/o adding complexity to the engine.
>
> Further, this allows an uber-designer to create tools for a design group
> to use to maintain consistancy in look/feel/design.
Na...Turbine already does that. You are getting off focus here.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 9/24/2000 1:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > True. Hoping not to wade back into the format-layer debate I watched go
> > by, nor rekindle the multiple-syntax idea, how about a preprocessor-like
> > facility so we can build things like this w/o making the language
> > bigger. For example :
> >
> > <input type="text" name="email" value="#isNull($email, "")">
> >
> > where
> >
> > isNull(x,y) := #if (x) { x } #else { y }
> <snip>
>
> There is a difference in my mind between directives (#) and variables ($).
> For simplicity, I really want to keep the number of directives to as few as
> possible because I relate directives to functions. I would however agree
> that we should provide a number of tools to go into the context (ie: like
> WM's ContextTools).
>
But we don't add any directives to the language here. I agree with you
that the core language should remain small. Real small.
> The more that I think about it, the more I'm -1 on $!foo. The reason is that
> it makes us start to look like Perl syntax where you have all sorts of
> "modifiers" on variables and that gets confusing for people very quickly.
Agreed.
> So, to take your proposal one step further:
>
> <input type="text" name="email" value="$tool.Value($email, "")">
>
> That seems perfectly acceptable and is a valid way right now to solve the
> problem without any core language changes.
But when using a template engine, you are basically providing a small
set of programming facilities for the designer to use. Adding a macro
capability doesn't change this : you are simply allowing the
diabolically creative to avoid using constructs like
#set $title="the title"
#set $title_color="red"
#parse "/<directory>/title_show_template.wm
Where title_show_template.wm simply contains
<center>
<b><font color=$title_color>$title</font></b>
</center>
which to me is not only an horrendous abomination from a design point of
view, it's much harder to read than
#showSmallTitle( "the title", "red")
where
showSmallTitle(x,y) := <center><b><font color=y>x</font></b></center>
I mean, if it was argued that adding multiple syntaxes to the language
was important to support special tasks and repetitive tasks, here is a
way of doing it w/o adding complexity to the engine.
Further, this allows an uber-designer to create tools for a design group
to use to maintain consistancy in look/feel/design.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 24 Sep 2000, Jon Stevens wrote:
> on 9/24/2000 2:49 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > That's totally cool. If that's what's decided is best, but I
> > think at least a configuration option would be better so
> > that you didn't have to use a context tool thing to
> > emit an empty string when a reference isn't defined.
>
> Ok, I can find a middle ground here and agree to that. +1
>
> Just promise me: no more funny variable modifiers. You get one and only one.
> :-)
I think $!foo is a special case, and would be quite useful
in things like forms. I certainly wouldn't want a bunch of
perl type things (even though I do love Larry!).
And the feature is very easy to add/remove so if people
do agree that it is an ugliness that should be removed, or
a useful shorthand to have then it will take all of
five minutes to make the necessary changes.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 2:49 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> That's totally cool. If that's what's decided is best, but I
> think at least a configuration option would be better so
> that you didn't have to use a context tool thing to
> emit an empty string when a reference isn't defined.
Ok, I can find a middle ground here and agree to that. +1
Just promise me: no more funny variable modifiers. You get one and only one.
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 24 Sep 2000, Jon Stevens wrote:
> >> The more that I think about it, the more I'm -1 on $!foo. The reason is that
> >> it makes us start to look like Perl syntax where you have all sorts of
> >> "modifiers" on variables and that gets confusing for people very quickly.
> >
> > I rather like the shorthand. I think people would get used to some
> > form of shorthand. We could choose a better notation.
> >
> > Maybe we could just have a configuration option for undefined
> > values. If it's undefined then it come's out as an empty
> > string, or whatever you want.
>
> Right, I agree that the shorthand chosen is fine $!. What I'm worried about
> is that this will just be the start of the requests for more shorthand
> things.
I suppose people could ask for things like:
$#list
$_
#end
Which is certainly awful, but that example is a little out
of hand.
> >> So, to take your proposal one step further:
> >>
> >> <input type="text" name="email" value="$tool.Value($email, "")">
> >>
> >> That seems perfectly acceptable and is a valid way right now to solve the
> >> problem without any core language changes.
> >
> > Again, the $!foo reference could be valid but if you prefer
> > to use $tool.Value($email, "") then you can. I actually think most people
> > would prefer to type:
> >
> > <input type="text" name="email" value="$!foo">
> >
> > over
> >
> > <input type="text" name="email" value="$tool.Value($email, "")">
>
> Probably, but the problem with $!foo is that you can't have a default option
> specified. Think of it this way...you code up your entire site with $!foo
> and then you realize that you need to specify a default option for
> everything...what do you do?
For $!foo or $foo we probably could have a configuration
option for the desired output. I think that's what Bob
wanted for iSpock. But if you set the output to be an
empty string if a reference is undefined then you
could simply write:
<input type="text" name="email" value="$email">
> I think that the different notation is simply using a context tool for it.
> :-)
That's totally cool. If that's what's decided is best, but I
think at least a configuration option would be better so
that you didn't have to use a context tool thing to
emit an empty string when a reference isn't defined.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 1:04 PM, "Jason van Zyl" <jv...@periapt.com> wrote:
> On Sun, 24 Sep 2000, Jon Stevens wrote:
>
>> There is a difference in my mind between directives (#) and variables ($).
>> For simplicity, I really want to keep the number of directives to as few as
>> possible because I relate directives to functions. I would however agree
>> that we should provide a number of tools to go into the context (ie: like
>> WM's ContextTools).
>
> A library of tools would be great. Could we move some of the
> utilities that have been created in turbine and move them
> into velocity?
Yes, that would be the plan.
>> The more that I think about it, the more I'm -1 on $!foo. The reason is that
>> it makes us start to look like Perl syntax where you have all sorts of
>> "modifiers" on variables and that gets confusing for people very quickly.
>
> I rather like the shorthand. I think people would get used to some
> form of shorthand. We could choose a better notation.
>
> Maybe we could just have a configuration option for undefined
> values. If it's undefined then it come's out as an empty
> string, or whatever you want.
Right, I agree that the shorthand chosen is fine $!. What I'm worried about
is that this will just be the start of the requests for more shorthand
things.
>> So, to take your proposal one step further:
>>
>> <input type="text" name="email" value="$tool.Value($email, "")">
>>
>> That seems perfectly acceptable and is a valid way right now to solve the
>> problem without any core language changes.
>
> Again, the $!foo reference could be valid but if you prefer
> to use $tool.Value($email, "") then you can. I actually think most people
> would prefer to type:
>
> <input type="text" name="email" value="$!foo">
>
> over
>
> <input type="text" name="email" value="$tool.Value($email, "")">
Probably, but the problem with $!foo is that you can't have a default option
specified. Think of it this way...you code up your entire site with $!foo
and then you realize that you need to specify a default option for
everything...what do you do?
I think that the different notation is simply using a context tool for it.
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 24 Sep 2000, Jon Stevens wrote:
> There is a difference in my mind between directives (#) and variables ($).
> For simplicity, I really want to keep the number of directives to as few as
> possible because I relate directives to functions. I would however agree
> that we should provide a number of tools to go into the context (ie: like
> WM's ContextTools).
A library of tools would be great. Could we move some of the
utilities that have been created in turbine and move them
into velocity?
> The more that I think about it, the more I'm -1 on $!foo. The reason is that
> it makes us start to look like Perl syntax where you have all sorts of
> "modifiers" on variables and that gets confusing for people very quickly.
I rather like the shorthand. I think people would get used to some
form of shorthand. We could choose a better notation.
Maybe we could just have a configuration option for undefined
values. If it's undefined then it come's out as an empty
string, or whatever you want.
> So, to take your proposal one step further:
>
> <input type="text" name="email" value="$tool.Value($email, "")">
>
> That seems perfectly acceptable and is a valid way right now to solve the
> problem without any core language changes.
Again, the $!foo reference could be valid but if you prefer
to use $tool.Value($email, "") then you can. I actually think most people
would prefer to type:
<input type="text" name="email" value="$!foo">
over
<input type="text" name="email" value="$tool.Value($email, "")">
I agree that in the reference $!foo, the notation doesn't really
tell us a lot, but people like a little bit of jargon :-). And
they don't have to use it if they don't want to.
It only took a line in the grammar, and an extra if
statement in the node responsible for resolving references.
It doesn't clutter the grammar by any means. Maybe there is a better
notation?
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Appearance of undefined references
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/2000 1:16 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> True. Hoping not to wade back into the format-layer debate I watched go
> by, nor rekindle the multiple-syntax idea, how about a preprocessor-like
> facility so we can build things like this w/o making the language
> bigger. For example :
>
> <input type="text" name="email" value="#isNull($email, "")">
>
> where
>
> isNull(x,y) := #if (x) { x } #else { y }
>
>
> A basic library of these will solve requests for things like $!var, and
> people can extend it themselves.
>
> And with caching, there should be no performance penalty.
>
> I would volunteer to work on this, if it were deemed wanted.
There is a difference in my mind between directives (#) and variables ($).
For simplicity, I really want to keep the number of directives to as few as
possible because I relate directives to functions. I would however agree
that we should provide a number of tools to go into the context (ie: like
WM's ContextTools).
The more that I think about it, the more I'm -1 on $!foo. The reason is that
it makes us start to look like Perl syntax where you have all sorts of
"modifiers" on variables and that gets confusing for people very quickly.
So, to take your proposal one step further:
<input type="text" name="email" value="$tool.Value($email, "")">
That seems perfectly acceptable and is a valid way right now to solve the
problem without any core language changes.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Appearance of undefined references
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Daniel L. Rall" wrote:
>
> Jason van Zyl wrote:
>
> SNIP
>
> > So if you had the following line:
> >
> > <input type="text" name="email" value="$!email">
> >
> > and $email had not yet been defined then the
> > output would look like this:
> >
> > <input type="text" name="email" value="">
> >
> > I tried implementing it this feature and it
> > works fine. Is it something that should be
> > added?
>
> I like the idea, but find the use of '!' a little confusing. Of course,
> I just woke up... ;)
True. Hoping not to wade back into the format-layer debate I watched go
by, nor rekindle the multiple-syntax idea, how about a preprocessor-like
facility so we can build things like this w/o making the language
bigger. For example :
<input type="text" name="email" value="#isNull($email, "")">
where
isNull(x,y) := #if (x) { x } #else { y }
A basic library of these will solve requests for things like $!var, and
people can extend it themselves.
And with caching, there should be no performance penalty.
I would volunteer to work on this, if it were deemed wanted.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Appearance of undefined references
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> Hi,
>
> I wanted to see what people thought of a shorthand
> notation to control the appearance of undefined
> references. This is something that iSpock does and
> I would like to borrow the following feature. If a
> logical not symbol immediately follows the dollar
> sign in a reference, it takes up no space in the
> output if it is undefined.
>
> So if you had the following line:
>
> <input type="text" name="email" value="$!email">
>
> and $email had not yet been defined then the
> output would look like this:
>
> <input type="text" name="email" value="">
>
> I tried implementing it this feature and it
> works fine. Is it something that should be
> added?
I like the idea, but find the use of '!' a little confusing. Of course,
I just woke up... ;)
--
Daniel Rall <dl...@finemaltcoding.com>