Re: [OS-webwork] Spring integration using ObjectFactory
Ross Mason wrote: I like the look of that Simon. This works well when your whole app is configured using the Spring Container (such as ours is) Glad that you liked it. I've got an almost complete SpringObjectFactory written; I've just got to find the time to add support for obtaining validators using it, and then I'll release it. One of the side effects of writing this has been to change the various configuration classes (such as ActionConfig and InterceptorConfig) from handling the classes themselves to contain a reference to the name of the class. I've added some caching to the DefaultObjectFactory to try and avoid having to repeatedly call "Class.forName()" There is still a need for the external reference resolver stuff as it does (potentially) enable actions to pull references from different sources. Indeed. Regards, Simon --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Spring integration using ObjectFactory
Jason Carreira wrote: I think the idea is that in the class=".." field in xwork.xml you actually just put your Spring bean name to reference. The rest of the xwork.xml file would be the same. Spot on. Frankly the thought of trying to wire _everything_ up in Spring makes me shudder because the config would be enormously verbose and hard to follow. The current format used for the xwork.xml file is far easier for someone to follow and understand what's happening, IMO. Of course, if all you want to do is have Spring set various properties on your Actions the alternative is to use an external entity resolver. It depends on what you're most comfortable with. Regards, Simon --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Spring integration using ObjectFactory
Francisco Hernandez wrote: so if you define your actions in spring how would you go about defining the results and interceptor stacks for those actions? You still use an "xwork.xml" file to define the actions' validators and results, but rather than using a real class name in the action's "class" attribute, put a spring bean id or name. In your spring application context simply create a prototype bean with the expected id or name. For example, a really simple "xwork.xml" might look like this (DTD elided): userInfo.jsp and in your "applicationContext.xml" file: osuser-memory.xml When XWork asks asks for the "getUserInfo" action, Spring will do it's normal magic of wiring up any listed properties, and then the SpringObjectFactory passes that to XWork to use as a normal action. All that's changing is how the bean is obtained. Two points: *) Notice that in the Spring context, the bean is configured as a prototype. This is a necessity because of the way that XWork expects a new Action for each request. *) The SpringObjectFactory falls back to the normal XWork behaviour when it can't find the given bean name in the spring context. This means that it's possible to create some beans using Spring and others using XWork's current behaviour, giving you a bit of flexibility. If there's interest, I'll put together the other methods in SpringObjectFactory and also add a little caching so that "Class.forName()" is not executed every time the default object factory is used. Regards, Simon --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Spring integration using ObjectFactory
I've just uploaded a simple implementation of the ObjectFactory to JIRA that offers support for using Spring to create (and therefore wire) Actions in XWork. In order to make this approach work, it was necessary to change the ActionConfig class so that a reference to the Action's class name was stored rather than the class itself. The patch includes a couple of unit tests that show the thing in action. All the other tests also run, at least on my machine, so I'm reasonably confident that this works as advertised. Because I'm obviously having a bad day today, I initially created an entry for this in the Webwork JIRA installation, but there's now a slightly more appropriate XWork issue too. I'd appreciate it if one of the JIRA admins would close the Webwork issue. http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-168 Regards, Simon --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XMLRPC dispatcher and view
remigijus wrote: Does it supports different encoders. Few monts ago I had to write my own XMLRPC library, only because no one had support for character encoding. ATM everything is hard-coded, but there's no reason why you can't implement the ObjectAdapter and Parser interfaces and use your own implementations instead because the only dependencies are on those interfaces. There would need to be changes made to: XmlRpcDispatcher.init() XmlRpcOutputter.renderResult() in order to look up the class names from the webwork config, but that's all that should need to be done. Regards, Simon --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] XMLRPC dispatcher and view
I've put together an XMLRPC dispatcher and view for Webwork 2, and thought that maybe some of you would like to know that it's available, and how it works. Read on if you're interested http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-467 It's composed of several parts, but the key ones are the XmlRpcDispatcher, which can be used in place of the normal ServletDispatcher and the XmlRpcDispatcherResult, which maps results to an XMLRPC "methodResponse" and a PositionalParameterInterceptor. The PositionalParameterInterceptor (other than having a snappy name) takes the parameters of an XMLRPC method call and maps them from their positions to a set of space separated OGNL paths, using the static Action parameter "XmlRpcPaths": username password result In this case, the first parameter is mapped to "username", and the second to "password". More examples are included in the attached "xwork.xml" file. Assuming that the XmlRpcDispatcherResult is being used, the "location" parameter of the results is again an OGNL path, which is adapted to an XMLRPC "methodResponse" by the DefaultObjectAdapter. There are some more examples of how to use the XmlRpc classes included in the "src/test" directory of the archives attached to the JIRA issue. The only other thing to note is that the dispatcher uses the name of the method to try and determine the package; a call to "blogger.getUserInfo" would look for an action named "getUserInfo" in the package called "blogger" So, what are the disadvantages and advantages of using this dispatcher rather than (say) Apache's XMLRPC code? *) It integrates nicely with Webwork, meaning that you don't need to learn another API *) This XMLRPC code doesn't contain any extra dependencies, which means fewer jars are needed in your application *) This XMLRPC code is missing certain features, specifically support for Base64 encoded parameters. *) The Apache code has been better tested. For instance, the Date code in the "SpecBasedParser" definitely needs some more hostile testing. *) It's a nice "proof of concept" for XWork/Webwork since very little additional work needed to be done once the XMLRPC adapter and parser had been written. Shout if you have questions! Regards, Simon http://www.opensymphony.com/xwork/xwork-1.0.dtd";> username password result
Re: [OS-webwork] Action Properties & HttpSession
On Friday, Feb 7, 2003, at 08:49 Europe/London, Rickard Öberg wrote: hm.. IIRC model() is also a property (both "getModel" and "model" is tested if the "model" property is accessed. *If* I recall correctly we might as well use getModel(), since it looks cleaner. exposeModel() perhaps? Or fetchModel()? Regards, Simon --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork flux
On Thursday, Jan 30, 2003, at 14:30 Europe/London, Rickard Öberg wrote: Joseph Ottinger wrote: Can we PLEASE get back to useful discussion? I'm interested in seeing if XWork is usable, and how much in flux it's considered to be. Alright, I'd estimate that the fluxness of XWork is about 70%. Rickard, just a thought, but how much of the code in XWork is derived form (or at least, similar in principle to) your own AOP framework? I get the feeling that there could be a significant amount of overlap between the two in terms of configuration, interceptors, etc. Which doesn't mean a whole lot I guess. Wait and see. Okay :) Regards, Simon --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] OpenSymphony build process
On Tuesday, Dec 17, 2002, at 16:23 Europe/London, Hani Suleiman wrote: I am vehemently opposed to build.bat and build.sh. All you need is ant. I'm likewise against checking in ant to every single project. It's a fairly reasonable assumption that people who might need to build a project have ant installed (you don't bundle gnu make with every project that has a Makefile). It's a reasonable assumption that people have ant installed, but not that they'll have all the optional jars, such as those needed to use the "style" ant task (or the "junit" task, for that matter) And don't even think about those poor souls stuck somewhere where they can't upgrade their ant installation for whatever reason. Assuming that they're willing to download an OpenSymhony project, complete with supporting jars, the extra couple of meg to cope with ant is a small penalty. You're right, you don't bundle make with every project. It doesn't do dependencies in the same way as ant does. Likewise, I'm against forcing a particular coding style. the coverage reports and suchlike are just eye candy really, so I'm ambivalent there. As long as each project has a consistent coding style, whatever the developers feel happy with is fine. Also, I'm not sure there is much point in adding code coverage results or test cases to a distribution. Those are aimed at end users, and huge downloads full of mostly useless cruft do not encourage warm fuzzy happy feelings towards fellow man/developer. Test cases are vital, if only to act as a quick check that the download does "what it says on the tin" Not so fussed with code coverage results, though I suppose that's an extra confidence boost. If you're worried about download size, only include them in a "src" download. Regards, Simon --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Documentation
On Tuesday, Dec 10, 2002, at 16:32 Europe/London, Ken Egervari [eXtremePHP] wrote: XSLT will also help us out if the website presentation layer changes or when we decide to compile the manual into a PDF document (which I really hope we do since PDF is a fantastic format for printing and offline viewing). XML will critical to achieve this. Maybe I'm just a little bit confused, but won't both the XML and the HTML crowd be happy with XHTML? Seems like a Really Obvious Solution. Fine, you can't use the Docbook tools that come with lots of linux distros, but that's just a minor implementation detail --- I bet that there are loads of people champing at the bit for a tool to convert their websites to PDF :) Regards, Simon --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Improved property tag....
On Monday, Nov 11, 2002, at 11:29 Europe/London, Joseph Ottinger wrote: It's okay. Actually, you guys were right: why should we bother writing our own? Snipsnap is getting data and not underperforming, IMHO; all it needs is a port away from Jetty and you'd be off and running, with very little work involved. Writing a wiki for opensymphony would involve reinventing wheels, and time that nobody really wants to spend... and it'd need some maturing. Development time costs money and mindshare best spent elsewhere. Yes, but it would be fantastic to have a real world app that uses Open Symphony components in the way that their creators intended them to be used. That way, it's possible for newbies to get started a _lot_ faster, which helps the mindshare of the project as a whole. The Roller project is a good example of a project that introduces a newbie to various tools, and how they fit together. Webwork's great, and I'm sure that OSWorkFlow is also the bee's knees. OSUser and OSAccess can probably solve a heap of problems (some of the perennial "how do I secure my WW app?" questions, perhaps) The missing piece of the puzzle is a show case app which demonstrates how it all fits together. Regards, Simon --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Unit testing Actions
On Thursday, Nov 7, 2002, at 23:09 Europe/London, Patrick Lightbody wrote: I'm still very happy with my test code that does use the WW framework. I haven't seen any performance problems (entire suite runs under 1s) but I suppose my machine might have a little more oomph than yours. Though even on my old PIII 600Mhz laptop the suite runs in 4seconds max. :) I like to treat my testing of code as purely a blackbox, to the point where i don't even create the actual object. So I guess in a way I'm not testing each method of my code, but each instance (alias) in views.properties (I too actually use a test_views.properties for unit tests). Here's what a typical test looks like for me: How do you simulate unusual conditions in your tests (perhaps an Exception that part of your app throws under certain circumstances)? I'd think of mocks as the way to do this, but you probably have some other way of generating these sort of situations. Obviously, once I'm sure that the individual methods work as expected, it's good to run through a series of tests using the whole framework, but that seems to lack precision. Or am I missing something? Regards, Simon --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Unit testing Actions
On Thursday, Nov 7, 2002, at 23:00 Europe/London, Mike Cannon-Brookes
wrote:
Simon,
You can test your actions without going through the whole framework.
Something like:
ActionContext.setSession(session);
MyAction act = new MyAction();
act.setFoo("bar");
act.execute();
Should work fine?
That's precisely what I do at the moment, because it can be done out of
the container and runs quickly. It also means that I can replace
supporting classes with Mocks, so that I can make sure that things are
working as I expect them to when something unexpected happens. For
example, right now, it's very easy to simulate duplicate users in my
app by simply setting up the mocks correctly:
public void testCreateUserCommandWithDuplicateUser() {
action.setCommand( "create" );
action.setUsername( "sms" );
edit.setupGetUsername( "sms" );
factory.setupExceptionCreateUser( new DuplicateUserException()
);
String result = action.doCreate();
assertEquals( Action.ERROR, result );
}
lifted almost directly from my current tests. "action" is the Action
being tested, and "edit" and "factory" are both mocks ("factory"
returns the "edit" mock, which is configured in setUp())
I've not seen much testing code before, especially for webwork
projects, so it would be handy to learn how the people most familiar
and experienced with the framework do this sort of thing.
Regards,
Simon
---
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
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Unit testing Actions
I'm curious to know how other people on the list unit test their Actions. Patrick, at least, uses his custom AbstractActionTest to run the tests (ultimately) via the GenericDispatcher. Others, such as Joe (according to his blog) prefer to treat their Actions as normal classes, with methods that need to be tested after being setup in a certain way. I can see the attractions of both ways: following one route, you can rely on the framework being used in precisely the same way as it will during deployment. The other way requires a certain amount of knowledge of how the Action will be called, but allows one to pass in state and supporting classes more easily (for example, Mocks to stub out database access) After having a play with both, I'm tempted to fall to the side of testing each of the methods in turn. This is partly because testing within webwork slows my tests enough to be irksome on my relatively humble machine, and partly because I want to test that each method works as it should --- I can manipulate the tests (eg. causing an IOException, or throwing a database exception) a lot more easily by passing in state and running the method being tested directly than I can by going through the entire framework. If I well off track here, then it'd be nice to get some pointers from the experts Regards, Simon --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
On Wednesday, Nov 6, 2002, at 10:36 Europe/London, Rickard Öberg wrote: Simon Stewart wrote: On Wednesday, Nov 6, 2002, at 09:51 Europe/London, Rickard Öberg wrote: > The issue about actions.xml is verbosity, not being able to figure out > how to create it. Having a DTD doesn't change a thing in this regard. XDoclet, perhaps? Sure, I mean, I use XDoclet to generate it, so for me it doesn't really matter much. But for those who do it by hand, it will be a big difference. It's about "scalability", and in this case scaling down to simpler projects. If it's scaling _down_ you're worried about, surely making as many elements and attributes as possible optional is the Right Way? The actions.xml that's part of the source covers enough ground to allow a newbie to get started (from experience :) and seems to cover most of the obvious things that a user would like to do. An alternative: if each Action has a small config file specifying its views associated with it (in the same style as Hibernate), and this is documented in the javadocs for the Action and ActionSupport classes, then the problem of "not being able to create it" is trivialised. Regards, Simon --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: Configuration (was RE: [OS-webwork] Webwork Security Requirements)
On Wednesday, Nov 6, 2002, at 09:51 Europe/London, Rickard Öberg wrote: The issue about actions.xml is verbosity, not being able to figure out how to create it. Having a DTD doesn't change a thing in this regard. XDoclet, perhaps? /Rickard, who still uses views.properties :) Regards, Simon --- 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 ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Two classes to ease development
On Monday, Oct 28, 2002, at 17:40 Europe/London, Patrick Lightbody wrote: Yup, GenericDispatcher was specifically designed for this situation (well, and others). I'll have a proper look at this tonight, but it seems that the only way that I can currently get data into an Action is using "params" that is used to set the parameters. How do I deal with the case where I store some data in the Session? At a quick glance through the code, it only deals with actions that are/were ParameterAware (if you see what I mean) Time to extend the AbstractActionTest with all the bits that are "missing" :) Although this feels a bit "heavier" than the solution offered by XAwareActionFactoryProxy, I'll try writing tests using both methods and see which I prefer. It's probably just a case of Not Invented Here *shrugs* The only other thing that comes to mind is that by implementing *Aware interfaces an Action makes obvious and explicit what it's expecting, and where, which might be handy if anyone else but myself has to look at this code (esp. given my commenting habits) I'll have a scan of the archives for why they've been deprecated. Regards, Simon --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Two classes to ease development
On Monday, Oct 28, 2002, at 16:19 Europe/London, Patrick Lightbody
wrote:
I like the StackableActionFactory, I'll make sure it gets in to XWork
at
least.
Thanks.
But what is the XAwareActionFactoryProxy exactly for? I do tons of unit
testing with my actions (using GenericDispatcher as a launching place)
and
I've not needed something like this.
The need for something like this arose from a conversation I was having
about how to unit test webwork actions without needing to fire up a
complete app server --- a process that takes an age on my machine, and
therefore acts a significant deterrent to doing "proper" TDD.
The suggested solution was to make use of Mock Objects, which can be
passed into the Action at test time. So you end up with a chunk of code
that looks a little like:
public void testNoUsernamePassedIntoClass() {
MockUser user = new MockUser();
user.setExpectedSetUsernameCalls( 0 );
UserEditAction action = new UserEditAction();
action.setUser( user );// Action is UserAware
action.setNewUsername( null ); // User name has not been filled
in
String result = action.execute();
assertEquals( Action.SUCCESS, result );
user.verify();
}
Obviously, the User class has to be tested elsewhere, but that's
another problem entirely. Using a style like this, I can run a whole
test suite in seconds, without having to deploy the app once or go
through the shenanigans of having a properly configured installation of
WW[1].
The question remains, however, as to how to get WW to pass in the
state. As hinted in the snippet of code, one way would be to create an
interface such as UserAware:
public interface UserAware {
void setUser( User aUser );
}
And a matching factory to go with it:
public class UserAwareFactoryProxy {
public static void setUser( Action anAction ) {
ActionContext context = ActionContext.getContext();
User user = (User)context.getSession().get("currentUser");
((UserAware)action).setUser( user );
}
}
It would be possible to simply append "User" to the list of factories
that StackableActionFactory gets to use, but this can become
inefficient --- not every Action is UserAware --- and doesn't allow one
to be properly Lazy[2] Instead, the developer has only to state in
webwork.properties what packages to search through, and
action.setUser() will be called automagically by
XAwareActionFactoryProxy if (and only if) the action happens to be
UserAware, without requiring a potentially enormous custom action
factory class, and with only a tiny amount of overhead once the first
invocation is done.
I know that I'm not the only one who thinks like this. Just today,
Darran Hobbs posted:
"I suppose I prefer the passive bean like approach where state is
passed in
from outside, leaving my implementations unaware of anything other than
their own state and the interfaces they implement. Its a personal
style thing I guess. I've been IOC indoctrinated :)"
If I can do the same "out of container" testing using the
GenericDispatcher, I would happily do that, especially if it was as
fast as the method described above, though I am unsure how to set
things up. Do you have any examples that I could see?
Also, the *Aware interfaces have been deprecated.
I had noticed the warnings when I compiled webwork from source. What's
the preferred idiom for passing data into an Action now?
Regards,
Simon
[1] Obviously, the acceptance tests ensure that WW is configured
properly when the app is deployed.
[2] In the Perl-ish sense :)
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
