Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Justin Wells <jr...@semiotek.com>]

On Fri, Sep 01, 2000 at 03:06:19PM -0400, Travis Low wrote:
> Exactly.  Speaking of which, would it be possible to decouple the
> parser a bit and allow different templating languages on the front
> end?

This is a feature that WebMacro has and I would urge Velocity to 
adopt something like this as well. It is my belief that in a few 
years there *will* be some good XML editing tools on the market and
there will be advantage in being able to support an XML front end.

WebMacro's parser is pluggable. One option that I have always 
strongly advocated for Velocity is to take advantage of that plug
point and plug the Velocity parser right into WM's build process.
That buys you instant semantic compatibility with the whole WM 
framework, at almost no cost. You could override and/or replace
just those parts you had issues with.

Plugging the Velocity parser in WM would require some changes on 
both sides for the smoothest transition. We would have to view 
some WM directives (foreach, if, set, etc.) as being "built in"
to the language, but continue to support the idea that additional
directies could be plugged in. 

The advantage of separating the parser from the build process is
that you can add new directies to the language without having
to touch the parser. For an end user, that means not opening
up the .jar and fiddling with stuff--you just write your new 
directive and drop it into the config file.

Pluggable directivese also end the eternal debates about what
should or should not be part of the syntax. Some people think
we should have a #while directive, whereas others think that
HTML folk shouldn't be given the opportunity to make a 
programmer error like an infinite loop. With pluggable 
directives everybody can choose: like having a while? It's
trivial to add. Don't like #set? Remove it!

Justin

Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Justin Wells <jr...@semiotek.com>]

On Fri, Sep 01, 2000 at 01:20:39PM -0700, Jon Stevens wrote:
> Right, this is something though that would be better served with a better
> thought out ContextTool though. It is also possible to do this just as
> easily...
> 
> $Response.Content-Type("text/html")

I'm planning to remove the round bracket hack from WM as soon as
I come up with a better way to introspect into methods that do not
follow the java beans conventions. They look like code, they confuse
people, and they bind the template to a particular implementation:

    $Foo.Bar

Good: I don't have any idea how this is implemented. But:

    $Foo.getBar()

Now in my template I am requiring the programmer to implement a getBar() 
method rather than making Foo a hashtable with a Bar key.

This violates the principle that everyone should own their own work: the
page designer is telling the programmer how to write code. 

Provisionally WM needs the round bracket hack to allow you to access
some very common objects.  But it's controversial. It's the first
thing people bring up when they try and argue that WM is not really
MVC, and they have a point--it needs to
go away.

Justin


> 
> > The servlet shouldn't be doing that one because it's totally a view issue,
> > but on the other hand, how do you proramatically distinguish that from this:
> > 
> > #set $Cookie.user = "fred"
> > 
> > which arguably the HTML guy has no business doing.
> 
> Yep. I agree.
> 
> -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: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Jon Stevens <jo...@latchkey.com>]

on 9/1/2000 1:15 PM, "Justin Wells" <jr...@semiotek.com> wrote:

> Yeah. You'll notice that WM has no "while" directive even though it would
> only take about 15 lines of code to implement it :-)
> 
> I just used that as an example. Less clear are whether or not things
> like sub-page caching should be under the control of the HTML folk. Also
> I can imagine someone wanting to remove #set from the template syntax,
> or using a version that was restricted in what it could do.
> 
> I'd outright restrict it but it has a few important uses:
> 
> #set $Response.Content-type = "text/html"

Right, this is something though that would be better served with a better
thought out ContextTool though. It is also possible to do this just as
easily...

$Response.Content-Type("text/html")

> The servlet shouldn't be doing that one because it's totally a view issue,
> but on the other hand, how do you proramatically distinguish that from this:
> 
> #set $Cookie.user = "fred"
> 
> which arguably the HTML guy has no business doing.

Yep. I agree.

-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: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Justin Wells <jr...@semiotek.com>]

On Fri, Sep 01, 2000 at 12:57:33PM -0700, Jon Stevens wrote:

> Part of the mentality I would like to fight is the idea of adding stuff like
> (#while) to the language. Part of the reason why JSP and even the Servlet
> Spec is such a mess today is because Sun has clients that mandate that
> certain things are added. Who is Sun to say no to paying clients?

Yeah. You'll notice that WM has no "while" directive even though it would
only take about 15 lines of code to implement it :-) 

I just used that as an example. Less clear are whether or not things 
like sub-page caching should be under the control of the HTML folk. Also
I can imagine someone wanting to remove #set from the template syntax,
or using a version that was restricted in what it could do.

I'd outright restrict it but it has a few important uses:

    #set $Response.Content-type = "text/html"

The servlet shouldn't be doing that one because it's totally a view issue, 
but on the other hand, how do you proramatically distinguish that from this:

    #set $Cookie.user = "fred"

which arguably the HTML guy has no business doing.

Justin

Re: User Design Issues, principle, and the whole philosophy (who is your customer, anyway?

[Jon Stevens <jo...@latchkey.com>]

on 9/1/2000 12:44 PM, "Justin Wells" <jr...@semiotek.com> wrote:

> Pluggable directivese also end the eternal debates about what
> should or should not be part of the syntax. Some people think
> we should have a #while directive, whereas others think that
> HTML folk shouldn't be given the opportunity to make a
> programmer error like an infinite loop. With pluggable
> directives everybody can choose: like having a while? It's
> trivial to add. Don't like #set? Remove it!
> 
> Justin

Justin and everyone, please read this email a couple times before you
respond.

Part of the mentality I would like to fight is the idea of adding stuff like
(#while) to the language. Part of the reason why JSP and even the Servlet
Spec is such a mess today is because Sun has clients that mandate that
certain things are added. Who is Sun to say no to paying clients?

At some level, having Velocity at a high level position (ie: in the ASF)
allows us to resist that type of feature crap (like adding #while and #begin
and #end). When we get a specification document together, that will improve
this stance even further because we can just declare that we are
implementing the specification and there can be a process towards changing
the specification which will lead to intelligent discussion vs. changing the
product.

Another good example of this is that I refused (for years now), even though
I was flamed to hell about it, to add "servlet chaining" features to JServ.
I was able to accomplish this because JServ does not have paying clients.
People who use JServ do have paying clients, but most of the time, the fact
that JServ didn't support that (non-servlet spec) feature showed people that
servlet chaining was indeed a really bad idea. What eventually came out of
it was a better proposal (from Craig) that solved the problems with servlet
chaining and the specification was changed to reflect that. In fact, there
is some stuff in the 2.3 servlet spec along these lines that I can't talk
about right now because I'm under a stupid NDA. A good portion of it was my
design and influence.

I think that by showing people that things are not such a good idea (ie:
being a role model) will help us not only educate people about what is good
for them, but also for the entire product. Of course, who are we to say what
is good and what is bad? Well, I think that someone has to because otherwise
we get into the JSP situation and it might as well be us doing the educating
since we are the experts on this stuff.

In other words, I do not subscribe to the idea that giving people bullets to
shoot themselves in the foot if they want to is a good idea. It ends up just
complicating things for everyone. I do however subscribe to the model of
giving people the ability to buy a bong and if they want to stick pot
(illegal) or tobacco (legal) into it, that is up to them.

:-)

-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/