RE: You make the decision

["Geir Magnusson Jr." <gm...@xyris.com>]

 From: David Esposito [mailto:esposito@newnetco.com]

> Ok, I know this is going to bring on some flames ... but whatever ...

Flames are good - given your current energy crisis and price of heating oil
here in the northeast, I need some additional heat.... :)

> The article brings up some pretty interesting points and certainly
> illustrates a lot of the reasons why we ultimately decided to
> use Velocity for our project. But it is certainly not a resource for
> someone that is trying to "make the decision" ... It doesn't even come
close
> to illustrating  any of the downsides of using Velocity (or any true MVC
> architecture) ... a very one-sided article by almost anyone's standards
...

To start off,  keep in mind that I don't speak for Jon - he is the author.
I have opinions about what YMTD is saying, but it is only my interpretation.

I think your observation isn't off base, but I don't think that YMTD was
meant to cover really cover both sides like that.  I think that Jon was very
honest in describing what he was setting out to do - to "compare what it is
like to do the job with each of the tools.", and as it is a 'living
document' of sorts, I am sure that he would be happy to address and debate
any valid concerns you have.  If there is a quality about Jon that I think
won't be debated, it is that he is honest, open, and truly cares about what
he works on.

 I would think it interesting to get an argument from the 'other side' - the
how the disadvantages of Velocity or template engines in general (WM?) are
solved by JSP.   Maybe we should invite Craig McClanahan or another to argue
the other side - either as an answer to YMTD or a making the case
independantly - then maybe someone like yourself could try to bring the two
together from a 'user' point of view.

> One particular peeve I have about the article is its lack of
> illustrating
> one point ... prototyping an application ... One of the
> reasons that Cold
> Fusion and JSP have gained such market share is because the
> first person to
> take a whack at a prototype for an application is often the
> web designer ...
> Non-developers can build screen shots and even demonstrate some basic
> functionality by using a few <CFOUTPUT> or <%= %> tags and a
> few HREF links
> ... On the other hand, building a prototype by a non-developer using
> Velocity is not possible. Every page must be constructed
> using a back-end
> servlet ... This means that the prototype and the production
> app must be two
> independent projects (unless you want to allocate a developer
> to build a
> servlet and modify the deployment descriptor for the web app
> for each page
> that the designer wants to add)...

I think that when you combine Velocity with  an application 'framework' this
issue isn't as important.  By framework, I mean something as elaborate as
Turbine, or as simple as a 'generic' servlet that loads the context with a
set of objects specified in a configuration file - towards the Pull Model,
maybe.  Something as simple as a config file for the servlet containing
name/class  pairs to stuff into the context to be made available to the
designer, and specify the template to be rendered in the request to the
servlet.  In that way, you can establish the setup where a designer can just
'go at it' and still remain within the boundaries of the objects / tools
they are to use.  Futher, the programmer is only involved to make new
objects for the designer to use - something that has to be done in a JSP
environment anyway.

That would be a complete solution for the above - as long as the objects the
designer needed were in existance, they could easily put them into the
config for their servlet, and have at it creating their template.

Maybe I will write this and put in a contrib area - I don't think it belongs
in the Vel core (here we go again....), but certainly would help people in
this way.

Now, this does move away slightly from orthodox MVC, but no more than the
'Pull Model'.  Maybe a little more, as the designer can take control of the
Controller layer by specifying the template to show in the requests, but
still - it's for prototyping.

Of course, I would think that you would take the prototype and build a more
structured production app from it :)

You have the freedom to work with Velocity in any way you choose.  Bare
bones, it won't satisfy the rapid prototyping you are talking about, but
with a *tiny* bit of work, I think you can build an environment pretty
quickly that supports it.

> Yes, I know ... you may think that I have a pretty weak
> argument ... But in
> practice, using the same language/technology for the
> production application
> and the prototype does amazing things for speed of
> development ... Several
> web projects that I worked on had incredible speed increases
> because the
> designer and I were working on the same physical project and
> I could add
> functionality to the pages that he already designed and
> linked ... and vice
> versa ...

I think that what you bring up is an important issue.  I believe that
production and development process and practice certainly must be considered
in what we are doing - if not, the stuff we are building won't get used by
anyone but us, and that would be a shame.

> Like I said ... ultimately, we decided to go with Velocity
> but it certainly
> wasn't a 'no-brainer' like the article implies it should be ...

Please keep reporting back here on what you find - how it is to use.  Like I
said above, I think that real-life feedback about production use is very
important - I try to use Velocity exclusivly in my commercial consulting
work, and it has provided an enormous amount of insight for me about its use
that I turn around and put back into the project.

Having a collection of 'best practices' will only make Velocity that much
more valuable all of us.

geir

Re: You make the decision

[Lane Sharman <la...@san.rr.com>]

Hi Simon,

Simon Allaway wrote:

> Lane Sharman wrote:
> >
> > For $.05: always have these two context variables declared: $ApplicationStorage,
> > $SessionStorage. They will save you incalculable amount of time when you want a
> > value to transitively move from web page a to page z.
>
> A follow-up question to the above suggestion.
>
> How do you cope with more than one web server or long sessions?

