frameworks, tools, and velocity Was: Re: accessing $session when using VelocityLayoutServlet

[Nathan Bubna <na...@esha.com>]

Gonzalo Diethelm said:
> Nathan said:
...
> > but again, while Velocity[Tools]-only design is reasonable
> > for small and simple web applications, i would *highly*
> > recommend using an established framework for anything more complex.
>
> Would you care to mention some specific frameworks you recommend? Your
> answer probably changes from time to time, and depends on what you want to
> do, but anyway I would be interested in frameworks falling under these
> criteria:
>
> * are meant to solve a narrow problem, and solve it well (ex: velosurf)

not sure what you mean here, partly because your example is not something i
would call a true "framework" in this context.

> * are well integrated with (or depend upon) Velocity

well, first there is Turbine.  it's *very* well integrated with Velocity, and
a number of VelocityTools ideas were gleaned from them, though it does not
itself work with VelocityTools.

then there's Struts w/VelocityStruts.  while the Struts folks have not done
much themselves to integrate with Velocity, we (VelocityTools) have certainly
put in the effort to make the two work well together.

there are also several frameworks which seem to have taken steps to integrate
with Velocity on their own.  these include WebWork and Spring.  i have not
used WebWork, but i've looked through their code and docs, and it appears
solid.  my company has recently begun to use Spring with VelocityStruts,
though i'm not presently working on that project.

the other one i hear good things about is Maverick.  by all accounts it is
very clean, well-designed framework (though perhaps with less features than
the rest) that integrates well with pretty much any view layer.  i'm told it
works great with VelocityTools.

the other major java webapp frameworks i hear about are Tapestry and JSF.
although JSF--being a spec--could be implemented in Velocity, it has not been,
and from all i know of Tapestry, i believe that it neither does nor will ever
have anything to do with Velocity.

> Let me rephrase the question under a hypothetical situation: for any of a
> set of projects that you have to embark on (starting from scratch), please
> comment on what tools (besides Velocity ;-) you would use. I would be really
> interested in hearing any opinions for this question; for example:
>
> * for a big, enterprise-functionality project: Velocity, foo bar and, of
> course, baz!

Turbine, Struts, WebWork, Spring, and Maverick would probably all work for
these.

> * for a small, hobbyist-level project: Velocity, bifur, bofur and, usually,
> bombur.

i haven't done this, but i've always figured i'd use VelocityView with
Velosurf and if i needed a bit more convenience/power/features, then i might
throw Maverick or parts of Spring into the mix to help out.

> * etc.
>
> > actually, i haven't yet had the joy of building any java
> > webapps small/simple enough to fit this category.
>
> And what combinations of tools (in addition to Velocity) have you (and
> anybody listening) used in real life projects?

i've used Turbine (with Velocity as view layer), Struts+VelocityStruts, and as
i said, my coworker has begun working with Spring+Struts+VelocityStruts,
though i myself have done little work there.

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: frameworks, tools, and velocity Was: Re: accessing $session when using VelocityLayoutServlet

[Anthony Eden <ae...@signaturedomains.com>]

What kind of an advocate and project maintainer would I be if I didn't 
mention JPublish? ;-)

JPublish is based on the same design principals as Turbine.  Velocity 
was originally the only template language supported by JPublish, 
although now other template engines such as FreeMarker and WebMacro are 
also supported.  Actions (the logic which provides the glue between your 
view and your business logic) can be written in a variety of scripting 
languages or in Java.  JPublish supports global design templates so that 
designers can work on the site design without interferring with 
programmers or content producers.  Design templates also help reduce the 
amount of work needed to maintain a site design since design elements 
are applied to the site as a whole rather than on each page.

I've used JPublish for projects both large and small and have found that 
it works equally well in either case.  Granted it is not as simple as 
throwing together a small site with PHP, but with the included "starter" 
webapp which you can just expand and modify it is pretty easy to get 
small projects up to speed, and the payoff with the separation of 
concerns is worth it in my opinion.

Anyhow, enough evangelizing.  Give JPublish a try: 
http://www.jpublish.org/ .  It's open source and has a very open license 
(Apache-like).

Sincerely,
Anthony Eden

Nathan Bubna wrote:

