You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Daniel L. Rall" <dl...@finemaltcoding.com> on 2000/08/30 20:40:07 UTC
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet
CGITool.java CookieTool.java FormListTool.java FormTool.java
RequestTool.java ResponseTool.java SessionTool.java
jvanzyl@locus.apache.org wrote:
>
> jvanzyl 00/08/30 01:16:05
>
> Added: src/java/org/apache/velocity/servlet CGITool.java
> CookieTool.java FormListTool.java FormTool.java
> RequestTool.java ResponseTool.java SessionTool.java
> Log:
> - place holders for WM ContextTool compatibility. Discussion need as
> to how these should be implemented. Stand-alone or provide a
> Turbine/Velocity combination as a replace for WebMacro.
+1 on moving this functionality into Turbine. It does not belong in a
templating engine, but does belong in a web applications framework
(Turbine).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet
CGITool.java CookieTool.java FormListTool.java FormTool.java
RequestTool.java ResponseTool.java SessionTool.java
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
dave wrote:
> [snip]
> > > > > Log:
> > > > > - place holders for WM ContextTool compatibility. Discussion need as
> > > > > to how these should be implemented. Stand-alone or provide a
> > > > > Turbine/Velocity combination as a replace for WebMacro.
> > > >
> > > > +1 on moving this functionality into Turbine. It does not belong in a
> > > > templating engine, but does belong in a web applications framework
> > > > (Turbine).
> > >
> > > But what if someone wants to use Velocity without Turbine? I think we
> > > should at least provide a services like interface so these can be added by
> > > users that are not using Turbine.
> >
> > These interface and the functionality that they represent make no sense
> > in a non-web app.
> Right...but what if they want to do web apps w/o turbine? I realize this
> is probably a small population, so for now I agree that we should move it
> to turbine, but maybe in the future we could at least add an interface into
> Velocity so folks could bolt on if desired.
In that case, the interface should be much more generic, similar to a
Turbine Service. -1 on including any such interface, since it already
exists in Turbine and would be duplicate functionality.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet CGITool.java CookieTool.java FormListTool.java FormTool.java RequestTool.java ResponseTool.java SessionTool.java
Posted by dave <da...@miceda-data.com>.
On Wed, 30 Aug 2000, you wrote:
> dave wrote:
> >
> > On Wed, 30 Aug 2000, you wrote:
> > > jvanzyl@locus.apache.org wrote:
> > > >
> > > > jvanzyl 00/08/30 01:16:05
> > > >
> > > > Added: src/java/org/apache/velocity/servlet CGITool.java
> > > > CookieTool.java FormListTool.java FormTool.java
> > > > RequestTool.java ResponseTool.java SessionTool.java
> > > > Log:
> > > > - place holders for WM ContextTool compatibility. Discussion need as
> > > > to how these should be implemented. Stand-alone or provide a
> > > > Turbine/Velocity combination as a replace for WebMacro.
> > >
> > > +1 on moving this functionality into Turbine. It does not belong in a
> > > templating engine, but does belong in a web applications framework
> > > (Turbine).
> >
> > But what if someone wants to use Velocity without Turbine? I think we
> > should at least provide a services like interface so these can be added by
> > users that are not using Turbine.
>
> These interface and the functionality that they represent make no sense
> in a non-web app.
Right...but what if they want to do web apps w/o turbine? I realize this
is probably a small population, so for now I agree that we should move it
to turbine, but maybe in the future we could at least add an interface into
Velocity so folks could bolt on if desired.
--
dave
daveb@miceda-data.com
----------------------
Re: cvs commit:
jakarta-velocity/src/java/org/apache/velocity/servlet CGITool.java
CookieTool.java FormListTool.java FormTool.java RequestTool.java
ResponseTool.java SessionTool.java
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/30/2000 11:49 AM, "Daniel L. Rall" <dl...@finemaltcoding.com> wrote:
> These interface and the functionality that they represent make no sense
> in a non-web app. What if you want to use Velocity--in standalone--to
> generate XML? Why do you want the baggage of a CGITool or a
> CookieTool? I would much rather have a small and super-fast
> *templating* engine, then add a turbine.jar file if I want something
> more than that (to build a web app).
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
Daniel,
Stop. We need to have that functionality. I will talk to you more about it
in person on thurs.
-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: cvs commit:
jakarta-velocity/src/java/org/apache/velocity/servletCGITool.java
CookieTool.java FormListTool.java FormTool.java
RequestTool.javaResponseTool.java SessionTool.java
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
> [snip dlr and dave]
> This is something to discuss. Adding these things for compatibility
> shouldn't affect the performance of the template engine. If we
> have clean interfaces we can probably provide some modes of
> operation, some wrappers for turbine stuff if you're integrating
> Velocity and Turbine. But also provide stand-alone mode so that
> there is a drop in replacement for WM. This will coalesce
> eventually I'm sure. Maybe in time the Velocity/Turbine will
> be the prefered mode and the stand-alone will disappear.
>
> I'm not entirely sure what will happend WRT the requests
> of WM users.
How many people are really using WebMacro's service provider framework?
I'll be you most people are only using its templating capabilities. I
would rather have a drop in replacement for WM's templating
functionality only--that is what drew people to it in the first
place--and avoid code bloat. Those still wishing to use those
facilities can either stick with WM (which still has a bright
development future as a Jakarta project), or use Velocity + Turbine or
their own homegrown system (similar the JServ/Tomcat upgrade path).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Queries about WM Introspection engine
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
Here's a cleaner version. I suppressed the creation
of the Parameters node, and the Parameter(). I'm looking
for a way to suppress the Reference nodes inside a Reference
so that I can get a straight list i.e. something like
Reference
Identifier
Identifier
Identifer
.
.
.
Identifier
There's a way. I'm just looking :) Then it can be
straight fed into the introspection engine. My
the intro engine could just take a node and
walk it instead of taking an array of objects.
Just thinking out loud.
Anyway here's a cleaned up version:
$this.Person.Is.There.To.get($this,$that,$the,$the.Other,"way")
Reference
Identifier -> this
Identifier -> Person
Identifier -> Is
Identifier -> There
Identifier -> To
Identifier -> get
Reference
Identifier -> this
Reference
Identifier -> that
Reference
Identifier -> the
Reference
Identifier -> the
Identifier -> Other
StringLiteral -> "way"
$link.setPage("ScarabLogout.wm").setAction("LogoutUser")
Reference
Identifier -> link
Identifier -> setPage
StringLiteral -> "ScarabLogout.wm"
Identifier -> setAction
StringLiteral -> "LogoutUser"
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Queries about WM Introspection engine
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
I've just finished overhauling the parser once again. I'm off
to bed but before I go here's a few notes.
Here are a couple of examples of what the parser does. What
I would like to be able to do is feed the list of
Identifiers and StringLiterals directly into the WM
Introspection engine:
$this.Person.Is.There.To.get($this,$that,$the,$the.Other,"way")
Reference
Identifier -> this
Identifier -> Person
Identifier -> Is
Identifier -> There
Identifier -> To
Identifier -> get
Parameters
Parameter
Reference
Identifier -> this
Parameter
Reference
Identifier -> that
Parameter
Reference
Identifier -> the
Parameter
Reference
Identifier -> the
Identifier -> Other
Parameter
StringLiteral -> "way"
$link.setPage("ScarabLogout.wm").setAction("LogoutUser")
Reference
Identifier -> link
Identifier -> setPage
Parameters
Parameter
StringLiteral -> "ScarabLogout.wm"
Identifier -> setAction
Parameters
Parameter
StringLiteral -> "LogoutUser"
You can use any combination of properties, methods.
Parameters to methods can be variables, properties, methods
and string literals. It can all be nested. I believe
the WM Intro engine can deal with this.
I'm ready to feed the intro engine value. So if a
change has to be made I'd just like to figure out
whether it would easier/more efficient to massage
the data while it's being parsed or slightly
change the signature of the intro engine to take
the output from the parser. This might be more
useful given it's super PITA writing parsers, and
all recursive-decent parsers will produce output
similiar to the above. Then we could play around
with other compiler-compilers like Antlr or
SableCC. Hopefully some JavaCC people will step
forward. I'd really like to bounce some ideas
of someone :)
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet
CGITool.java CookieTool.java FormListTool.java FormTool.java RequestTool.java
ResponseTool.java SessionTool.java
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 30 Aug 2000, Daniel L. Rall wrote:
> dave wrote:
> >
> > On Wed, 30 Aug 2000, you wrote:
> > > jvanzyl@locus.apache.org wrote:
> > > >
> > > > jvanzyl 00/08/30 01:16:05
> > > >
> > > > Added: src/java/org/apache/velocity/servlet CGITool.java
> > > > CookieTool.java FormListTool.java FormTool.java
> > > > RequestTool.java ResponseTool.java SessionTool.java
> > > > Log:
> > > > - place holders for WM ContextTool compatibility. Discussion need as
> > > > to how these should be implemented. Stand-alone or provide a
> > > > Turbine/Velocity combination as a replace for WebMacro.
> > >
> > > +1 on moving this functionality into Turbine. It does not belong in a
> > > templating engine, but does belong in a web applications framework
> > > (Turbine).
> >
> > But what if someone wants to use Velocity without Turbine? I think we
> > should at least provide a services like interface so these can be added by
> > users that are not using Turbine.
>
> These interface and the functionality that they represent make no sense
> in a non-web app. What if you want to use Velocity--in standalone--to
> generate XML? Why do you want the baggage of a CGITool or a
> CookieTool? I would much rather have a small and super-fast
> *templating* engine, then add a turbine.jar file if I want something
> more than that (to build a web app).
This is something to discuss. Adding these things for compatibility
shouldn't affect the performance of the template engine. If we
have clean interfaces we can probably provide some modes of
operation, some wrappers for turbine stuff if you're integrating
Velocity and Turbine. But also provide stand-alone mode so that
there is a drop in replacement for WM. This will coalesce
eventually I'm sure. Maybe in time the Velocity/Turbine will
be the prefered mode and the stand-alone will disappear.
I'm not entirely sure what will happend WRT the requests
of WM users.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet
CGITool.java CookieTool.java FormListTool.java FormTool.java
RequestTool.java ResponseTool.java SessionTool.java
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
dave wrote:
>
> On Wed, 30 Aug 2000, you wrote:
> > jvanzyl@locus.apache.org wrote:
> > >
> > > jvanzyl 00/08/30 01:16:05
> > >
> > > Added: src/java/org/apache/velocity/servlet CGITool.java
> > > CookieTool.java FormListTool.java FormTool.java
> > > RequestTool.java ResponseTool.java SessionTool.java
> > > Log:
> > > - place holders for WM ContextTool compatibility. Discussion need as
> > > to how these should be implemented. Stand-alone or provide a
> > > Turbine/Velocity combination as a replace for WebMacro.
> >
> > +1 on moving this functionality into Turbine. It does not belong in a
> > templating engine, but does belong in a web applications framework
> > (Turbine).
>
> But what if someone wants to use Velocity without Turbine? I think we
> should at least provide a services like interface so these can be added by
> users that are not using Turbine.
These interface and the functionality that they represent make no sense
in a non-web app. What if you want to use Velocity--in standalone--to
generate XML? Why do you want the baggage of a CGITool or a
CookieTool? I would much rather have a small and super-fast
*templating* engine, then add a turbine.jar file if I want something
more than that (to build a web app).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet
CGITool.java CookieTool.java FormListTool.java FormTool.java RequestTool.java
ResponseTool.java SessionTool.java
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 30 Aug 2000, dave wrote:
> On Wed, 30 Aug 2000, you wrote:
> > jvanzyl@locus.apache.org wrote:
> > >
> > > jvanzyl 00/08/30 01:16:05
> > >
> > > Added: src/java/org/apache/velocity/servlet CGITool.java
> > > CookieTool.java FormListTool.java FormTool.java
> > > RequestTool.java ResponseTool.java SessionTool.java
> > > Log:
> > > - place holders for WM ContextTool compatibility. Discussion need as
> > > to how these should be implemented. Stand-alone or provide a
> > > Turbine/Velocity combination as a replace for WebMacro.
> >
> > +1 on moving this functionality into Turbine. It does not belong in a
> > templating engine, but does belong in a web applications framework
> > (Turbine).
>
> But what if someone wants to use Velocity without Turbine? I think we
> should at least provide a services like interface so these can be added by
> users that are not using Turbine.
Sounds good to me.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: cvs commit: jakarta-velocity/src/java/org/apache/velocity/servlet CGITool.java CookieTool.java FormListTool.java FormTool.java RequestTool.java ResponseTool.java SessionTool.java
Posted by dave <da...@miceda-data.com>.
On Wed, 30 Aug 2000, you wrote:
> jvanzyl@locus.apache.org wrote:
> >
> > jvanzyl 00/08/30 01:16:05
> >
> > Added: src/java/org/apache/velocity/servlet CGITool.java
> > CookieTool.java FormListTool.java FormTool.java
> > RequestTool.java ResponseTool.java SessionTool.java
> > Log:
> > - place holders for WM ContextTool compatibility. Discussion need as
> > to how these should be implemented. Stand-alone or provide a
> > Turbine/Velocity combination as a replace for WebMacro.
>
> +1 on moving this functionality into Turbine. It does not belong in a
> templating engine, but does belong in a web applications framework
> (Turbine).
But what if someone wants to use Velocity without Turbine? I think we
should at least provide a services like interface so these can be added by
users that are not using Turbine.
--
dave
daveb@miceda-data.com
----------------------