velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: Sessions
Date Fri, 16 Mar 2001 05:24:12 GMT
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

Mime
View raw message