>Gonzalo Diethelm said:
>  
>
>...
>  
>
>>* are well integrated with (or depend upon) Velocity
>>    
>>
>
>well, first there is Turbine.  it's *very* well integrated with Velocity, and
>a number of VelocityTools ideas were gleaned from them, though it does not
>itself work with VelocityTools.
>
>then there's Struts w/VelocityStruts.  while the Struts folks have not done
>much themselves to integrate with Velocity, we (VelocityTools) have certainly
>put in the effort to make the two work well together.
>
>there are also several frameworks which seem to have taken steps to integrate
>with Velocity on their own.  these include WebWork and Spring.  i have not
>used WebWork, but i've looked through their code and docs, and it appears
>solid.  my company has recently begun to use Spring with VelocityStruts,
>though i'm not presently working on that project.
>
>the other one i hear good things about is Maverick.  by all accounts it is
>very clean, well-designed framework (though perhaps with less features than
>the rest) that integrates well with pretty much any view layer.  i'm told it
>works great with VelocityTools.
>
>the other major java webapp frameworks i hear about are Tapestry and JSF.
>although JSF--being a spec--could be implemented in Velocity, it has not been,
>and from all i know of Tapestry, i believe that it neither does nor will ever
>have anything to do with Velocity.
>
>  
>
>>Let me rephrase the question under a hypothetical situation: for any of a
>>set of projects that you have to embark on (starting from scratch), please
>>comment on what tools (besides Velocity ;-) you would use. I would be really
>>interested in hearing any opinions for this question; for example:
>>
>>* for a big, enterprise-functionality project: Velocity, foo bar and, of
>>course, baz!
>>    
>>
>
>Turbine, Struts, WebWork, Spring, and Maverick would probably all work for
>these.
>
>  
>
>>* for a small, hobbyist-level project: Velocity, bifur, bofur and, usually,
>>bombur.
>>    
>>
>
>i haven't done this, but i've always figured i'd use VelocityView with
>Velosurf and if i needed a bit more convenience/power/features, then i might
>throw Maverick or parts of Spring into the mix to help out.
>
>  
>
>>* etc.
>>
>>    
>>
>>>actually, i haven't yet had the joy of building any java
>>>webapps small/simple enough to fit this category.
>>>      
>>>
>>And what combinations of tools (in addition to Velocity) have you (and
>>anybody listening) used in real life projects?
>>    
>>
>
>i've used Turbine (with Velocity as view layer), Struts+VelocityStruts, and as
>i said, my coworker has begun working with Spring+Struts+VelocityStruts,
>though i myself have done little work there.
>
>Nathan Bubna
>nathan@esha.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

Re: frameworks, tools, and velocity Was: Re: accessing $session when using VelocityLayoutServlet

["Charles N. Harvey III" <ch...@alloy.com>]

Gonzalo Diethelm said the following on 5/25/2004 10:04 PM:

>>>Would you care to mention some specific frameworks you 
>>>      
>>>
>>recommend? Your 
>>    
>>
>>>answer probably changes from time to time, and depends on what you 
>>>want to do, but anyway I would be interested in frameworks falling 
>>>under these
>>>criteria:
>>>
>>>* are meant to solve a narrow problem, and solve it well (ex: 
>>>velosurf)
>>>      
>>>
>>not sure what you mean here, partly because your example is 
>>not something i would call a true "framework" in this context.
>>    
>>
>
>Sorry, wrong use of the term "framework"; I didn't want to call it "tool",
>didn't want to get it mixed with Velocity tools. What I meant was that
>velosurf is an independent project, solving a very specific problem, and
>able to work with (actually, use) Velocity.
>
>  
>
>>>* are well integrated with (or depend upon) Velocity
>>>      
>>>
>>well, first there is Turbine.  it's *very* well integrated 
>>with Velocity, and a number of VelocityTools ideas were 
>>gleaned from them, though it does not itself work with VelocityTools.
>>    
>>
>
>I have worked on several projects with Turbine. While quite good, I have two
>problems with it: 1) it has overextended itself in functionality; 2) it has
>lost most of its maintainers.
>
>  
>
>>then there's Struts w/VelocityStruts.  while the Struts folks 
>>have not done much themselves to integrate with Velocity, we 
>>(VelocityTools) have certainly put in the effort to make the 
>>two work well together.
>>    
>>
>
>Struts would be closer to what I referred to above: it is intended to solve
>a specific problem (web-based user interface & navigational logic), and
>works well with Velocity. What I want is more examples like velosurf and
>Struts.
>
>  
>
>>there are also several frameworks which seem to have taken 
>>steps to integrate with Velocity on their own.  these include 
>>WebWork and Spring.  i have not used WebWork, but i've looked 
>>through their code and docs, and it appears solid.  my 
>>company has recently begun to use Spring with VelocityStruts, 
>>though i'm not presently working on that project.
>>    
>>
>
>I had heard of both of these, don't know much about them. Are they more
>alike Turbine, or Struts, in terms of the width of its goals?
>  
>

WebWork is just like Struts.  They started out both solving the same problem
that is mentioned above (web-based user interface).  I continue to use 
Struts
because I am familiar with it and I really like the Validator framework it
provides.  WebWork has become much larger and it has also integrated 
with other
tools from OpenSymphony (OSWorkFlow, SiteMesh, OSCache...).  The usual 
deal for
a web framework - xml config file, "action" classes that implement an 
interface,
and the possibility of different view sets (jsp, velocity, freemarker, xml).
http://www.opensymphony.com/webwork/

Spring I am still a little new at (and slightly confused by).  From what 
I can tell
so far it is a more elegant framework that can be used for more than 
just web, but
has a web layer built onto it.  It uses Inversion-of-Control (which I'm 
still not
sure what that means) and integrates well with persistence layers like 
Hibernate.
http://www.springframework.org/

