Sessions

[Bojan Smojver <bo...@binarix.com>]

Does VelocityServlet have a 'prescribed' mechanism of handling sessions?
Or, is this something left to programmer's discretion?

Bojan

Re: Sessions

[Bojan Smojver <bo...@binarix.com>]

Thanks.

Hopefully the URL-to-URL hook will be implemented in Apache 2.0 to avoid
using proxy just for this.

Bojan

> What I meant is that you would still use rewrite, but the flags would be
> [P,QSA] to force the rewritten URL up into mod_proxy, which allows it to
> go out to tomcat straight away (or that was the only way I could get it
> to work and preserve POST form vars...) rather than a redirect
> back-and-forth.
> 
> geir
> 
> --
> Geir Magnusson Jr.                               geirm@optonline.net
> Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Sessions

["Geir Magnusson Jr." <ge...@optonline.net>]

Bojan Smojver wrote:
> 
> "Geir Magnusson Jr." wrote:
> 
> > > RewriteRule ^/(.*)\.velocity$
> > > /servlet/handler?page=$1.vm&%{QUERY_STRING} [R]
> > >
> >
> > I don't think you have to redirect, do you?  Why not just proxy it -
> > that way any POST parameters make it across - a redirect will lose
> > them....
> 
> Very true. But I'm not sure how would this:
> 
> http://www.somedomain.com/products/catalogue.velocity
> 
> become this:
> 
> http://www.somedomain.com/servlet/handler?page=products/export/catalogue.vm
> 
> using mod_proxy. It isn't very important anyway. Pure cosmetics.

What I meant is that you would still use rewrite, but the flags would be
[P,QSA] to force the rewritten URL up into mod_proxy, which allows it to
go out to tomcat straight away (or that was the only way I could get it
to work and preserve POST form vars...) rather than a redirect
back-and-forth.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.net
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Sessions

[Bojan Smojver <bo...@binarix.com>]

"Geir Magnusson Jr." wrote:

> > RewriteRule ^/(.*)\.velocity$
> > /servlet/handler?page=$1.vm&%{QUERY_STRING} [R]
> >
> 
> I don't think you have to redirect, do you?  Why not just proxy it -
> that way any POST parameters make it across - a redirect will lose
> them....

Very true. But I'm not sure how would this:

http://www.somedomain.com/products/catalogue.velocity

become this:

http://www.somedomain.com/servlet/handler?page=products/export/catalogue.vm

using mod_proxy. It isn't very important anyway. Pure cosmetics.

Bojan

Re: Sessions

["Geir Magnusson Jr." <ge...@optonline.net>]

Bojan Smojver wrote:
>
> So, how do we get something like this to work:
> 
> http://www.somedomain.com/products/catalogue.velocity
> 
> In Apache (IIS anyone?) one would do:
> 
> RewriteRule ^/(.*)\.velocity$
> /servlet/handler?page=$1.vm&%{QUERY_STRING} [R]
> 

I don't think you have to redirect, do you?  Why not just proxy it -
that way any POST parameters make it across - a redirect will lose
them....

I realize this was a minor aspect of the missive you wrote :)  

I like a lot of the ideas in there - if you remember (or look back) on
the vel lists, there was some discussion of how JSP has an advantage
over Velocity in that prototyping is very easy, and your ZuperZervlet
would solve that ...

One thing I can say in support of Turbine (I don't use Turbine) is that
you will get a huge group of enthusiastic and generally friendly people
for support...  that can't be beat sometimes.

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.net
Developing for the web?  See http://jakarta.apache.org/velocity/

Re: Sessions

[Bojan Smojver <bo...@binarix.com>]

I'll have another look at Turbine. That's a promise.

My problem is that I already have a lot of stuff that's running out
there and most of it isn't related to presentation (ie. security and
database access is already worked out). And the presentation is the
layer I'd like to replace (JSP -> Velocity) because JSP's seem like a
big hassle in the long run.

Bojan

> You should really take a look at Turbine, you will really save
> yourself a lot of pain :-) You have a lot of similiar ideas that
> have already been implemented in Turbine. Not that it isn't
> fun to try and write something yourself, but if you need something
> for production use then I would really urge you to look at
> Turbine before trying to roll your own :-)

Re: Sessions

[Jason van Zyl <jv...@apache.org>]

Bojan Smojver wrote:

