webwork-devel Mailing List for WebWork
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel — WebWork development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(316) |
Dec
(117) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(197) |
Feb
(229) |
Mar
(293) |
Apr
(177) |
May
(84) |
Jun
(40) |
Jul
(43) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-23 08:57:58
|
Hey guys, Just to let you know we migrated all the data from the WW JIRA to the OpenSymphony JIRA today. If you had an account and did something, it still exists (but you will need to reset your password). If you didn't do anything, you'll need to sign up again. You can now access all the webwork issues at http://jira.opensymphony.com Also I updated the OS JIRA to 1.3.3 today, which means a while lot of nice little UI improvements, and an XML (RSS) issue view (which is very funky!). For example if you want to view (or subscribe in your favourite RSS aggregator) a feed of the latest OpenSymphony issues raised, try this URL: http://jira.opensymphony.com/IssueNavigator.jspa?createdPrevious=604800000&t empMax=15&view=rss&reset=true (you can of course filter this by a particular project or whatever you want) Enjoy. Mike PS email me if you notice anything strange - it all looks to be operating fine to me! |
|
From: Peter K. <pe...@mo...> - 2002-07-18 07:59:13
|
This is a forwarded message From: Peter Kelley <pe...@mo...> To: ope...@li... Date: Thursday, July 18, 2002, 3:33:28 PM Subject: [OS-webwork] Jasper Reports Just realised that not everyone will be on the new list yet. ===8<==============Original message text=============== I have just committed some updates to the Jasper Reports support. Since this is my very first commit I would appreciate any feedback. In this update: - Subreport support to support nested iterators along with updated examples. Note that the way that I have implemented subreports is to have the ValueStackDataSource return another ValueStackDataSource if the field you specify via expression language turns out to be iterable (List, array, Enumeration etc). If you actually want the value of one of these objects in your report you will have to create another property that returns the toString of the property. Barring changes to Jasper Reports itself (like adding a new method on JRDataSource) this was the cleanest way to do this even though it was a kludge. Still to do: - Add support for compiling the reports in the build - Add support for passing the webwork parameters to Jasper Try this out and let me know if you like it. -- regards, Peter Kelley MoveIt Pty Ltd You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away. - Antoine-Marie-Roger de Saint-Exupery ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ===8<===========End of original message text=========== -- regards, Peter Kelley MoveIt Pty Ltd mailto:pe...@mo... +61-2-9986-3510 Transport of the mails, transport of the human voice, transport of flickering pictures - in this century, as in others, our highest accomplishments still have the single aim of bringing men together. - Antoine-Marie-Roger de Saint-Exupery |
|
From: Matt B. <ma...@sm...> - 2002-07-18 00:41:19
|
os-ww list for all WW related stuff ----- Original Message ----- From: "Toby Hede" <tob...@in...> To: <web...@li...>; <web...@li...> Sent: Wednesday, July 17, 2002 7:26 PM Subject: [Webwork-devel] Re: [Webwork-user] WW integration > Is there no separate ww development list? Is there a large volume of > development mail on the os-developer list? Or should ww development just go > to the os-ww list? > > > > > WW is now integrated with Open Symphony. Please take a > > moment to sign up for the appropriate mailing list (see > > below). I'm currently in the process of migrating our > > documentation to HTML. I hope to have this done by > > week's end. I'm only trying to duplicate what we have > > with a few revisions. Later, we can take a look at > > inadequecies. > > > > All webwork related questions should be sent here: > > ope...@li... > > > > Developers should also sign up for: > > ope...@li... > > > > -Matt > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Webwork-user mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webwork-user > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > |
|
From: Toby H. <tob...@in...> - 2002-07-18 00:26:06
|
Is there no separate ww development list? Is there a large volume of development mail on the os-developer list? Or should ww development just go to the os-ww list? > WW is now integrated with Open Symphony. Please take a > moment to sign up for the appropriate mailing list (see > below). I'm currently in the process of migrating our > documentation to HTML. I hope to have this done by > week's end. I'm only trying to duplicate what we have > with a few revisions. Later, we can take a look at > inadequecies. > > All webwork related questions should be sent here: > ope...@li... > > Developers should also sign up for: > ope...@li... > > -Matt > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user |
|
From: Bill B. <bi...@pr...> - 2002-07-17 22:00:48
|
Hello, Matt Baldree wrote: > > ----- Original Message ----- > From: "Mike Cannon-Brookes" <mi...@at...> > To: <ma...@sm...>; <web...@li...>; > "opensymphony-developers" <ope...@li...> > Sent: Tuesday, July 16, 2002 7:51 PM > Subject: Re: [Opensymphony-developers] WW integration > > > 3. Is the plan to move WW docs away from using DocBook to plain HTML? > > yes, it is in the works. So, no more XML to HTML transformation of any kind? Care to provide any details? -Bill |
|
From: <ma...@sm...> - 2002-07-17 18:54:59
|
Also, if you are interested in CVS updates, you will need to sign up for that mailing list as well as the others. On Wed, 17 July 2002, ma...@sm... wrote > > WW is now integrated with Open Symphony. Please take a > moment to sign up for the appropriate mailing list (see > below). I'm currently in the process of migrating our > documentation to HTML. I hope to have this done by > week's end. I'm only trying to duplicate what we have > with a few revisions. Later, we can take a look at > inadequecies. > > All webwork related questions should be sent here: > ope...@li... > > Developers should also sign up for: > ope...@li... > > -Matt > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user |
|
From: <ma...@sm...> - 2002-07-17 18:37:40
|
WW is now integrated with Open Symphony. Please take a moment to sign up for the appropriate mailing list (see below). I'm currently in the process of migrating our documentation to HTML. I hope to have this done by week's end. I'm only trying to duplicate what we have with a few revisions. Later, we can take a look at inadequecies. All webwork related questions should be sent here: ope...@li... Developers should also sign up for: ope...@li... -Matt |
|
From: Philipp M. <me...@me...> - 2002-07-17 10:23:58
|
On Wed, Jul 17, 2002 at 08:37:10AM +0200, Rickard wrote: > Matt Baldree wrote: > >Well, I would say that you shouldn't release until documentation is brou= ght > >up to date. The current CVS will have work-in-progress code that may not= be > >documented until released. But, hopefully moving docs to HTML will allow > >easier input. >=20 > Document before release is all we need. I want to add: unit test before release is what we need, too. At least for the central parts of ww (actionstack, servlet dispatcher) and for every new code. -billy. --=20 Meisterbohne S=F6flinger Stra=DFe 100 Tel: +49-731-399 499-0 eL=F6sungen 89077 Ulm Fax: +49-731-399 499-9 |
|
From: Rickard <ri...@dr...> - 2002-07-17 06:40:20
|
Matt Baldree wrote: > Well, I would say that you shouldn't release until documentation is bro= ught > up to date. The current CVS will have work-in-progress code that may no= t be > documented until released. But, hopefully moving docs to HTML will allo= w > easier input. I agree. Francois' suggestion is not good, since we need to "try out"=20 features in CVS before saying that they stay. Features that have been=20 added have a tendency to change between initial import to CVS and a=20 release, which is good. Document before release is all we need. /Rickard --=20 Rickard =D6berg |
|
From: Peter K. <pe...@mo...> - 2002-07-17 01:30:30
|
Just an update on how the Jasper Reports stuff is coming: It proved easier and better architecturally to implement nested iterators as sub reports in jasper. This now better maps to the iterator structure that is used in the JSP pages. I have a skeleton implementation working and Maurice is looking at it before committing to CVS. I am now looking at the compilation and caching of report definitions and I have a question: Would it be a big pain if you had to compile your reports beforehand rather than having the servlet do it for you ? The reason I ask is that it will be a real pain figuring out which sub reports to compile for a given master report and the compilation takes a long time anyway. On top of this the report compiler doesn't use a custom classloader and so you need the jasper reports jar files in the system classpath of your application server. Will the loss of dynamic report compilation seriously inconvenience anyone ? Monday, July 15, 2002, 2:28:55 PM, Maurice Parker wrote: MP> Peter, MP> Let's move this back to webwork-dev since we're beginning to discuss the MP> implementation. I've left the full history tacked on so others can catch MP> up. MP> On Sunday, July 14, 2002, at 10:27 PM, Peter Kelley wrote: >> Maurice, >> >> I have official sanction to work on this as part of my day job and >> contribute back to WW (we use a lot of open source here) so I should >> be able to make some good progress over the next few days. MP> We should all have such jobs. :-) >> What were you thinking of in terms of getting values from actions for >> the report ? One idea I had was to use the expression language in the >> field name. The other idea I'm toying around with is how to do the >> equivalent of JSP webwork:iterator tags, either sub reports or by >> writing some smarts in the data source to denormalise the structure >> automatically. By the latter I mean that the structure: >> >> foo >> bar1 >> foobar1 >> foobar2 >> bar2 >> foobar3 >> foobar4 >> foobar5 >> bar3 >> foobar6 >> foobar7 >> >> would come out looking something like this to the iterator: >> >> foo bar1 foobar1 >> foo bar1 foobar2 >> foo bar2 foobar3 >> foo bar2 foobar4 >> foo bar2 foobar5 >> foo bar3 foobar6 >> foo bar3 foobar7 >> >> This of course leaves the question how would you decide which >> properties to iterate over and how many levels down to go. >> >> What do you think ? MP> It's interesting. I'll think more about it tomorrow. >> I might have a go at putting some code together this afternoon (I'm in >> Australia by the way) and see what I come up with for a data source. >> Iterators may take a little longer. MP> Take a look at what I just put into CVS and see what you think. It's MP> rough still, but at least you can see where my thought process is heading. MP> One thing that will be a high priority soon will be caching the compiled MP> JasperReports for performance reasons. (or we force people to precompile MP> before deploying which isn't convenient). MP> It's late here and I'm going out for a night cap. Have fun at work. If I MP> code while you sleep and you code while I sleep this will get done in no MP> time. MP> -Maurice MP> P.S. Mike, I'll take the beer instead of that man-love you offered me. : MP> -) >> >> Monday, July 15, 2002, 12:50:13 PM, you wrote: >> >> MP> Peter, >> >> MP> My day job has kept me very busy, but I started doing some Jasper/WW >> MP> integration yesterday. I have a servlet that generates an empty PDF >> as a >> MP> view from Jasper right now and am in the process of creating a Jasper >> MP> datasource that uses the WW value stack. >> >> MP> I hope to do an initial commit sometime tomorrow. That will give us >> a >> MP> base to work from if you're interested in working together on it. >> >> MP> BTW, we used Jasper on my current project by putting the Jasper code >> in WW >> MP> Actions and wrote the result out using a custom servlet as a view. It >> MP> works well and the customer is very happy with the result. The fully >> MP> integrated version I'm working on should be much easier to use and >> more >> MP> powerful. >> >> MP> I love your sig line. My personal favorite is: >> >> MP> A designer knows he has arrived at perfection not when there is >> nothing >> MP> more to add, but when there is no longer anything to take away. >> MP> -Antoine de Saint-Exupery >> >> >> MP> -Maurice >> >> >> MP> On Sunday, July 14, 2002, at 08:01 PM, Peter Kelley wrote: >> >>>> Maurice, >>>> >>>> I notice that there is an issue assigned to you to integrate WebWork >>>> with JasperReports. I was wondering how far you had progressed in >>>> doing this and whether you could use some help ? We have a need to do >>>> this for our current project and so I have some time available to get >>>> this going. >>>> >>>> -- >>>> >>>> regards, >>>> Peter Kelley >>>> >>>> MoveIt Pty Ltd >>>> mailto:pe...@mo... >>>> +61-2-9986-3510 >>>> >>>> "If you want to build a ship, don't drum up the men to >>>> gather wood, divide the work and give orders. Instead, >>>> teach them to yearn for the vast and endless sea." >>>> - Saint-Exupery >>>> >>>> >> >> >> -- >> >> regards, >> Peter Kelley >> >> MoveIt Pty Ltd >> mailto:pe...@mo... >> +61-2-9986-3510 >> >> "If you want to build a ship, don't drum up the men to >> gather wood, divide the work and give orders. Instead, >> teach them to yearn for the vast and endless sea." >> - Saint-Exupery >> >> -- regards, Peter Kelley MoveIt Pty Ltd You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away. - Antoine-Marie-Roger de Saint-Exupery |
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-17 01:29:53
|
>> 3. Is the plan to move WW docs away from using DocBook to plain HTML? > > yes, it is in the works. Great! >> 5. Let me know the SF names of who you want added! >> > > jhaynie - VXML owner > rickardoberg > mauricevineyard > llucifer - XSLT owner Done - welcome all! >> 6. Right - opensymphony-webwork sound ok? >> > > sounds fine. Done - should be live in 6-24 hours. Cheers, Mike |
|
From: Matt B. <ma...@sm...> - 2002-07-17 01:04:07
|
Well, I would say that you shouldn't release until documentation is brought up to date. The current CVS will have work-in-progress code that may not be documented until released. But, hopefully moving docs to HTML will allow easier input. -Matt ----- Original Message ----- From: "Francois Beauregard" <fbe...@py...> To: <web...@li...> Sent: Tuesday, July 16, 2002 7:53 PM Subject: [Webwork-devel] Suggestion > Since I have not been directly involved in the development of WebWork, I may > not be entitiled for the following suggestion but I will make it anyway. > > It has been identified that there is some room for improvement in WebWork's > documentation. Lately, there has been some new features introduced which is > very good but documentation ... > > To prevent the situation related to documentation to worsen, I suggest the > following rule : > No feature can be commited in the cvs repository unless it has been > documented. > > Cheers, > ___________________________ > François Beauregard, b.ing. > Vice-président > Recherche et développement > Pyxis Technologies > www.pyxis-tech.com > > T : (450) 681-9094, poste 102 > F : (450) 681-5758 > fbe...@py... > > |
|
From: Matt B. <ma...@sm...> - 2002-07-17 01:00:21
|
----- Original Message ----- From: "Mike Cannon-Brookes" <mi...@at...> To: <ma...@sm...>; <web...@li...>; "opensymphony-developers" <ope...@li...> Sent: Tuesday, July 16, 2002 7:51 PM Subject: Re: [Opensymphony-developers] WW integration > Matt, > > That looks fantastic - I just checked the website and the doco frontpage is > up - looks good. > > I'll migrate the WW JIRA data across this week too - I have to work out how > to do it :) > > 3. Is the plan to move WW docs away from using DocBook to plain HTML? yes, it is in the works. > > 4. Agree with JoeO here - ask SF to do the migration so we keep change > history. > done, they are on it. > 5. Let me know the SF names of who you want added! > jhaynie - VXML owner rickardoberg mauricevineyard llucifer - XSLT owner [If I missed anybody who thinks they should be added, please *yell*.] > 6. Right - opensymphony-webwork sound ok? > sounds fine. > 7. Can we shut down a SF site? :) > maybe > Cheers, > Mike > > PS I'm also investigating setting up MovableType (www.movabletype.org) as a > news system for OS and for any developer who wants a blog > (blogs.opensymphony.com?). That way each different module can have > independent news on their module pages, and also the frontpage can have an > aggregate of news. This would make the website more dynamic. Will let you > know about progress. > > On 17/7/02 4:54 AM, "ma...@sm..." (ma...@sm...) penned the > words: > > > I'm starting the migration of WW to OS. This is a work > > in progress but here are my tasks. I hope to have these > > tasks completed by week's end. > > > > 1. Updating OS site to include WW. > > 2. Migrating WW docs to HTML. > > 3. Update OS website to build WW docs. > > 4. Import WW code into OS. (I will announce this to the > > WW developer list before I do this.) > > 5. Add WW core developers to OS. > > 6. Add WW mailing list to OS. > > 7. Announce migration and shut down WW SF site. This > > means appropriate modules will be turned off and > > project description will direct users to OS. > > > > -Matt > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Jabber - The world's fastest growing > > real-time communications platform! Don't just IM. Build it in! > > http://www.jabber.com/osdn/xim > > _______________________________________________ > > Opensymphony-developers mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers > > > |
|
From: Francois B. <fbe...@py...> - 2002-07-17 00:53:33
|
Since I have not been directly involved in the development of WebWork, I may not be entitiled for the following suggestion but I will make it anyway. It has been identified that there is some room for improvement in WebWork's documentation. Lately, there has been some new features introduced which is very good but documentation ... To prevent the situation related to documentation to worsen, I suggest the following rule : No feature can be commited in the cvs repository unless it has been documented. Cheers, ___________________________ François Beauregard, b.ing. Vice-président Recherche et développement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 fbe...@py... |
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-17 00:51:23
|
Matt, That looks fantastic - I just checked the website and the doco frontpage is up - looks good. I'll migrate the WW JIRA data across this week too - I have to work out how to do it :) 3. Is the plan to move WW docs away from using DocBook to plain HTML? 4. Agree with JoeO here - ask SF to do the migration so we keep change history. 5. Let me know the SF names of who you want added! 6. Right - opensymphony-webwork sound ok? 7. Can we shut down a SF site? :) Cheers, Mike PS I'm also investigating setting up MovableType (www.movabletype.org) as a news system for OS and for any developer who wants a blog (blogs.opensymphony.com?). That way each different module can have independent news on their module pages, and also the frontpage can have an aggregate of news. This would make the website more dynamic. Will let you know about progress. On 17/7/02 4:54 AM, "ma...@sm..." (ma...@sm...) penned the words: > I'm starting the migration of WW to OS. This is a work > in progress but here are my tasks. I hope to have these > tasks completed by week's end. > > 1. Updating OS site to include WW. > 2. Migrating WW docs to HTML. > 3. Update OS website to build WW docs. > 4. Import WW code into OS. (I will announce this to the > WW developer list before I do this.) > 5. Add WW core developers to OS. > 6. Add WW mailing list to OS. > 7. Announce migration and shut down WW SF site. This > means appropriate modules will be turned off and > project description will direct users to OS. > > -Matt > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Opensymphony-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers |
|
From: <ma...@sm...> - 2002-07-16 19:01:54
|
I'm working on integrating WW with OS. We need to freeze all CVS updates until SF moves the WW module under OS. I'm about to open up a ticket and I'm not sure how long this will take so we need to go ahead and freeze development until it is moved. -Matt |
|
From: Joseph O. <jo...@en...> - 2002-07-16 18:56:56
|
We need to make sure to let SF support know to move the webwork modules across directly, when the time comes, so we don't lose version information. This is step 4; I figured we were already aware of the issues, but wanted to make sure. :) --------------------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant On Tue, 16 Jul 2002 ma...@sm... wrote: > I'm starting the migration of WW to OS. This is a work > in progress but here are my tasks. I hope to have these > tasks completed by week's end. > > 1. Updating OS site to include WW. > 2. Migrating WW docs to HTML. > 3. Update OS website to build WW docs. > 4. Import WW code into OS. (I will announce this to the > WW developer list before I do this.) > 5. Add WW core developers to OS. > 6. Add WW mailing list to OS. > 7. Announce migration and shut down WW SF site. This > means appropriate modules will be turned off and > project description will direct users to OS. > > -Matt > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Opensymphony-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers > |
|
From: <ma...@sm...> - 2002-07-16 18:54:26
|
I'm starting the migration of WW to OS. This is a work in progress but here are my tasks. I hope to have these tasks completed by week's end. 1. Updating OS site to include WW. 2. Migrating WW docs to HTML. 3. Update OS website to build WW docs. 4. Import WW code into OS. (I will announce this to the WW developer list before I do this.) 5. Add WW core developers to OS. 6. Add WW mailing list to OS. 7. Announce migration and shut down WW SF site. This means appropriate modules will be turned off and project description will direct users to OS. -Matt |
|
From: <ma...@sm...> - 2002-07-16 13:45:50
|
IMO, I think a simple solution like Mike's is best to start with. A solution that would allow users to use GLUE or Axis. We don't have to distribute either jar but just provide some documentation. It would be similar to the multipart solution. Users can use different multipart providers (COS or PEL or whatever). As far as EJB 2.1, I'm not convinced this is the way to go long term. If it is fine, but it would be nice to have an alternative to evaluate which is a better long term approach especially when SOAP moves beyond RPC. -Matt On Tue, 16 July 2002, Mike Cannon-Brookes wrote > > Toby, > > Thoughts below! > > On 11/7/02 12:13 PM, "Toby Hede" (tob...@in...) penned the > words: > > > This is more or less the approach I have been looking at. Rather than > > exposing Actions to SOAP messages directly, I think there is more value in > > simply looking at SOAP as another messaging system. > > Right - I think the biggest value in this exercise (for me) is abstracting > our webwork 'web' actions into more generic interfaces into our webwork > 'command' actions. WebWork is a very powerful command pattern framework that > should be able to be utilised anywhere IMHO. > > > A SOAPAware interface would indeed probably be required for completeness, > > but I think in the majority of cases, it would not used by developers. > > Right - I wouldn't use it. > > > This is the basic flow as I perceive it: > > > > Incoming SOAP Message: method and parameters > > This is a simple SOAP method call, eg: someCommand(param1, param2) > > Will defaulting to a Map of parameters that are associated with an Action > > require any extra work by other SOAP clients (like .Net, FlashMX and Perl)? > > I think that there is some benfit in allowing standard SOAP parameters to > > be passed by default. > > > > SoapDispatch: dispatches the method call to the processing action > > Incoming parameters mapped to the corresponding Action parameters and the > > Command is executed. > > > > One issue I see is that return values in WebWork will be limited, because > > of the Action API itself. Although, I imagine that Action parameters can be > > altered and returned. > > Right. At the moment with my WWSOAP integration project, I have a > SOAPDispatcher with a few methods: > > - String runAction(String actionName) > - String runAction(String actionName, Map parameters) > - Map runAction(String actionName, Map parameters, List resultsWanted) > > The first two run a specified action (the second with a map of parameters) > and then return it's result as a String. > > The last runs the action, but also returns a Map of results (of which the > String result is one entry with the key 'actionresult'). The result map is > created from the incoming results wanted. (eg if the resultsWanted list > contains "foo", the returned map will contain "foo" as a key, and > action.getFoo() as a value). > > This can then be plugged into _any_ webwork action! > > > We may need to create new Service mappings that allow an Action Command to > > be associated with a SOAP request. > > Right - possibly. At the moment I'm just using aliases in the actions.xml, > and then my SOAP client can request any action/command via its alias. This > is neat! > > > One note: GLUE is not Open Source, so I think there is value in continuing > > to look at Axis integration. > > Certainly - Glue is just the best SOAP framework available, and free - so we > use it. But I agree that it cannot be bundled with WebWork. However I'm > still not convinced that the proposed Axis integration is a good idea. > > > Oh, and has anyone looked at the EJB 2.1 spec? Web Service integration is > > one of the big new features. > > True - but do you trust Sun to do things well? :) > > Cheers, > Mike > > > > > > >> I am actually integrating SOAP and WebWork for JIRA at the moment - but > >> in a different manner. I'm not sure how this fits with your use cases, > >> but it requires very little modification to WebWork as it stands. > >> > >> (As a use case what we're trying to do is enable other applications to > >> talk to JIRA - for example an IDE plugin. SOAP is a natural transport > >> mechanism because it is endpoint agnostic) > >> > >> I think the idea of integrating SOAP at a low level into WW isn't such > >> a good one. I suppose you could have a SOAPAware interface that > >> contains the setSoap() method - but XML at the command level is _ugly_. > >> > >> Here's how we're planning to do it: > >> > >> The incoming SOAP request contains two pieces of information: > >> - the 'command' to carry out > >> - the 'parameters' (this is basically a map, but can be typed) > >> > >> Our receiving class (SOAPCommandProcessor) then takes this information, > >> looks up a WebWork action based on the 'command', sets the parameters > >> in the command via the 'parameters' map. > >> > >> The action is then executed. > >> > >> The SCP then checks for errors. > >> - If they occur, it returns a SOAP fault containing the error messages. > >> - If there are no messages, the success value is returned. > >> > >> The advantages of this are: > >> - I can add new commands without modifying the SOAP processing > >> architecture - I can use my existing WW commands remotely! > >> - I can bundle a number of commands into a single SOAP request, each > >> with their own parameters - effectively chaining them and reducing > >> network traffic > >> > >> (Note: here WW has nothing to do with the web - we're using WW as a > >> command pattern framework) > >> (Note2: I haven't actually done this yet - it's all in the planning > >> stages) (Note3: we're using Glue exclusively for SOAP - because it > >> rocks!) > >> > >> Thoughts? > >> > >> Cheers, > >> Mike > >> > >> On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the > >> words: > >> > >>> OK here is what I came up with in terms of some possible use cases, > >>> feel free to critique away: > >>> > >>> Use Case 1: Custom Input Processing > >>> > >>> 1. SOAP message arrives > >>> 2. setXML(???? xml) method gets called on the action with the contents > >>> of the SOAP body (not sure which format to use here, perhaps a > >>> String). > >>> 3. prepare method gets called to allow the action to parse the XML and > >>> set action properties > >>> 4. doValidate() and doExecute() get called as normal > >>> > >>> Comments: > >>> - This allows for the times when the input document needs special > >>> processing before the properties get set > >>> - Another possibility would be to have an action interface that also > >>> accepted the complete SOAP message to allow header processing as well. > >>> > >>> Use Case 2: Stylesheet Input Processing > >>> > >>> 1. SOAP message arrives > >>> 2. The appropriate stylesheet for the incoming message is selected > >>> based on the URL and run on the SOAP body. The output format produced > >>> is identical to that used by the XSLT view. This transformation could > >>> be the identity transformation if the input is already in that format. > >>> 3. The resulting XML is parsed and used to set the action properties. > >>> 4. doValidate() and doExecute() get called as normal. > >>> > >>> Use Case 3: Custom Output Processing > >>> > >>> 1. doExecute() is called on the action > >>> 2. The getXML() method on the action is called to allow it to produce > >>> the output XML in a custom fashion. > >>> 3. The resulting XML is wrapped in a SOAP message and sent back to the > >>> caller. > >>> > >>> Use Case 4: Stylesheet Output Processing > >>> 1. doExecute() is called on the action > >>> 2. The appropriate output stylesheet is selected based on the view > >>> requested > >>> 3. XML is produced from the action using the same code as for an XSLT > >>> view. > >>> 4. The stylesheet is run on the XML > >>> 5. The resulting XML is wrapped in a SOAP body and sent to the caller. > >>> > >>> Use Case 5: Error processing > >>> 1. doValidate() or doExecute() is called producing one or more error > >>> messages > >>> 2. The appropriate error output stylesheet is selected based on the > >>> view requested > >>> 3. XML is produced from the error messages using a similar format to > >>> that used by the XSLT view. > >>> 4. The stylesheet is run on the XML > >>> 5. The resulting XML is wrapped in a SOAP fault message and sent to > >>> the caller. > >>> > >>> > >>> Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: > >>> > >>> MB> I read several articles concerning REST and I agree with its > >>> conclusions on > >>> MB> RPC and yes, it would be nice to let the WW's actions still drive > >>> the MB> application and allow views produce the appropriate output. > >>> Since you guys MB> brought this up maybe you are up to putting a > >>> prototype together to see if MB> it makes sense to call webservices > >>> through a normal MVC web tier or into an > >>> MB> EJB tier directly. I guess that is the real question we are trying > >>> to MB> answer. I'll be happy to participate/critique/do nothing. What > >>> do you say? > >>> > >>> MB> -Matt > >> > >> > >> > >> ------------------------------------------------------- > >> This sf.net email is sponsored by:ThinkGeek > >> Two, two, TWO treats in one. > >> http://thinkgeek.com/sf > >> _______________________________________________ > >> Webwork-devel mailing list > >> Web...@li... > >> https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Two, two, TWO treats in one. > > http://thinkgeek.com/sf > > _______________________________________________ > > Webwork-devel mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-16 07:56:02
|
Toby, Thoughts below! On 11/7/02 12:13 PM, "Toby Hede" (tob...@in...) penned the words: > This is more or less the approach I have been looking at. Rather than > exposing Actions to SOAP messages directly, I think there is more value in > simply looking at SOAP as another messaging system. Right - I think the biggest value in this exercise (for me) is abstracting our webwork 'web' actions into more generic interfaces into our webwork 'command' actions. WebWork is a very powerful command pattern framework that should be able to be utilised anywhere IMHO. > A SOAPAware interface would indeed probably be required for completeness, > but I think in the majority of cases, it would not used by developers. Right - I wouldn't use it. > This is the basic flow as I perceive it: > > Incoming SOAP Message: method and parameters > This is a simple SOAP method call, eg: someCommand(param1, param2) > Will defaulting to a Map of parameters that are associated with an Action > require any extra work by other SOAP clients (like .Net, FlashMX and Perl)? > I think that there is some benfit in allowing standard SOAP parameters to > be passed by default. > > SoapDispatch: dispatches the method call to the processing action > Incoming parameters mapped to the corresponding Action parameters and the > Command is executed. > > One issue I see is that return values in WebWork will be limited, because > of the Action API itself. Although, I imagine that Action parameters can be > altered and returned. Right. At the moment with my WWSOAP integration project, I have a SOAPDispatcher with a few methods: - String runAction(String actionName) - String runAction(String actionName, Map parameters) - Map runAction(String actionName, Map parameters, List resultsWanted) The first two run a specified action (the second with a map of parameters) and then return it's result as a String. The last runs the action, but also returns a Map of results (of which the String result is one entry with the key 'actionresult'). The result map is created from the incoming results wanted. (eg if the resultsWanted list contains "foo", the returned map will contain "foo" as a key, and action.getFoo() as a value). This can then be plugged into _any_ webwork action! > We may need to create new Service mappings that allow an Action Command to > be associated with a SOAP request. Right - possibly. At the moment I'm just using aliases in the actions.xml, and then my SOAP client can request any action/command via its alias. This is neat! > One note: GLUE is not Open Source, so I think there is value in continuing > to look at Axis integration. Certainly - Glue is just the best SOAP framework available, and free - so we use it. But I agree that it cannot be bundled with WebWork. However I'm still not convinced that the proposed Axis integration is a good idea. > Oh, and has anyone looked at the EJB 2.1 spec? Web Service integration is > one of the big new features. True - but do you trust Sun to do things well? :) Cheers, Mike > > >> I am actually integrating SOAP and WebWork for JIRA at the moment - but >> in a different manner. I'm not sure how this fits with your use cases, >> but it requires very little modification to WebWork as it stands. >> >> (As a use case what we're trying to do is enable other applications to >> talk to JIRA - for example an IDE plugin. SOAP is a natural transport >> mechanism because it is endpoint agnostic) >> >> I think the idea of integrating SOAP at a low level into WW isn't such >> a good one. I suppose you could have a SOAPAware interface that >> contains the setSoap() method - but XML at the command level is _ugly_. >> >> Here's how we're planning to do it: >> >> The incoming SOAP request contains two pieces of information: >> - the 'command' to carry out >> - the 'parameters' (this is basically a map, but can be typed) >> >> Our receiving class (SOAPCommandProcessor) then takes this information, >> looks up a WebWork action based on the 'command', sets the parameters >> in the command via the 'parameters' map. >> >> The action is then executed. >> >> The SCP then checks for errors. >> - If they occur, it returns a SOAP fault containing the error messages. >> - If there are no messages, the success value is returned. >> >> The advantages of this are: >> - I can add new commands without modifying the SOAP processing >> architecture - I can use my existing WW commands remotely! >> - I can bundle a number of commands into a single SOAP request, each >> with their own parameters - effectively chaining them and reducing >> network traffic >> >> (Note: here WW has nothing to do with the web - we're using WW as a >> command pattern framework) >> (Note2: I haven't actually done this yet - it's all in the planning >> stages) (Note3: we're using Glue exclusively for SOAP - because it >> rocks!) >> >> Thoughts? >> >> Cheers, >> Mike >> >> On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the >> words: >> >>> OK here is what I came up with in terms of some possible use cases, >>> feel free to critique away: >>> >>> Use Case 1: Custom Input Processing >>> >>> 1. SOAP message arrives >>> 2. setXML(???? xml) method gets called on the action with the contents >>> of the SOAP body (not sure which format to use here, perhaps a >>> String). >>> 3. prepare method gets called to allow the action to parse the XML and >>> set action properties >>> 4. doValidate() and doExecute() get called as normal >>> >>> Comments: >>> - This allows for the times when the input document needs special >>> processing before the properties get set >>> - Another possibility would be to have an action interface that also >>> accepted the complete SOAP message to allow header processing as well. >>> >>> Use Case 2: Stylesheet Input Processing >>> >>> 1. SOAP message arrives >>> 2. The appropriate stylesheet for the incoming message is selected >>> based on the URL and run on the SOAP body. The output format produced >>> is identical to that used by the XSLT view. This transformation could >>> be the identity transformation if the input is already in that format. >>> 3. The resulting XML is parsed and used to set the action properties. >>> 4. doValidate() and doExecute() get called as normal. >>> >>> Use Case 3: Custom Output Processing >>> >>> 1. doExecute() is called on the action >>> 2. The getXML() method on the action is called to allow it to produce >>> the output XML in a custom fashion. >>> 3. The resulting XML is wrapped in a SOAP message and sent back to the >>> caller. >>> >>> Use Case 4: Stylesheet Output Processing >>> 1. doExecute() is called on the action >>> 2. The appropriate output stylesheet is selected based on the view >>> requested >>> 3. XML is produced from the action using the same code as for an XSLT >>> view. >>> 4. The stylesheet is run on the XML >>> 5. The resulting XML is wrapped in a SOAP body and sent to the caller. >>> >>> Use Case 5: Error processing >>> 1. doValidate() or doExecute() is called producing one or more error >>> messages >>> 2. The appropriate error output stylesheet is selected based on the >>> view requested >>> 3. XML is produced from the error messages using a similar format to >>> that used by the XSLT view. >>> 4. The stylesheet is run on the XML >>> 5. The resulting XML is wrapped in a SOAP fault message and sent to >>> the caller. >>> >>> >>> Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: >>> >>> MB> I read several articles concerning REST and I agree with its >>> conclusions on >>> MB> RPC and yes, it would be nice to let the WW's actions still drive >>> the MB> application and allow views produce the appropriate output. >>> Since you guys MB> brought this up maybe you are up to putting a >>> prototype together to see if MB> it makes sense to call webservices >>> through a normal MVC web tier or into an >>> MB> EJB tier directly. I guess that is the real question we are trying >>> to MB> answer. I'll be happy to participate/critique/do nothing. What >>> do you say? >>> >>> MB> -Matt >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Two, two, TWO treats in one. >> http://thinkgeek.com/sf >> _______________________________________________ >> Webwork-devel mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Matt B. <ma...@sm...> - 2002-07-16 00:26:51
|
Well, I think you guys are mapping out a doable solution. Take a look at this e-mail delivered to the Axis user list. I think it provides additional insight into what you guys are thinking. -Matt MVC for Web Services : mvc4ws It is a small framework for building web services applications using the MVC Model 2 (MVC2) design pattern. It will serve as a platform for exploring approaches to implementing this design pattern. Any information, remark or feedback about mvc4ws is welcome. You can download it from the following page : http://www.improve-technologies.com/alpha/mvc4ws/ ----- Original Message ----- From: "Toby Hede" <tob...@in...> To: <web...@li...> Sent: Wednesday, July 10, 2002 9:13 PM Subject: Re: [Webwork-devel] SOAP and Webwork - does it make sense > This is more or less the approach I have been looking at. Rather than > exposing Actions to SOAP messages directly, I think there is more value in > simply looking at SOAP as another messaging system. > > A SOAPAware interface would indeed probably be required for completeness, > but I think in the majority of cases, it would not used by developers. > > This is the basic flow as I perceive it: > > Incoming SOAP Message: method and parameters > This is a simple SOAP method call, eg: someCommand(param1, param2) > Will defaulting to a Map of parameters that are associated with an Action > require any extra work by other SOAP clients (like .Net, FlashMX and Perl)? > I think that there is some benfit in allowing standard SOAP parameters to > be passed by default. > > SoapDispatch: dispatches the method call to the processing action > Incoming parameters mapped to the corresponding Action parameters and the > Command is executed. > > One issue I see is that return values in WebWork will be limited, because > of the Action API itself. Although, I imagine that Action parameters can be > altered and returned. > > We may need to create new Service mappings that allow an Action Command to > be associated with a SOAP request. > > One note: GLUE is not Open Source, so I think there is value in continuing > to look at Axis integration. > > Oh, and has anyone looked at the EJB 2.1 spec? Web Service integration is > one of the big new features. > > > > > I am actually integrating SOAP and WebWork for JIRA at the moment - but > > in a different manner. I'm not sure how this fits with your use cases, > > but it requires very little modification to WebWork as it stands. > > > > (As a use case what we're trying to do is enable other applications to > > talk to JIRA - for example an IDE plugin. SOAP is a natural transport > > mechanism because it is endpoint agnostic) > > > > I think the idea of integrating SOAP at a low level into WW isn't such > > a good one. I suppose you could have a SOAPAware interface that > > contains the setSoap() method - but XML at the command level is _ugly_. > > > > Here's how we're planning to do it: > > > > The incoming SOAP request contains two pieces of information: > > - the 'command' to carry out > > - the 'parameters' (this is basically a map, but can be typed) > > > > Our receiving class (SOAPCommandProcessor) then takes this information, > > looks up a WebWork action based on the 'command', sets the parameters > > in the command via the 'parameters' map. > > > > The action is then executed. > > > > The SCP then checks for errors. > > - If they occur, it returns a SOAP fault containing the error messages. > > - If there are no messages, the success value is returned. > > > > The advantages of this are: > > - I can add new commands without modifying the SOAP processing > > architecture - I can use my existing WW commands remotely! > > - I can bundle a number of commands into a single SOAP request, each > > with their own parameters - effectively chaining them and reducing > > network traffic > > > > (Note: here WW has nothing to do with the web - we're using WW as a > > command pattern framework) > > (Note2: I haven't actually done this yet - it's all in the planning > > stages) (Note3: we're using Glue exclusively for SOAP - because it > > rocks!) > > > > Thoughts? > > > > Cheers, > > Mike > > > > On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the > > words: > > > >> OK here is what I came up with in terms of some possible use cases, > >> feel free to critique away: > >> > >> Use Case 1: Custom Input Processing > >> > >> 1. SOAP message arrives > >> 2. setXML(???? xml) method gets called on the action with the contents > >> of the SOAP body (not sure which format to use here, perhaps a > >> String). > >> 3. prepare method gets called to allow the action to parse the XML and > >> set action properties > >> 4. doValidate() and doExecute() get called as normal > >> > >> Comments: > >> - This allows for the times when the input document needs special > >> processing before the properties get set > >> - Another possibility would be to have an action interface that also > >> accepted the complete SOAP message to allow header processing as well. > >> > >> Use Case 2: Stylesheet Input Processing > >> > >> 1. SOAP message arrives > >> 2. The appropriate stylesheet for the incoming message is selected > >> based on the URL and run on the SOAP body. The output format produced > >> is identical to that used by the XSLT view. This transformation could > >> be the identity transformation if the input is already in that format. > >> 3. The resulting XML is parsed and used to set the action properties. > >> 4. doValidate() and doExecute() get called as normal. > >> > >> Use Case 3: Custom Output Processing > >> > >> 1. doExecute() is called on the action > >> 2. The getXML() method on the action is called to allow it to produce > >> the output XML in a custom fashion. > >> 3. The resulting XML is wrapped in a SOAP message and sent back to the > >> caller. > >> > >> Use Case 4: Stylesheet Output Processing > >> 1. doExecute() is called on the action > >> 2. The appropriate output stylesheet is selected based on the view > >> requested > >> 3. XML is produced from the action using the same code as for an XSLT > >> view. > >> 4. The stylesheet is run on the XML > >> 5. The resulting XML is wrapped in a SOAP body and sent to the caller. > >> > >> Use Case 5: Error processing > >> 1. doValidate() or doExecute() is called producing one or more error > >> messages > >> 2. The appropriate error output stylesheet is selected based on the > >> view requested > >> 3. XML is produced from the error messages using a similar format to > >> that used by the XSLT view. > >> 4. The stylesheet is run on the XML > >> 5. The resulting XML is wrapped in a SOAP fault message and sent to > >> the caller. > >> > >> > >> Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: > >> > >> MB> I read several articles concerning REST and I agree with its > >> conclusions on > >> MB> RPC and yes, it would be nice to let the WW's actions still drive > >> the MB> application and allow views produce the appropriate output. > >> Since you guys MB> brought this up maybe you are up to putting a > >> prototype together to see if MB> it makes sense to call webservices > >> through a normal MVC web tier or into an > >> MB> EJB tier directly. I guess that is the real question we are trying > >> to MB> answer. I'll be happy to participate/critique/do nothing. What > >> do you say? > >> > >> MB> -Matt > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Two, two, TWO treats in one. > > http://thinkgeek.com/sf > > _______________________________________________ > > Webwork-devel mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > |
|
From: Maurice P. <Ma...@Vi...> - 2002-07-15 04:29:07
|
Peter, Let's move this back to webwork-dev since we're beginning to discuss the implementation. I've left the full history tacked on so others can catch up. On Sunday, July 14, 2002, at 10:27 PM, Peter Kelley wrote: > Maurice, > > I have official sanction to work on this as part of my day job and > contribute back to WW (we use a lot of open source here) so I should > be able to make some good progress over the next few days. We should all have such jobs. :-) > What were you thinking of in terms of getting values from actions for > the report ? One idea I had was to use the expression language in the > field name. The other idea I'm toying around with is how to do the > equivalent of JSP webwork:iterator tags, either sub reports or by > writing some smarts in the data source to denormalise the structure > automatically. By the latter I mean that the structure: > > foo > bar1 > foobar1 > foobar2 > bar2 > foobar3 > foobar4 > foobar5 > bar3 > foobar6 > foobar7 > > would come out looking something like this to the iterator: > > foo bar1 foobar1 > foo bar1 foobar2 > foo bar2 foobar3 > foo bar2 foobar4 > foo bar2 foobar5 > foo bar3 foobar6 > foo bar3 foobar7 > > This of course leaves the question how would you decide which > properties to iterate over and how many levels down to go. > > What do you think ? It's interesting. I'll think more about it tomorrow. > I might have a go at putting some code together this afternoon (I'm in > Australia by the way) and see what I come up with for a data source. > Iterators may take a little longer. Take a look at what I just put into CVS and see what you think. It's rough still, but at least you can see where my thought process is heading. One thing that will be a high priority soon will be caching the compiled JasperReports for performance reasons. (or we force people to precompile before deploying which isn't convenient). It's late here and I'm going out for a night cap. Have fun at work. If I code while you sleep and you code while I sleep this will get done in no time. -Maurice P.S. Mike, I'll take the beer instead of that man-love you offered me. : -) > > Monday, July 15, 2002, 12:50:13 PM, you wrote: > > MP> Peter, > > MP> My day job has kept me very busy, but I started doing some Jasper/WW > MP> integration yesterday. I have a servlet that generates an empty PDF > as a > MP> view from Jasper right now and am in the process of creating a Jasper > MP> datasource that uses the WW value stack. > > MP> I hope to do an initial commit sometime tomorrow. That will give us > a > MP> base to work from if you're interested in working together on it. > > MP> BTW, we used Jasper on my current project by putting the Jasper code > in WW > MP> Actions and wrote the result out using a custom servlet as a view. It > MP> works well and the customer is very happy with the result. The fully > MP> integrated version I'm working on should be much easier to use and > more > MP> powerful. > > MP> I love your sig line. My personal favorite is: > > MP> A designer knows he has arrived at perfection not when there is > nothing > MP> more to add, but when there is no longer anything to take away. > MP> -Antoine de Saint-Exupery > > > MP> -Maurice > > > MP> On Sunday, July 14, 2002, at 08:01 PM, Peter Kelley wrote: > >>> Maurice, >>> >>> I notice that there is an issue assigned to you to integrate WebWork >>> with JasperReports. I was wondering how far you had progressed in >>> doing this and whether you could use some help ? We have a need to do >>> this for our current project and so I have some time available to get >>> this going. >>> >>> -- >>> >>> regards, >>> Peter Kelley >>> >>> MoveIt Pty Ltd >>> mailto:pe...@mo... >>> +61-2-9986-3510 >>> >>> "If you want to build a ship, don't drum up the men to >>> gather wood, divide the work and give orders. Instead, >>> teach them to yearn for the vast and endless sea." >>> - Saint-Exupery >>> >>> > > > -- > > regards, > Peter Kelley > > MoveIt Pty Ltd > mailto:pe...@mo... > +61-2-9986-3510 > > "If you want to build a ship, don't drum up the men to > gather wood, divide the work and give orders. Instead, > teach them to yearn for the vast and endless sea." > - Saint-Exupery > > |
|
From: Toby H. <tob...@in...> - 2002-07-11 02:13:54
|
This is more or less the approach I have been looking at. Rather than exposing Actions to SOAP messages directly, I think there is more value in simply looking at SOAP as another messaging system. A SOAPAware interface would indeed probably be required for completeness, but I think in the majority of cases, it would not used by developers. This is the basic flow as I perceive it: Incoming SOAP Message: method and parameters This is a simple SOAP method call, eg: someCommand(param1, param2) Will defaulting to a Map of parameters that are associated with an Action require any extra work by other SOAP clients (like .Net, FlashMX and Perl)? I think that there is some benfit in allowing standard SOAP parameters to be passed by default. SoapDispatch: dispatches the method call to the processing action Incoming parameters mapped to the corresponding Action parameters and the Command is executed. One issue I see is that return values in WebWork will be limited, because of the Action API itself. Although, I imagine that Action parameters can be altered and returned. We may need to create new Service mappings that allow an Action Command to be associated with a SOAP request. One note: GLUE is not Open Source, so I think there is value in continuing to look at Axis integration. Oh, and has anyone looked at the EJB 2.1 spec? Web Service integration is one of the big new features. > I am actually integrating SOAP and WebWork for JIRA at the moment - but > in a different manner. I'm not sure how this fits with your use cases, > but it requires very little modification to WebWork as it stands. > > (As a use case what we're trying to do is enable other applications to > talk to JIRA - for example an IDE plugin. SOAP is a natural transport > mechanism because it is endpoint agnostic) > > I think the idea of integrating SOAP at a low level into WW isn't such > a good one. I suppose you could have a SOAPAware interface that > contains the setSoap() method - but XML at the command level is _ugly_. > > Here's how we're planning to do it: > > The incoming SOAP request contains two pieces of information: > - the 'command' to carry out > - the 'parameters' (this is basically a map, but can be typed) > > Our receiving class (SOAPCommandProcessor) then takes this information, > looks up a WebWork action based on the 'command', sets the parameters > in the command via the 'parameters' map. > > The action is then executed. > > The SCP then checks for errors. > - If they occur, it returns a SOAP fault containing the error messages. > - If there are no messages, the success value is returned. > > The advantages of this are: > - I can add new commands without modifying the SOAP processing > architecture - I can use my existing WW commands remotely! > - I can bundle a number of commands into a single SOAP request, each > with their own parameters - effectively chaining them and reducing > network traffic > > (Note: here WW has nothing to do with the web - we're using WW as a > command pattern framework) > (Note2: I haven't actually done this yet - it's all in the planning > stages) (Note3: we're using Glue exclusively for SOAP - because it > rocks!) > > Thoughts? > > Cheers, > Mike > > On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the > words: > >> OK here is what I came up with in terms of some possible use cases, >> feel free to critique away: >> >> Use Case 1: Custom Input Processing >> >> 1. SOAP message arrives >> 2. setXML(???? xml) method gets called on the action with the contents >> of the SOAP body (not sure which format to use here, perhaps a >> String). >> 3. prepare method gets called to allow the action to parse the XML and >> set action properties >> 4. doValidate() and doExecute() get called as normal >> >> Comments: >> - This allows for the times when the input document needs special >> processing before the properties get set >> - Another possibility would be to have an action interface that also >> accepted the complete SOAP message to allow header processing as well. >> >> Use Case 2: Stylesheet Input Processing >> >> 1. SOAP message arrives >> 2. The appropriate stylesheet for the incoming message is selected >> based on the URL and run on the SOAP body. The output format produced >> is identical to that used by the XSLT view. This transformation could >> be the identity transformation if the input is already in that format. >> 3. The resulting XML is parsed and used to set the action properties. >> 4. doValidate() and doExecute() get called as normal. >> >> Use Case 3: Custom Output Processing >> >> 1. doExecute() is called on the action >> 2. The getXML() method on the action is called to allow it to produce >> the output XML in a custom fashion. >> 3. The resulting XML is wrapped in a SOAP message and sent back to the >> caller. >> >> Use Case 4: Stylesheet Output Processing >> 1. doExecute() is called on the action >> 2. The appropriate output stylesheet is selected based on the view >> requested >> 3. XML is produced from the action using the same code as for an XSLT >> view. >> 4. The stylesheet is run on the XML >> 5. The resulting XML is wrapped in a SOAP body and sent to the caller. >> >> Use Case 5: Error processing >> 1. doValidate() or doExecute() is called producing one or more error >> messages >> 2. The appropriate error output stylesheet is selected based on the >> view requested >> 3. XML is produced from the error messages using a similar format to >> that used by the XSLT view. >> 4. The stylesheet is run on the XML >> 5. The resulting XML is wrapped in a SOAP fault message and sent to >> the caller. >> >> >> Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: >> >> MB> I read several articles concerning REST and I agree with its >> conclusions on >> MB> RPC and yes, it would be nice to let the WW's actions still drive >> the MB> application and allow views produce the appropriate output. >> Since you guys MB> brought this up maybe you are up to putting a >> prototype together to see if MB> it makes sense to call webservices >> through a normal MVC web tier or into an >> MB> EJB tier directly. I guess that is the real question we are trying >> to MB> answer. I'll be happy to participate/critique/do nothing. What >> do you say? >> >> MB> -Matt > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Marc L. <dev...@lo...> - 2002-07-10 13:31:24
|
> Marc Logemann wrote: >> i want to try to document the Action API in a user-readable way like >> Matt Baldree has done it in "Chapter1 Webwork Fundamentals - Action API" >> but of course with a deeper look into it. > Not following. If he has done it, why do you want to do it again? see "but with a deeper look into it" :) perhaps my english is so bad... all i wanted to say is that i want to explain the processing of several proxies and when they do what. This together with a description of what these marker interfaces are good for. --- greetings from Marc Logemann Homebase @ www.logemann.info |
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-10 07:42:24
|
I am actually integrating SOAP and WebWork for JIRA at the moment - but in a different manner. I'm not sure how this fits with your use cases, but it requires very little modification to WebWork as it stands. (As a use case what we're trying to do is enable other applications to talk to JIRA - for example an IDE plugin. SOAP is a natural transport mechanism because it is endpoint agnostic) I think the idea of integrating SOAP at a low level into WW isn't such a good one. I suppose you could have a SOAPAware interface that contains the setSoap() method - but XML at the command level is _ugly_. Here's how we're planning to do it: The incoming SOAP request contains two pieces of information: - the 'command' to carry out - the 'parameters' (this is basically a map, but can be typed) Our receiving class (SOAPCommandProcessor) then takes this information, looks up a WebWork action based on the 'command', sets the parameters in the command via the 'parameters' map. The action is then executed. The SCP then checks for errors. - If they occur, it returns a SOAP fault containing the error messages. - If there are no messages, the success value is returned. The advantages of this are: - I can add new commands without modifying the SOAP processing architecture - I can use my existing WW commands remotely! - I can bundle a number of commands into a single SOAP request, each with their own parameters - effectively chaining them and reducing network traffic (Note: here WW has nothing to do with the web - we're using WW as a command pattern framework) (Note2: I haven't actually done this yet - it's all in the planning stages) (Note3: we're using Glue exclusively for SOAP - because it rocks!) Thoughts? Cheers, Mike On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the words: > OK here is what I came up with in terms of some possible use cases, > feel free to critique away: > > Use Case 1: Custom Input Processing > > 1. SOAP message arrives > 2. setXML(???? xml) method gets called on the action with the contents > of the SOAP body (not sure which format to use here, perhaps a > String). > 3. prepare method gets called to allow the action to parse the XML and > set action properties > 4. doValidate() and doExecute() get called as normal > > Comments: > - This allows for the times when the input document needs special > processing before the properties get set > - Another possibility would be to have an action interface that also > accepted the complete SOAP message to allow header processing as well. > > Use Case 2: Stylesheet Input Processing > > 1. SOAP message arrives > 2. The appropriate stylesheet for the incoming message is selected > based on the URL and run on the SOAP body. The output format produced > is identical to that used by the XSLT view. This transformation could > be the identity transformation if the input is already in that format. > 3. The resulting XML is parsed and used to set the action properties. > 4. doValidate() and doExecute() get called as normal. > > Use Case 3: Custom Output Processing > > 1. doExecute() is called on the action > 2. The getXML() method on the action is called to allow it to produce > the output XML in a custom fashion. > 3. The resulting XML is wrapped in a SOAP message and sent back to the > caller. > > Use Case 4: Stylesheet Output Processing > 1. doExecute() is called on the action > 2. The appropriate output stylesheet is selected based on the view > requested > 3. XML is produced from the action using the same code as for an XSLT > view. > 4. The stylesheet is run on the XML > 5. The resulting XML is wrapped in a SOAP body and sent to the caller. > > Use Case 5: Error processing > 1. doValidate() or doExecute() is called producing one or more error > messages > 2. The appropriate error output stylesheet is selected based on the view > requested > 3. XML is produced from the error messages using a similar format to > that used by the XSLT view. > 4. The stylesheet is run on the XML > 5. The resulting XML is wrapped in a SOAP fault message and sent to the > caller. > > > Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: > > MB> I read several articles concerning REST and I agree with its conclusions > on > MB> RPC and yes, it would be nice to let the WW's actions still drive the > MB> application and allow views produce the appropriate output. Since you guys > MB> brought this up maybe you are up to putting a prototype together to see if > MB> it makes sense to call webservices through a normal MVC web tier or into > an > MB> EJB tier directly. I guess that is the real question we are trying to > MB> answer. I'll be happy to participate/critique/do nothing. What do you say? > > MB> -Matt |
34982 messages has been excluded from this view by a project administrator.