In other words, how does one implement web clustering? There are several issues and so
I will address only a couple relevant to our exchange.

To do this introduce rmi or an equivalent. I wrote my own before rmi and still use it
because it is far faster than rmi and doesn't get confused about references and is
simpler to understand how to use.

Then, implement a Session interface with two persistent methods:

Hashtable getTransientStorage(); return a vm based Hashtable implementation
and
Hashtable getPersistentStorage(); return a remote hashtable proxy or use
VeryLargeHashtable from Open Doors.

And, of course, make the session identifer persist to the storage server.

Finally, I am careful to introduce unique guids from a sequence server to represent
complex objects. Then, I may pass around the identifier in a query string:

#set $complexView = ViewFactory.createView("NewUserWizard")
#set $complexViewID = $complexView.getViewIdentifier
#set $ignore = $Session.PesistentStorage.put($complexViewID, $complexView)

Now, I can pass around the simple string $complexViewID and get the view object at any
time. And, this view can be managed on the next request by different web server if so
targeted. Normally, I reserve persistent storage for transaction values, not views.
This was for illustration purposes. And, hope this helps some.

-lane

>
>
> I used to have this problem with ASP scripting. There is the magical
> Application or Session variable notion that does exactly what you
> suggest above, but it kind of fell apart when users weren't as quick at
> navigating as we'd like. The sessions would time out making sure the
> user had to go through the entire form (or set of forms) again.
>
> The only way I found to safely (and scalably) keep values from one page
> to the other was using the querystring. I wonder what your thoughts
> might be on this.
>
> Simon
>
> PS: YMTD inspired me to look at Velocity. Nice work guys.
>
> --
> Simon Allaway          |
> University of Chicago  | "It all makes sense now...
> Anthropology           |  ...banner comes with mount"
> 5-4390  Haskell Hall   |                    - Lcoady

--
Lane Sharman
Direct: 858-755-2868
http://corporate.acctiva.com/lane
Settlement via the Net

Re: You make the decision

[Simon Allaway <si...@uchicago.edu>]

Lane Sharman wrote:
> 
> For $.05: always have these two context variables declared: $ApplicationStorage,
> $SessionStorage. They will save you incalculable amount of time when you want a
> value to transitively move from web page a to page z.

A follow-up question to the above suggestion.

How do you cope with more than one web server or long sessions? 

I used to have this problem with ASP scripting. There is the magical
Application or Session variable notion that does exactly what you
suggest above, but it kind of fell apart when users weren't as quick at
navigating as we'd like. The sessions would time out making sure the
user had to go through the entire form (or set of forms) again.

The only way I found to safely (and scalably) keep values from one page
to the other was using the querystring. I wonder what your thoughts
might be on this.

Simon

PS: YMTD inspired me to look at Velocity. Nice work guys.

--
Simon Allaway          |   
University of Chicago  | "It all makes sense now...
Anthropology           |  ...banner comes with mount"  
5-4390  Haskell Hall   |                    - Lcoady

Re: You make the decision

[Lane Sharman <la...@san.rr.com>]

Greetings David:

On the topic of prototyping, Geir is hinting at the following observation. It is
a fallacy to believe that a servlet or java code must drive every template page.
in fact, this is a strait jacket which is actually irrelevant to the mvc
discussion but which does drive a lot of development patterns.

David, to do template development follow this approach (one of many no doubt):

1) Declare a mime type. I use tml.
2) Declare a startup servlet which initializes your application state.
3) Develop a request processor which then builds your session state if you have
this. If you are prototyping at the application level, this step is unneeded.
The mime type is handled by this request processor.
4)
a) Delegate the request, to a template processor which has a single instance of
a context into which you populate properties, application objects
(Class.newInstance()), and, any other proprietarty objects. Some of these steps
can be done once during lazy initialization. This step can be done explicitly as
well to "refresh" your context when property files change for developement
purposes.

b) Finally, the request processor delegates the actual request value, the
template, eg, foo.tml, for parsing and evaluation by a single instance of a
Velocity processor which owns the context. (Not sure about this because I use a
WebMacro processor).

I have classes for all of the above. This is how I do my development now. It
gets me out of the business of writing small, one-off controllers. As new
objects, component families come off the production line for testing, they are
declared in property files and become available to the template designer.

For $.05: always have these two context variables declared: $ApplicationStorage,
$SessionStorage. They will save you incalculable amount of time when you want a
value to transitively move from web page a to page z.

-lane

"Geir Magnusson Jr." wrote:

