Re: [Mav-user] opt-freemarker
Thanks Eelco. I'd be more than happy to maintain opt-freemarker but I guess one vote probably isn't sufficient to give me write access. What do you other developers think? Hopefully opt-freemarker won't require any updates anyway, but I'm about to post something to the FreeMarker mailing list and get some feedback from some real FreeMarker users ;-) Your summary of the patch was spot on. As a result of it the DispatchedViewFactory class is no longer required and can be removed. I also noticed that the javadoc for DocumentView needs updating since it still mentions DispatchedView. Ed. - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 11:01 AM Subject: RE: [Mav-user] opt-freemarker I created Maverick 2.2.3 with Ed's patch. I also created Optional Freemarker; maintenance for this packge should be done by somebody else. Eelco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eelco Hillenius Sent: zaterdag 7 augustus 2004 9:48 To: [EMAIL PROTECTED] Subject: RE: [Mav-user] opt-freemarker Hi Ed, I had a chance to look at your changes; looks good. For the other readers: with the patch that Ed proposes, every document view with a path attribute will be a view with transforms internally, the first transform being the dispatch/ document transform with the given path. His patch makes it possible to have document views without a dispatch transform, functionality needed for his opt-freemarker package. If I mis-understood anything, please correct me... If everyone agrees (please take a look at CVS-HEAD) I can make a new build (v 2.2.3) next week. About the opt-freemarker package... It's great that you took the trouble to implement the friendbook example. As I do not work with Freemarker myself, I do not want to maintain it. But, if you'd like, we could give you write access, and you could maintain that module yourself. So, I hereby vote +1 for write access for Ed Ward. What about the other developers? Eelco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Ward Sent: woensdag 4 augustus 2004 3:05 To: [EMAIL PROTECTED] Subject: Re: [Mav-user] opt-freemarker Hi Eelco, I appreciate you're busy at the moment but have you found time to look at the updates to DocumentView? Ed - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 23, 2004 7:27 PM Subject: RE: [Mav-user] opt-freemarker Sounds interesting. I am very busy with other things at the moment though, but I'll try to look at it next week. Cheers, Eelco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Ward Sent: donderdag 22 juli 2004 4:22 To: [EMAIL PROTECTED] Subject: [Mav-user] opt-freemarker Hi, I came across a reference to the FreeMarker templating engine a couple of weeks ago whilst reading up on the Spring framework. It looked pretty interesting so I thought I'd have a go at writing an opt-freemarker package. Unlike Velocity though FreeMarker doesn't have a dispatch servlet but I still wanted to utilise the functionality of DocumentView (the setting of the model bean attribute in the scope specified on the document view). DocumentView currently assumes the use of a dispatcher though so I've made a few updates (attached) that allow the document view type to optionally use the existing DocumentTransform class to perform the task of dispatching the supplied document path rather than use an aggregated DispatchedView instance. The updated DocumentView class no longer needs DispatchedView since the dispatch include/forward is handled by the DocumentTransform that's created when the view configuration is loaded. Could you committers have a look at the updates please and let me know what you think? opt-freemarker is currently dependent on them. many thanks, Ed Ward PS. If you'd like to look at the opt-freemarker package, I've placed a copy at http://www.commlock.freeserve.co.uk/opt-freemarker-20040722.zip (632 KB) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=ick [INVALID FOOTER] --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com [INVALID FOOTER] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Ward Sent: woensdag 4 augustus 2004 3:05 To: [EMAIL PROTECTED] Subject: Re: [Mav-user] opt-freemarker Hi Eelco, I appreciate you're busy at the moment
Re: [Mav-user] opt-freemarker
Hi Eelco, I appreciate you're busy at the moment but have you found time to look at the updates to DocumentView? Ed - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 23, 2004 7:27 PM Subject: RE: [Mav-user] opt-freemarker Sounds interesting. I am very busy with other things at the moment though, but I'll try to look at it next week. Cheers, Eelco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Ward Sent: donderdag 22 juli 2004 4:22 To: [EMAIL PROTECTED] Subject: [Mav-user] opt-freemarker Hi, I came across a reference to the FreeMarker templating engine a couple of weeks ago whilst reading up on the Spring framework. It looked pretty interesting so I thought I'd have a go at writing an opt-freemarker package. Unlike Velocity though FreeMarker doesn't have a dispatch servlet but I still wanted to utilise the functionality of DocumentView (the setting of the model bean attribute in the scope specified on the document view). DocumentView currently assumes the use of a dispatcher though so I've made a few updates (attached) that allow the document view type to optionally use the existing DocumentTransform class to perform the task of dispatching the supplied document path rather than use an aggregated DispatchedView instance. The updated DocumentView class no longer needs DispatchedView since the dispatch include/forward is handled by the DocumentTransform that's created when the view configuration is loaded. Could you committers have a look at the updates please and let me know what you think? opt-freemarker is currently dependent on them. many thanks, Ed Ward PS. If you'd like to look at the opt-freemarker package, I've placed a copy at http://www.commlock.freeserve.co.uk/opt-freemarker-20040722.zip (632 KB) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=ick [INVALID FOOTER] --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com [INVALID FOOTER]
[Mav-user] opt-freemarker
Hi,
I came across a reference to the FreeMarker templating engine a couple of weeks ago
whilst
reading up on the Spring framework. It looked pretty interesting so I thought I'd have
a
go at writing an opt-freemarker package.
Unlike Velocity though FreeMarker doesn't have a dispatch servlet but I still wanted to
utilise the functionality of DocumentView (the setting of the model bean attribute in
the
scope specified on the document view). DocumentView currently assumes the use of a
dispatcher though so I've made a few updates (attached) that allow the document view
type to optionally use the existing DocumentTransform class to perform the task of
dispatching the supplied document path rather than use an aggregated DispatchedView
instance. The updated DocumentView class no longer needs DispatchedView since the
dispatch
include/forward is handled by the DocumentTransform that's created when the view
configuration is loaded.
Could you committers have a look at the updates please and let me know what you think?
opt-freemarker is currently dependent on them.
many thanks,
Ed Ward
PS. If you'd like to look at the opt-freemarker package, I've placed a copy at
http://www.commlock.freeserve.co.uk/opt-freemarker-20040722.zip (632 KB)
/*
* $Id: ViewWithTransforms.java,v 1.1 2002/06/06 12:23:54 lhoriman Exp $
* $Source: /cvsroot/mav/maverick/src/java/org/infohazard/maverick/flow/ViewWithTransforms.java,v $
*/
package org.infohazard.maverick.flow;
import java.io.IOException;
import javax.servlet.ServletException;
/**
* ViewWithTransforms is a decorator that sets transforms when
* rendering a view.
*/
class ViewWithTransforms implements View
{
/** The decorated view */
protected View decorated;
/** The transforms associated with the decorated view */
protected Transform[] transforms;
/**
* @param decorate the view to be decorated
* @param trans the transforms used to decorate the view
*/
public ViewWithTransforms(View decorate, Transform[] trans)
{
if (trans == null || trans.length == 0)
throw new IllegalArgumentException(Don't use this decorator without transforms);
if (decorate instanceof ViewWithTransforms)
{
final ViewWithTransforms other = (ViewWithTransforms)decorate;
final Transform[] transforms = new Transform[trans.length + other.transforms.length];
System.arraycopy(other.transforms, 0, transforms, 0, other.transforms.length);
System.arraycopy(trans, 0, transforms, other.transforms.length, trans.length);
this.transforms = transforms;
this.decorated = other.decorated;
}
else
{
this.decorated = decorate;
this.transforms = trans;
}
}
/**
* @param vctx the view context
* @throws IOException
* @throws ServletException
*/
public void go(ViewContext vctx) throws IOException, ServletException
{
((MaverickContext)vctx).setTransforms(this.transforms);
this.decorated.go(vctx);
}
}/*
* $Id: MasterFactory.java,v 1.3 2004/06/27 17:41:31 eelco12 Exp $
* $Source: /cvsroot/mav/maverick/src/java/org/infohazard/maverick/flow/MasterFactory.java,v $
*/
package org.infohazard.maverick.flow;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import javax.servlet.ServletConfig;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.infohazard.maverick.util.XML;
import org.jdom.Element;
/**
* Factory for creating View and Transform objects. This calls out to specific instances
* of ViewFactory and TransformFactory to actually create the objects.
*/
class MasterFactory
{
/** Logger. */
private static Log log = LogFactory.getLog(MasterFactory.class);
/** xml attribute for type, value = 'type'. */
protected static final String ATTR_FACTORY_TYPE_NAME = type;
/** xml attribute for the factory provider, value = 'provider'. */
protected static final String ATTR_FACTORY_PROVIDER = provider;
/** xml attribute for the type name, value = 'type' */
protected static final String ATTR_TYPE_NAME = type;
/** xml attribute for the transform type name (for a view node), value = 'transform-type' */
protected static final String ATTR_TRANSFORM_TYPE_NAME = transform-type;
/** xml tag name for a transform, value = 'transform'. */
public static final String TAG_TRANSFORM = transform;
/**
* Holds mapping of typeName to ViewFactory.
*/
protected Map viewFactories = new HashMap();
/**
* Holds mapping of typeName to TransformFactory.
*/
protected Map transformFactories = new HashMap();
/**
* The default type of factory to use if no explicit type is set.
*/
protected String defaultViewType;
/**
* The default type of factory to use if no explicit type is set
Re: [Mav-user] Re: Unit Testing Maverick
Thanks Jeff. Yes I suppose if there's anything worth testing with JUnit in the servlet/controller objects its probably an indication that there's business logic there that would be better placed in an EJB or java object in the business tier. I haven't had the need to test any maverick controllers so it's not something I'd thought about. (The fact I hadn't needed to test any should have been a big clue. :-]) Ed. - Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 7:34 PM Subject: RE: [Mav-user] Re: Unit Testing Maverick What kind of testing? What kinds of errors are you trying to catch? JUnitEE is great for testing business logic, but if you want to exercise Maverick controllers you either need Mock Objects for the maverick/servlet objects or you need to test them live in the servlet container. If you're testing them in the servlet container, you really need something like HTTPUnit - you're not really running JUnit tests, you're exercising the HTTP frontend. Personally, I focus on unit testing the business logic (stored in EJBs and application-domain classes) and leave the frontend logic (including Maverick controllers) to eyeball functional testing. Since I've pushed all the high-risk logic into the backend, testing the frontend is more a question of is it formatted properly rather than does it display the right numbers. If you have unit tests for your business classes, and load test scripts to verify that you get the right pages when you navigate your application, you should be pretty well covered. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Ed Ward [mailto:ed;whatsa.co.uk] Sent: Wednesday, November 06, 2002 2:26 AM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] Re: Unit Testing Maverick Jeff, why wouldn't you consider using JUnitEE for this? Ed. - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Holt, Jack C. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 5:20 AM Subject: [Mav-user] Re: Unit Testing Maverick I don't know of anything - anyone else? On Fri, Nov 01, 2002 at 11:19:45AM -0800, Holt, Jack C. wrote: I'm a fan of Maverick. It seems to implement MVC without the high levels of abstraction with approaches such as Struts. I'm currently trying figure out how to unit test the maverick controllers (classes that implement Controller) which I've written. I've been looking at jakarta cactus and I think it has promise for the purpose. Could you point me to some resource on the internet that would give me some detailed examples of the best way to unit test Maverick controllers? Preferably examples that use Cactus? --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER] --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER] --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER] --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER]
Re: [Mav-user] Re: Unit Testing Maverick
Jeff, why wouldn't you consider using JUnitEE for this? Ed. - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Holt, Jack C. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 5:20 AM Subject: [Mav-user] Re: Unit Testing Maverick I don't know of anything - anyone else? On Fri, Nov 01, 2002 at 11:19:45AM -0800, Holt, Jack C. wrote: I'm a fan of Maverick. It seems to implement MVC without the high levels of abstraction with approaches such as Struts. I'm currently trying figure out how to unit test the maverick controllers (classes that implement Controller) which I've written. I've been looking at jakarta cactus and I think it has promise for the purpose. Could you point me to some resource on the internet that would give me some detailed examples of the best way to unit test Maverick controllers? Preferably examples that use Cactus? --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER] --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en [INVALID FOOTER]
Re: [Mav-user] Maverick to Struts
I suppose I should have been more explicit in my previous email, which was posted in part to help me let off some steam. :-o I'm aiming at reusing the View mechanism and the controllers (with a few modifications to overcome the singleton nature of Struts). The general idea is to have the Struts actions forwarding to Maverick style views to provide the transforms etc. I've been working on an implementation that works with a servlet 2.1 API and jdk1.1.x (It's currently running in VisualAge 3.02 (urghh)). I'm using the TrivialView and Transforms along with a DispatchedView. The configuration is hard-coded rather than driven from a configuration file. I've ported the Jakarta Commons packages to the 1.1.x platform. The eventual platform will be WebSphere 4.0, so there'll be a few changes when that happens. One good thing from my point of view though, is that although the use Struts has been mandated on this project, its use is mainly as a dispatch mechanism. Use of the Struts tag libraries has been discouraged, so a Maverick style view mechanism will be really cool and will hopefully be good publicity for Maverick on other projects which will hopefully be able to make use of the view mechanism. Ed. - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Ed Ward [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 23, 2002 1:36 AM Subject: RE: [Mav-user] Maverick to Struts The question is, which part? I can identify three discrete pieces of an MVC framework which could conceivably be mixed and matched: 1) The controller/action part, including bean population, form validation, etc. 2) The view part, including jsp taglibs and (for Maverick) transformation, etc. 3) The core, which basically covers everything else. In particular, it includes the Dispatcher/ActionServlet, the configuration file, and how the components are put together. Which parts of Maverick do you want to work with which parts of Struts? A lot of interoperability with Struts is possible if you use the Maverick core. It is even possible (although I haven't tried it yet) to use Struts Actions and Struts views (with their own JSP taglibs), getting transforms, shunting, and the flexible config file from Maverick. This would require building fairly simple implementations of the ControllerSingleton base class and ViewFactory. Struts however is not very modular, so if you need to use the Struts core (including their ActionServlet), I don't know what you can do. You're going to have a rough time with XSLT, too, because it'll be very difficult to get more than a single transform configured. Jeff Schnitzer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: Ed Ward Sent: Sat 4/20/2002 9:31 AM To: [EMAIL PROTECTED] Cc: Subject: [Mav-user] Maverick to Struts Hi, Hold on to your hats whilst I ask what might sound a really dumb question. How easy is it to wrap a Maverick application with Struts? The reason I ask... The client I'm working for recently made an announcement that all their future webapps will be developed with Struts :-(( I did what I could to make them see the error of their ways, but AFAIK they haven't even taken a brief look at Maverick and the lead architect hadn't even put a working Struts app together when the decision was communicated! I don't have much knowledge of Struts myself, hence the question. Suffice it to say I'd still like to rework our UI using Maverick and XSLT, but now I have to consider the implications of my client's Struts requirements. The presentation layer of the app I'm working on requires extensive rework to enable it to use either Maverick or Struts, but I've already started rewriting with Maverick in mind. Any advice as to how I can keep the client's Struts fans happy and not lose my changes based on the use of Maverick? My guess is that it's going to be easier port a Struts application to Maverick than the other way around. Ed. ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