>  
>
>>the other one i hear good things about is Maverick.  by all 
>>accounts it is very clean, well-designed framework (though 
>>perhaps with less features than the rest) that integrates 
>>well with pretty much any view layer.  i'm told it works 
>>great with VelocityTools.
>>    
>>
>
>Ditto.
>  
>

Maverick is actually really cool.  Very small, but very easy.  Same deal 
as WebWork
and Struts but with less "stuff".  No persistence and no validation, 
just web framework,
you provide the rest.  The xml config file is very flexible and you can 
use xml/xsl,
velocity or jsp in the same project.  And you can transform views 
multiple times
to provide wrappers around your documents.  It is definately worth 
looking into if
you have a strictly web-based project.
http://mav.sourceforge.net/

>  
>
>>the other major java webapp frameworks i hear about are 
>>Tapestry and JSF. although JSF--being a spec--could be 
>>implemented in Velocity, it has not been, and from all i know 
>>of Tapestry, i believe that it neither does nor will ever 
>>have anything to do with Velocity.
>>    
>>
>
>I know nothing about these two.
>  
>

JSF - Java Server Faces 
(http://java.sun.com/j2ee/javaserverfaces/index.jsp) is Sun's
attempt to have a web framework.  Haven't really had a look at it so I 
can't say much
about it.  Turbine the same.  Its all smoke and mirrors to me so far.  I 
am pretty
sure it builds your app using fragments of html pages and wraps java 
objects around
them with its extensive configuration elements.  Its supposed to be able 
to do many
of the things EJB does but without all the headaches (I guess - I know 
nothing of EJB).


Hope this helped.


Charlie

>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

RE: frameworks, tools, and velocity Was: Re: accessing $session when using VelocityLayoutServlet

[Gonzalo Diethelm <go...@aditiva.com>]

> > Would you care to mention some specific frameworks you 
> recommend? Your 
> > answer probably changes from time to time, and depends on what you 
> > want to do, but anyway I would be interested in frameworks falling 
> > under these
> > criteria:
> >
> > * are meant to solve a narrow problem, and solve it well (ex: 
> > velosurf)
> 
> not sure what you mean here, partly because your example is 
> not something i would call a true "framework" in this context.

Sorry, wrong use of the term "framework"; I didn't want to call it "tool",
didn't want to get it mixed with Velocity tools. What I meant was that
velosurf is an independent project, solving a very specific problem, and
able to work with (actually, use) Velocity.

> > * are well integrated with (or depend upon) Velocity
> 
> well, first there is Turbine.  it's *very* well integrated 
> with Velocity, and a number of VelocityTools ideas were 
> gleaned from them, though it does not itself work with VelocityTools.

I have worked on several projects with Turbine. While quite good, I have two
problems with it: 1) it has overextended itself in functionality; 2) it has
lost most of its maintainers.

> then there's Struts w/VelocityStruts.  while the Struts folks 
> have not done much themselves to integrate with Velocity, we 
> (VelocityTools) have certainly put in the effort to make the 
> two work well together.

Struts would be closer to what I referred to above: it is intended to solve
a specific problem (web-based user interface & navigational logic), and
works well with Velocity. What I want is more examples like velosurf and
Struts.

> there are also several frameworks which seem to have taken 
> steps to integrate with Velocity on their own.  these include 
> WebWork and Spring.  i have not used WebWork, but i've looked 
> through their code and docs, and it appears solid.  my 
> company has recently begun to use Spring with VelocityStruts, 
> though i'm not presently working on that project.

I had heard of both of these, don't know much about them. Are they more
alike Turbine, or Struts, in terms of the width of its goals?

> the other one i hear good things about is Maverick.  by all 
> accounts it is very clean, well-designed framework (though 
> perhaps with less features than the rest) that integrates 
> well with pretty much any view layer.  i'm told it works 
> great with VelocityTools.

Ditto.

> the other major java webapp frameworks i hear about are 
> Tapestry and JSF. although JSF--being a spec--could be 
> implemented in Velocity, it has not been, and from all i know 
> of Tapestry, i believe that it neither does nor will ever 
> have anything to do with Velocity.

I know nothing about these two.

> > * for a small, hobbyist-level project: Velocity, bifur, bofur and, 
> > usually, bombur.
> 
> i haven't done this, but i've always figured i'd use 
> VelocityView with Velosurf and if i needed a bit more 
> convenience/power/features, then i might throw Maverick or 
> parts of Spring into the mix to help out.

Gotcha. Gotta check these out more thoroughly.

> i've used Turbine (with Velocity as view layer), 
> Struts+VelocityStruts, and as i said, my coworker has begun 
> working with Spring+Struts+VelocityStruts, though i myself 
> have done little work there.

It would be grand if you could convince him/her to write a little note with
his/her thoughts about the Spring+Struts+Velocity combination.

> Nathan Bubna
> nathan@esha.com

Thanks for taking the time.


-- 
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org