>  From: David Esposito [mailto:esposito@newnetco.com]
>
> > Ok, I know this is going to bring on some flames ... but whatever ...
>
> Flames are good - given your current energy crisis and price of heating oil
> here in the northeast, I need some additional heat.... :)
>
> > The article brings up some pretty interesting points and certainly
> > illustrates a lot of the reasons why we ultimately decided to
> > use Velocity for our project. But it is certainly not a resource for
> > someone that is trying to "make the decision" ... It doesn't even come
> close
> > to illustrating  any of the downsides of using Velocity (or any true MVC
> > architecture) ... a very one-sided article by almost anyone's standards
> ...
>
> To start off,  keep in mind that I don't speak for Jon - he is the author.
> I have opinions about what YMTD is saying, but it is only my interpretation.
>
> I think your observation isn't off base, but I don't think that YMTD was
> meant to cover really cover both sides like that.  I think that Jon was very
> honest in describing what he was setting out to do - to "compare what it is
> like to do the job with each of the tools.", and as it is a 'living
> document' of sorts, I am sure that he would be happy to address and debate
> any valid concerns you have.  If there is a quality about Jon that I think
> won't be debated, it is that he is honest, open, and truly cares about what
> he works on.
>
>  I would think it interesting to get an argument from the 'other side' - the
> how the disadvantages of Velocity or template engines in general (WM?) are
> solved by JSP.   Maybe we should invite Craig McClanahan or another to argue
> the other side - either as an answer to YMTD or a making the case
> independantly - then maybe someone like yourself could try to bring the two
> together from a 'user' point of view.
>
> > One particular peeve I have about the article is its lack of
> > illustrating
> > one point ... prototyping an application ... One of the
> > reasons that Cold
> > Fusion and JSP have gained such market share is because the
> > first person to
> > take a whack at a prototype for an application is often the
> > web designer ...
> > Non-developers can build screen shots and even demonstrate some basic
> > functionality by using a few <CFOUTPUT> or <%= %> tags and a
> > few HREF links
> > ... On the other hand, building a prototype by a non-developer using
> > Velocity is not possible. Every page must be constructed
> > using a back-end
> > servlet ... This means that the prototype and the production
> > app must be two
> > independent projects (unless you want to allocate a developer
> > to build a
> > servlet and modify the deployment descriptor for the web app
> > for each page
> > that the designer wants to add)...
>
> I think that when you combine Velocity with  an application 'framework' this
> issue isn't as important.  By framework, I mean something as elaborate as
> Turbine, or as simple as a 'generic' servlet that loads the context with a
> set of objects specified in a configuration file - towards the Pull Model,
> maybe.  Something as simple as a config file for the servlet containing
> name/class  pairs to stuff into the context to be made available to the
> designer, and specify the template to be rendered in the request to the
> servlet.  In that way, you can establish the setup where a designer can just
> 'go at it' and still remain within the boundaries of the objects / tools
> they are to use.  Futher, the programmer is only involved to make new
> objects for the designer to use - something that has to be done in a JSP
> environment anyway.
>
> That would be a complete solution for the above - as long as the objects the
> designer needed were in existance, they could easily put them into the
> config for their servlet, and have at it creating their template.
>
> Maybe I will write this and put in a contrib area - I don't think it belongs
> in the Vel core (here we go again....), but certainly would help people in
> this way.
>
> Now, this does move away slightly from orthodox MVC, but no more than the
> 'Pull Model'.  Maybe a little more, as the designer can take control of the
> Controller layer by specifying the template to show in the requests, but
> still - it's for prototyping.
>
> Of course, I would think that you would take the prototype and build a more
> structured production app from it :)
>
> You have the freedom to work with Velocity in any way you choose.  Bare
> bones, it won't satisfy the rapid prototyping you are talking about, but
> with a *tiny* bit of work, I think you can build an environment pretty
> quickly that supports it.
>
> > Yes, I know ... you may think that I have a pretty weak
> > argument ... But in
> > practice, using the same language/technology for the
> > production application
> > and the prototype does amazing things for speed of
> > development ... Several
> > web projects that I worked on had incredible speed increases
> > because the
> > designer and I were working on the same physical project and
> > I could add
> > functionality to the pages that he already designed and
> > linked ... and vice
> > versa ...
>
> I think that what you bring up is an important issue.  I believe that
> production and development process and practice certainly must be considered
> in what we are doing - if not, the stuff we are building won't get used by
> anyone but us, and that would be a shame.
>
> > Like I said ... ultimately, we decided to go with Velocity
> > but it certainly
> > wasn't a 'no-brainer' like the article implies it should be ...
>
> Please keep reporting back here on what you find - how it is to use.  Like I
> said above, I think that real-life feedback about production use is very
> important - I try to use Velocity exclusivly in my commercial consulting
> work, and it has provided an enormous amount of insight for me about its use
> that I turn around and put back into the project.
>
> Having a collection of 'best practices' will only make Velocity that much
> more valuable all of us.
>
> geir

--
Lane Sharman
Direct: 858-755-2868
http://corporate.acctiva.com/lane
Settlement via the Net

VTL syntax, again ... :)

[David Esposito <es...@newnetco.com>]

Is there a way to do the following:

$$price

where the first $ sign gets just printed to the output while the second
$sign gets parsed and returns the value of the price variable?

if i put a space between the two dollar signs, it accomplishes what I want
but I don't like the space ... (hehe ... )