> Thanks for that, I actually had a look at Turbine and it seems like
> feature complete, quite extensive application environment.
>
> I've seen a few problems with it (totally subjective):
> - I don't think 'pull' model has been implemented yet

Yup. It's been implemented. I'm using it in Tambora, and others
are using now as well. Mostly the UIManager, but other 'pull'
tools will crop up shortly.

>
> - I'm kind of a KISS person and Turbine seems rather big

Turbine has grown to a certain size, everyone who has tried
to make an application framework will wind up with something
similiar to Turbine. It is true that it takes some time to get up
to speed with Turbine if you want to know it thoroughly but
it's worth it. You will end up with something similiar, but
won't have 30-40 other people working on it! Nor will
you have the thousands of hours that have gone into
debugging it.

>
>
> My thinking was this:
> - CGI programs are great because they require no setup but they suck
> because you have to forge HTML from them, they are not platform
> independent (mostly), they are slow and don't have the richness of Java
> API
> - I like having all my docs in a single hierarchy (ie. JSP files mixed
> with HTML files etc.)
> - I don't like fiddling with servlets because it requires a lot of
> concentration and mistakes are usually expensive
>
> So, my plan was to have a single servlet that does everything (I call it
> handler) for a particular virtual host or application. Kinda spooky, but
> I think it can be done.

Yes, the idea of a controller servlet. This is what Turbine does, it
definitely can be done :-)

[snip]

>
>
>
> I don't know if this makes any sense to any of you. Please feel free to
> flame, criticise, contribute or just plain dismiss.
>
> In the meantime, I'm back to building 'The SuperServlet' ;-)

You should really take a look at Turbine, you will really save
yourself a lot of pain :-) You have a lot of similiar ideas that
have already been implemented in Turbine. Not that it isn't
fun to try and write something yourself, but if you need something
for production use then I would really urge you to look at
Turbine before trying to roll your own :-)

>
>
> Bojan
>
> Jason van Zyl wrote:
> > You might want to check out Turbine, it uses Velocity as its
> > template engine but is a framework for making webapps.
> >
> > http://jakarta.apache.org/turbine

--
jvz.

Jason van Zyl
jvanzyl@periapt.com

http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org

Re: Sessions

[Leon Messerschmidt <le...@opticode.co.za>]

Hi,

> I've seen a few problems with it (totally subjective):
> - I don't think 'pull' model has been implemented yet
> - I'm kind of a KISS person and Turbine seems rather big

We've started of with our own servlet based project and I can guarantee you
that it is not worth it.  Although Turbine can seem huge it is very flexible
and you only need to use (and know about) the pieces that you actually use.

If you go your own way it won't be long before you start longing for the
repository of Turbine Services, like Pull, DB Connection Pooling, Global
Cache, XSLT, Built-in Security, etc.  Get the TDK and you'll be up and
running in no time.

~ Leon

Re: Sessions

[Bojan Smojver <bo...@binarix.com>]

Thanks for that, I actually had a look at Turbine and it seems like
feature complete, quite extensive application environment.

I've seen a few problems with it (totally subjective):
- I don't think 'pull' model has been implemented yet
- I'm kind of a KISS person and Turbine seems rather big

My thinking was this:
- CGI programs are great because they require no setup but they suck
because you have to forge HTML from them, they are not platform
independent (mostly), they are slow and don't have the richness of Java
API
- I like having all my docs in a single hierarchy (ie. JSP files mixed
with HTML files etc.)
- I don't like fiddling with servlets because it requires a lot of
concentration and mistakes are usually expensive

So, my plan was to have a single servlet that does everything (I call it
handler) for a particular virtual host or application. Kinda spooky, but
I think it can be done.

Servlet entry in web.xml would use a single parameter (other than
velocity.properties) which would be the name of a standard Java
properties file (or maybe XML?) that contains all the necessary 'pull'
bits. Unlike servlet init parameters, this file would be reloadable at
runtime, just like velocity macros are. This would ensure that
everything that needs to be pulled, gets pulled and at runtime.

Something like this would prepare the building blocks for page designers
(total pseudo code, no bearing on reality whatsoever):

page.nameofpagebean=com.somedomain.someproject.SomeClass       # page
scope
session.nameofsessionbean=com.somedomain.someproject.SomeClass # session
scope
...

by loading appropriate things into the session, application or just
straight into the Velocity context.

The other use of such a file could be security per bean (again, pseudo
code):

action.read.nameofthebean=exporters,importers,managers
action.write.nameofthebean=exporters,managers
action.delete.nameofthebean=exporters,managers

since the only servlet ever running (handler) would always 'pull' the
beans, it could easily pass to the bean (a bit of introspection here)
the permissions defined for the role of the user currently logged on. If
no user logged on, the servlet would go to logon first... pretty
standard. Failure of the bean to handle permissions (if specified in the
file) would render it unusable, to prevent security problems. It would
be up to the bean to implement the permissions properly and enable
certain functionality, while exposing what can be done (ie. which
actions are allowed) to the page designers through the use of regular
getXXX() methods. This would give page designers ability to easily steer
the flow of the page around the current security constraints while
preventing misuse.

The security could also be worked out per page (per velocity macro) in
conjunction to beans.

The next problem is URL's. I quite dislike:

http://www.somedomain.com/servlet/handler?page=catalogue

as an entry somewhere in the menu of the site or a URL on the page.

I think this is one of the good features of JSP's. They are in fact real
pages to the web server (or at least their URL's appear as such). To
give the URL's of the servlet the look of JSP's but without the
edit->transform->compile->load->run overhead, one could use
servlet-mapping in web.xml file. But that requires Tomcat restarts every
time there is a new page.

So, how do we get something like this to work:

http://www.somedomain.com/products/catalogue.velocity

In Apache (IIS anyone?) one would do:

RewriteRule ^/(.*)\.velocity$
/servlet/handler?page=$1.vm&%{QUERY_STRING} [R]

Which is not the happiest of the solutions but should work OK. After
all, once they hit the application itself, things would already be
redirected to the correct URL. Note that this would produce page
arguments that can contain subdirectories as well. For instance:

http://www.somedomain.com/products/export/catalogue.velocity

would be redirected to:

http://www.somedomain.com/servlet/handler?page=products/export/catalogue.vm

So, all you need to do is put the velocity macro files in your normal
htdocs directory, mixed with regular HTML, and point the root directory
of the velocity macros to the root of HTML docs.

The above might cause a hiccup or two. Passing parameters from page to
page with Apache redirection is a bit scary...

You might want to do something like this in Apache:

<LocationMatch "\.vm$">
    AllowOverride None
    deny from all
</LocationMatch>

To prevent people from viewing velocity macro files directly through the
browser, while preserving one document hierarchy. Or you can leave that
out on your development box to view the macro files through the browser
for convenience.

The end result:
- to create a new app, you would need to create one entry in web.xml
file that never changes; you might do that for all virtual hosts, just
to let page designers play
- page designers would have no need to ask Java programmers to change
the servlet since it would always remain the same
- it would be trivial to plug in decent security system through the use
of above mentioned properties file, which is modifiable at runtime
(unlike Tomcat's realms vs. roles)
- Java programmers would only ever do Java model programming, building
new blocks for page designers to use
- Java programmers would be the only ones that can do security sensitive
stuff
- system administrators would take care of the properties files in the
live environments - the way it should be
- Tomcat/Apache would never have to be rastarted unless you have a new
virtual host (new client?)

I really liked Jon's idea of the 'pull' model and I don't believe that
page designers should generate Java code (JSP's) at all. The performance
gain is probably negligent when compared to Velocity's user of context.
And flexibilitly is much better with Velocity. Plus, with a concept as
above, you just start the engine once and feed data and code to it as
you wish and when you wish. As new building blocks become available,
page designers can do new things with them, while the middle layer
(servlet) is never touched.

I don't know if this makes any sense to any of you. Please feel free to
flame, criticise, contribute or just plain dismiss.

In the meantime, I'm back to building 'The SuperServlet' ;-)

Bojan

Jason van Zyl wrote:
> You might want to check out Turbine, it uses Velocity as its
> template engine but is a framework for making webapps.
> 
> http://jakarta.apache.org/turbine

Re: Sessions

[Jason van Zyl <jv...@apache.org>]

Bojan Smojver wrote:

> Does VelocityServlet have a 'prescribed' mechanism of handling sessions?
> Or, is this something left to programmer's discretion?
>
> Bojan

You might want to check out Turbine, it uses Velocity as its
template engine but is a framework for making webapps.

http://jakarta.apache.org/turbine


--
jvz.

Jason van Zyl
jvanzyl@periapt.com

http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org