webwork-user Mailing List for WebWork (Page 4)
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-user — WebWork users mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(24) |
Dec
(194) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(70) |
Feb
(133) |
Mar
(193) |
Apr
(114) |
May
(141) |
Jun
(176) |
Jul
(334) |
Aug
(418) |
Sep
(329) |
Oct
(209) |
Nov
(296) |
Dec
(122) |
| 2002 |
Jan
(123) |
Feb
(61) |
Mar
(115) |
Apr
(149) |
May
(124) |
Jun
(69) |
Jul
(80) |
Aug
(22) |
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
|
| 2003 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Peter K. <pe...@mo...> - 2002-07-10 06:10:00
|
Moved to developer list for technical discussion. Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: MB> ----- Original Message ----- MB> From: "Toby Hede" <tob...@in...> MB> To: <web...@li...> MB> Cc: <web...@li...> MB> Sent: Wednesday, July 03, 2002 10:34 PM MB> Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense >> I have been thinking about some of these issues myself recently, and MB> actually >> wondering how to get web services into Webwork. I am (meant to be) doing >> my thesis on some aspects of web services and this stuff is rather >> important: Iam working on the modelling of web services, which requires MB> developing a >> conceptual model of web services ... (yada yada yada). >> >> Option: WebServices as RPC to EJBs >> >> It is my understanding that many EJB containers are already providing this >> typeof capability or at least planning to. I am pretty sure JBoss provides MB> a SOAP >> based transport to the EJB layer. Many of the infrastructure issues should >> therefore be resolved, albeit without much standardisation. I remember >> reading somewhere that the EJB2.1 spec is dealing with some of these >> infrastructure issues. >> MB> yes, the future spec will require SOAP support. most app servers do now. >> As noted, an unresolved issue lies in the granularity of calls being made >> to theEJB... an adaptation of the SessionFacade pattern will definitely be >> required toaggregate EJB calls. >> MB> agree >> ______ >> Option: Adapt Webwork >> >> This is my preference, based on work I have done so far*. As mentioned, >> Webwork seems to offer a fairly good basis for achieving this already. In >> thismodel, we can simply look at Web Services as an alternative to HTTP MB> Get/Post >> for accessing actions. Keep the entire Action API, but just add some MB> specific >> mappings to actions.xml to denote web services. The request comes in as a >> SOAP message, parameters are marshalled and passed to the receiving >> action. >> >> This model is useful because it allows the developer to use a variety of >> technologies under the web services (JDBC, JDO, Castor, EJB) to provide MB> the >> actual work. I am not sure that the hierarchic nature of XML is such an >> issue,because SOAP in its current incarnation really limits requests to MB> fairly >> simpleInput/Output parameters. >> >> * There is an argument raging at the moment about the definition of Web >> Services should they be RPC or document focussed. I think that the latter MB> is >> probably where things are going to end up - it is a much more useful of >> granularity and meshes neatly with the existing Web architecture (or REST MB> as >> documented by Fielding). >> 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 >> >> >> >> >> > I have been doing a lot of thinking recently about web services and >> > whether it makes sense to adapt webwork to be called by a web service. >> > After some discussion with a few people I have decided to document my >> > thoughts here and see what people think. If this belongs in the dev >> > list please let me know and I'll move the discussion over there. >> > >> > The two options we have: >> > >> > 1. Adapt webwork to work on the end of a web service by creating one or >> > more new dispatcher servlets and a SOAP view technology. >> > >> > 2. Use RPC calls to our EJB's directly. >> > >> > I'll discuss the advantages and disadvantages separately. >> > >> > Option 1 - webwork >> > ------------------ >> > Advantages >> > >> > a. Webwork is already a good implementation of the command pattern with >> > validation, processing and a generic error mechanism. This could all be >> > reused. >> > >> > b. Webwork is a document oriented interface as opposed to a procedure >> > oriented interface and as such is well suited to information that >> > arrives in document form. >> > >> > c. Using webwork would allow our current action logic to be re-used >> > with little or no modification. >> > >> > d. Webwork already has an XSLT presentation capability which would be >> > readily adaptable to creating SOAP message bodies. >> > >> > Disadvantages >> > >> > a. Webwork action arguments are presented as a fairly flat structure >> > with little hierarchy. Would it be a perversion of the architecture to >> > adapt webwork to handle hierarchical XML input documents ? >> > >> > b. Webwork would not be well suited to application interfaces that were >> > procedure driven rather than document driven. >> > >> > Option 2 - RPC >> > -------------- >> > Advantages >> > >> > a. There are some good tools available to allow the packaging of EJB >> > methods as web services with minimum effort. >> > >> > b. RPC is a natural fit for interfaces that are procedure rather than >> > document driven. >> > >> > Disadvantages >> > >> > a. Our EJB method calls are too granular to be useful as web services. >> > Another layer would have to be constructed to provide the level of >> > aggregation necessary in a web services context, a level of >> > aggregation already present in the webwork actions. >> > >> > b. Integrated security between the servlet engine and the EJB server >> > would have to be unpicked and the EJB security integrated with web >> > services. >> > >> > c. A certain amount of processing infrastructure would have to be >> > created to perform validation and error marshalling. >> > >> > -- >> > Peter Kelley >> > >> > >> > >> > ------------------------------------------------------- >> > This sf.net email is sponsored by:ThinkGeek >> > No, I will not fix your computer. >> > 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 >> No, I will not fix your computer. >> http://thinkgeek.com/sf >> _______________________________________________ >> Webwork-user mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webwork-user >> MB> ------------------------------------------------------- MB> This sf.net email is sponsored by:ThinkGeek MB> Bringing you mounds of caffeinated joy. MB> http://thinkgeek.com/sf MB> _______________________________________________ MB> Webwork-user mailing list MB> Web...@li... MB> https://lists.sourceforge.net/lists/listinfo/webwork-user -- regards, Peter Kelley MoveIt Pty Ltd "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: G.L. G. <ga...@gr...> - 2002-07-10 04:20:01
|
Still trying to figure this one out. Below is my original action where I
would compare the values of 'view' and return a view mapping pending the
value of view ...
public class Products extends ActionSupport implements ParameterAware {
private Map params;
...
public void setParameters(Map map) { this.params = map; }
public String doExecute() throws Exception {
if (view.equals("myview.a")) {
return "selectA.success";
}
else if (view.equals("myview.b")) {
return "selectB.success";
}
return "select.error";
}
Then I needed to capture the parameter from within the action (coming from
the velocity *.vm template) so I changed the class I extended from and now
have ...
public class Products extends WebWorkVelocityServlet implements
ParameterAware {
private Map params;
...
public void setParameters(Map map) { this.params = map; }
public Template handleRequest(Context context) {
HttpServletRequest request = (HttpServletRequest)
context.get(REQUEST);
HttpServletResponse response = (HttpServletResponse)
context.get(RESPONSE);
}
}
As I understand it, I now have the handleRequest() method above so that I
can get a query string parameter from the servlet now and write something
like this in the template page ...
--- *.vm file
#if ( $reqParser.getParameter("myParam").equals("this_string") )
## do something
#end
The problem is that whereas I had the execute() method from the first ex.
(extended from ActionSupport) to compare views and return a different view
pending on the value of view, I don't know how to do this (return views
pending a query string parameter in the servlet request) w/ the
WebWorkVelocityServlet.
So what I have is a query string coming from the template to the action, and
then I'll return a view mapping w/ query string parameters back to the
browser.
Any help much appreciated.
|
|
From: Toby H. <tob...@in...> - 2002-07-10 02:00:23
|
The rules will still apply. I might be way off here, but it is my understanding that implementing the SessionAware interface simply allows the ActionContext to pass in the HTTPSession Map for access. See action.factory.SessionMap, action.factory.ActionFactory > > Hello, > > > I'm curious... do the objects that are stored in the > session object within an action required to implement the > java.io.Serializable interface? I know that objects placed > in HttpSession must be, but it appears that WebWork presents > the programmer with just a plain Map. Do the rules still > apply? > > Thanks, > > Ryan LeCompte > rm...@lo... > http://www.louisiana.edu/~rml7669 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user |
|
From: Ryan L. <rm...@lo...> - 2002-07-09 23:40:20
|
Hello,
I'm curious... do the objects that are stored in the
session object within an action required to implement the
java.io.Serializable interface? I know that objects placed
in HttpSession must be, but it appears that WebWork presents
the programmer with just a plain Map. Do the rules still
apply?
Thanks,
Ryan LeCompte
rm...@lo...
http://www.louisiana.edu/~rml7669
|
|
From: Mike Cannon-B. <mi...@at...> - 2002-07-09 08:18:40
|
Ok - so if you're on this list you probably don't need convincing, but I should post it anyway :) http://radio.weblogs.com/0107789/stories/2002/07/09/whyILikeWebwork.html Enjoy. -mike -- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support |
|
From: Marc L. <dev...@lo...> - 2002-07-08 20:21:32
|
Hi, in the process of understanding your framework...here i go: in the examples i see a lot of CommandDriven implementations (HelloWorld, Login,...) but i didnt see the usage of the interface. As far as i can read from the code, the commandDriven Bean is used for calling a selfnamed method in your bean, so when you request myAction!myCommand.action or myAction.action?command=myCommand, you must have a method called doMyCommand() in your Bean to do additional things. But in the examples i dont see any doXXX (not mentioned the normal workflow doXXX methods). Am i missing something with CommandDriven, is the usage different than i described? thx for input. Sorry to bother you with question around WW, but i really wanna use it in a sophisticated way and try to give back input to the project as soon as possible. --- Marc Logemann (see him @ www.logemann.info) |
|
From: G.L. G. <ga...@gr...> - 2002-07-07 20:16:58
|
I have a clas extended from ActionSupport w/ a mapping that returns a
WebWorkVelocityServlet which is defined as ...
public class Products extends WebWorkVelocityServlet implements
ParameterAware { ...
It implements ParameterAware so that it can capture the request query string
parameters. But it's extended from WebWorkVelocityServlet so that it
contains ...
public Template handleRequest(Context context) { ...
By using this, I understand that I can write the following in my velocity
templates ...
#if ( $reqParser.getParameter("myParam").equals("this_string") )
## do something
#end
My problem is that I can't figure out how to return different mappings
because this class use to be extended from ActionSupport and I had the
execute() method to compare the incoming parameters (ParameterAware). Now
that I've made it into a WebworkVelocityServlet I don't know where to
capture the query string param and make a decision on which mapping to
return.
Any help much appreciated.
|
|
From: Rickard <ri...@dr...> - 2002-07-07 20:13:38
|
Marc Logemann wrote: > i am having quite a hard time to fully understand your ActionFactory > chaining. >=20 > Is it correct that when using defaultActionFactory, getActionImpl() of > all defined Factories (about 11 there) will be called? Yes. > Is it also correct that some factories do some pre-processing like > settings paramters from request into the bean while others > will only do their work when your Action Bean is an instance of > some Action (like PrepareAction) ? Yes. > I am wondering how my MyAction which extends ActionSupport can also > implement prepare() of the PrepareAction Interface. Since instanceof > is used, implementing the interface wont work here. Why? > Another miracle is for example XMLActionFactoryProxy, which acts upon > a certain suffix (here .xml), am i right that when using this feature, > you must also redefine your web.xml, cause .xml requests wont > handled by webwork default web.xml. No, the URL would be something like "foo.xml.action". /Rickard --=20 Rickard =D6berg |
|
From: Marc L. <dev...@lo...> - 2002-07-06 13:21:49
|
Hi, i am having quite a hard time to fully understand your ActionFactory chaining. Is it correct that when using defaultActionFactory, getActionImpl() of all defined Factories (about 11 there) will be called? Is it also correct that some factories do some pre-processing like settings paramters from request into the bean while others will only do their work when your Action Bean is an instance of some Action (like PrepareAction) ? I am wondering how my MyAction which extends ActionSupport can also implement prepare() of the PrepareAction Interface. Since instanceof is used, implementing the interface wont work here. Another miracle is for example XMLActionFactoryProxy, which acts upon a certain suffix (here .xml), am i right that when using this feature, you must also redefine your web.xml, cause .xml requests wont handled by webwork default web.xml. The code looks very clever, perhaps i am just too dumb to fully understand it in the first hour. Thx for input. --- Marc Logemann (see him @ www.logemann.info) |
|
From: Marc L. <dev...@lo...> - 2002-07-06 11:14:19
|
Hi, i am using velocity as view for webwork. There are some sentences in the docs about how to start with this combination, but IMO it could be expanded a lot. There is also some TODO paragraph at the end. If there is nothing against it, i would start to document this better as soon i read through the main classes of Webwork to really understand the action behavior. But what is the desired format for any doc contributions? I heard that docbook should be droped?? --- Marc Logemann (see him @ www.logemann.info) |
|
From: Matt B. <ma...@sm...> - 2002-07-05 20:58:58
|
----- Original Message ----- From: "Toby Hede" <tob...@in...> To: <web...@li...> Cc: <web...@li...> Sent: Wednesday, July 03, 2002 10:34 PM Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense > I have been thinking about some of these issues myself recently, and actually > wondering how to get web services into Webwork. I am (meant to be) doing > my thesis on some aspects of web services and this stuff is rather > important: Iam working on the modelling of web services, which requires developing a > conceptual model of web services ... (yada yada yada). > > Option: WebServices as RPC to EJBs > > It is my understanding that many EJB containers are already providing this > typeof capability or at least planning to. I am pretty sure JBoss provides a SOAP > based transport to the EJB layer. Many of the infrastructure issues should > therefore be resolved, albeit without much standardisation. I remember > reading somewhere that the EJB2.1 spec is dealing with some of these > infrastructure issues. > yes, the future spec will require SOAP support. most app servers do now. > As noted, an unresolved issue lies in the granularity of calls being made > to theEJB... an adaptation of the SessionFacade pattern will definitely be > required toaggregate EJB calls. > agree > ______ > Option: Adapt Webwork > > This is my preference, based on work I have done so far*. As mentioned, > Webwork seems to offer a fairly good basis for achieving this already. In > thismodel, we can simply look at Web Services as an alternative to HTTP Get/Post > for accessing actions. Keep the entire Action API, but just add some specific > mappings to actions.xml to denote web services. The request comes in as a > SOAP message, parameters are marshalled and passed to the receiving > action. > > This model is useful because it allows the developer to use a variety of > technologies under the web services (JDBC, JDO, Castor, EJB) to provide the > actual work. I am not sure that the hierarchic nature of XML is such an > issue,because SOAP in its current incarnation really limits requests to fairly > simpleInput/Output parameters. > > * There is an argument raging at the moment about the definition of Web > Services should they be RPC or document focussed. I think that the latter is > probably where things are going to end up - it is a much more useful of > granularity and meshes neatly with the existing Web architecture (or REST as > documented by Fielding). > I read several articles concerning REST and I agree with its conclusions on RPC and yes, it would be nice to let the WW's actions still drive the application and allow views produce the appropriate output. Since you guys brought this up maybe you are up to putting a prototype together to see if it makes sense to call webservices through a normal MVC web tier or into an EJB tier directly. I guess that is the real question we are trying to answer. I'll be happy to participate/critique/do nothing. What do you say? -Matt > > > > > > I have been doing a lot of thinking recently about web services and > > whether it makes sense to adapt webwork to be called by a web service. > > After some discussion with a few people I have decided to document my > > thoughts here and see what people think. If this belongs in the dev > > list please let me know and I'll move the discussion over there. > > > > The two options we have: > > > > 1. Adapt webwork to work on the end of a web service by creating one or > > more new dispatcher servlets and a SOAP view technology. > > > > 2. Use RPC calls to our EJB's directly. > > > > I'll discuss the advantages and disadvantages separately. > > > > Option 1 - webwork > > ------------------ > > Advantages > > > > a. Webwork is already a good implementation of the command pattern with > > validation, processing and a generic error mechanism. This could all be > > reused. > > > > b. Webwork is a document oriented interface as opposed to a procedure > > oriented interface and as such is well suited to information that > > arrives in document form. > > > > c. Using webwork would allow our current action logic to be re-used > > with little or no modification. > > > > d. Webwork already has an XSLT presentation capability which would be > > readily adaptable to creating SOAP message bodies. > > > > Disadvantages > > > > a. Webwork action arguments are presented as a fairly flat structure > > with little hierarchy. Would it be a perversion of the architecture to > > adapt webwork to handle hierarchical XML input documents ? > > > > b. Webwork would not be well suited to application interfaces that were > > procedure driven rather than document driven. > > > > Option 2 - RPC > > -------------- > > Advantages > > > > a. There are some good tools available to allow the packaging of EJB > > methods as web services with minimum effort. > > > > b. RPC is a natural fit for interfaces that are procedure rather than > > document driven. > > > > Disadvantages > > > > a. Our EJB method calls are too granular to be useful as web services. > > Another layer would have to be constructed to provide the level of > > aggregation necessary in a web services context, a level of > > aggregation already present in the webwork actions. > > > > b. Integrated security between the servlet engine and the EJB server > > would have to be unpicked and the EJB security integrated with web > > services. > > > > c. A certain amount of processing infrastructure would have to be > > created to perform validation and error marshalling. > > > > -- > > Peter Kelley > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > No, I will not fix your computer. > > 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 > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user > |
|
From: Matt B. <ma...@sm...> - 2002-07-05 17:45:14
|
> > >4. Begin work on leveraging the synergy of the merge. > >- IMO, I believe a key to OS is concise well-built building blocks. A > >developer can choose to use only OS-Cache, Sitemesh, WW, FormTags, > >OS-Workflow, or all of them. Abstracting out core functionality like bean > >manipulation, configuration, etc. just makes sense. With core pieces > >abstracted, you have a leaner, easier to maintain, easier to extend, easier > >for developers to comprehend, and more popular modules. This abstraction > >creates common core pieces that become rock solid because the extra review > >and use they receive. > > Agreed; formtags, for example, already has some webwork integration (I had > offered them to Rickard a long, long time ago in a galaxy far, far away) and > I'd love to see them brought up to date. > Agree. I don't see a need to multiple tags but one "kick but" set of tags! |
|
From: Matt B. <ma...@sm...> - 2002-07-05 17:44:25
|
> > 1. Does OS need 13 mailing lists? I suggest one general mail list, one > >per module, and one cvs mail list. There should be no need to cross post > >messages. If the message pertains to the group, then send it there; > >otherwise, send it to the module specific list. If traffic is light enough, > >then one general and one cvs would be fine with me. > > That's been the way of it, actually, where most lists are ignored except for > -developers, -cvs, -oscache, ans -sitemesh, I believe. > If you are really only using one list plus CVS, then I vote (if it counts yet :)) to only have two mailing lists and hide/delete the others. It confuses people. Sometimes they aren't sure where to post so they post to several. I imagine the volume of messages on the list are not too high so one list should do. |
|
From: Matt B. <ma...@sm...> - 2002-07-05 17:38:14
|
> > > 1. Does OS need 13 mailing lists? > > Yes, we hate our mailing lists, but the admin tools don't have any way to > remove them! We'll have to bug the SF people directly I suppose. We really > only want os-dev, os-users, and os-cvsmail. > You can delete them or not make them public. |
|
From: Patrick L. <pli...@ho...> - 2002-07-05 16:08:42
|
> - WW documentation will be changed to HTML and moved from DocBook. DocBook > code will be removed from source tree. I hate having to tote DocBook crap > around in the source tree. Yeah, I went with DocBook in OSCore and OSWorkflow initially, but gave up on it. Documentation should be simple enough for the developers, with the limited time we have, to be able to open up some crappy WYSIWG editor and tap away at the keyboard for a couple minutes. > 1. Does OS need 13 mailing lists? Yes, we hate our mailing lists, but the admin tools don't have any way to remove them! We'll have to bug the SF people directly I suppose. We really only want os-dev, os-users, and os-cvsmail. > 2. The news announcements seem out of sync with the home page. I know it > is a pain to keep them in sync, but I think it is important since potential > new users will first read the news announcements on SF. If you decide not to > use it, then I suggest turn it off or delete old announcements and announce > that announcements are posted on the home page. Also a good point. I'd go for deleting them and then posting a single item pointing to the new site. > 3. As a user, I don't see where to go for issue tracking. Is this on the > main web site? If so, I don't see it. Ahh!, you have to click on a product > to see the link at the bottom. That is fine, but I suggest that a brief > paragraph and link concerning issue tracking should be on the main page. At the top, "Bugs/Tasks"... but yes, the site could use some work to make it more user friendly. > - IMO, I believe a key to OS is concise well-built building blocks. A > developer can choose to use only OS-Cache, Sitemesh, WW, FormTags, > OS-Workflow, or all of them. Abstracting out core functionality like bean > manipulation, configuration, etc. just makes sense. With core pieces > abstracted, you have a leaner, easier to maintain, easier to extend, easier > for developers to comprehend, and more popular modules. This abstraction > creates common core pieces that become rock solid because the extra review > and use they receive. Very well said, that's always been a core goal with all the code and should continue to be a primary focus. > - It would be nice if the main website was redone utilizing most, if not > all, of the modules as a solid example of best practices with the modules. > Then the website itself would be a module that would be released and > available for download. Yes, the website redesign should include taking advantage of all the modules possible. It is currently also updated every hour from CVS, which is probably something we should continue doing, even after the overhaul. |
|
From: Joseph O. <ep...@ho...> - 2002-07-05 15:59:17
|
>From: "Matt Baldree" <ma...@sm...> >Great! Now what? I propose the following - >1. Migrate WW with Opensymphony. >- OS website and SF update recommendation > 1. Does OS need 13 mailing lists? I suggest one general mail list, one >per module, and one cvs mail list. There should be no need to cross post >messages. If the message pertains to the group, then send it there; >otherwise, send it to the module specific list. If traffic is light enough, >then one general and one cvs would be fine with me. That's been the way of it, actually, where most lists are ignored except for -developers, -cvs, -oscache, ans -sitemesh, I believe. > 2. The news announcements seem out of sync with the home page. I know >it >is a pain to keep them in sync, but I think it is important since potential >new users will first read the news announcements on SF. If you decide not >to >use it, then I suggest turn it off or delete old announcements and announce >that announcements are posted on the home page. Agreed. Does SF have some way for us to pull announcements from there, so we can have one source? > 3. As a user, I don't see where to go for issue tracking. Is this on >the >main web site? If so, I don't see it. Ahh!, you have to click on a product >to see the link at the bottom. That is fine, but I suggest that a brief >paragraph and link concerning issue tracking should be on the main page. Our web site sucks. It doesn't suck as much as it could - we could use flash and java applets (and activex!) on it, too, but it's not very clear. >4. Begin work on leveraging the synergy of the merge. >- IMO, I believe a key to OS is concise well-built building blocks. A >developer can choose to use only OS-Cache, Sitemesh, WW, FormTags, >OS-Workflow, or all of them. Abstracting out core functionality like bean >manipulation, configuration, etc. just makes sense. With core pieces >abstracted, you have a leaner, easier to maintain, easier to extend, easier >for developers to comprehend, and more popular modules. This abstraction >creates common core pieces that become rock solid because the extra review >and use they receive. Agreed; formtags, for example, already has some webwork integration (I had offered them to Rickard a long, long time ago in a galaxy far, far away) and I'd love to see them brought up to date. >5. Synergy work >- It would be nice if the main website was redone utilizing most, if not >all, of the modules as a solid example of best practices with the modules. >Then the website itself would be a module that would be released and >available for download. Agreed. I had done a version of the OS website using webcompass at one point myself, partly because I wanted to use core features and partly because I wanted some reorganization of information. Are there any developers who do usable web site design on a regular basis on either list who would be willing to contribute here? ----------------------------------------------- Joseph B. Ottinger jo...@en... http://enigmastation.com IT Consultant _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Matt B. <ma...@sm...> - 2002-07-05 15:37:42
|
Well, so far there seems to be a consensus to move WW under OS's umbrella.
Great! Now what? I propose the following -
1. Migrate WW with Opensymphony.
- The focus is to move the code and issue tracking to OS. I assume I would
work with Mike to make this transition happen.
- WW on SF will reference the new location. CVS and other components will be
turned off.
- WW's issue tracking on JIRA should be migrated to OS's.
- WW documentation will be changed to HTML and moved from DocBook. DocBook
code will be removed from source tree. I hate having to tote DocBook crap
around in the source tree.
- Integrate WW into OS's site.
- Migrate WW's developers to OS. Inactive developers would not be migrated.
- OS website and SF update recommendation
1. Does OS need 13 mailing lists? I suggest one general mail list, one
per module, and one cvs mail list. There should be no need to cross post
messages. If the message pertains to the group, then send it there;
otherwise, send it to the module specific list. If traffic is light enough,
then one general and one cvs would be fine with me.
2. The news announcements seem out of sync with the home page. I know it
is a pain to keep them in sync, but I think it is important since potential
new users will first read the news announcements on SF. If you decide not to
use it, then I suggest turn it off or delete old announcements and announce
that announcements are posted on the home page.
3. As a user, I don't see where to go for issue tracking. Is this on the
main web site? If so, I don't see it. Ahh!, you have to click on a product
to see the link at the bottom. That is fine, but I suggest that a brief
paragraph and link concerning issue tracking should be on the main page.
2. Announce migration.
- WW will release 1.2.
- After 1.2 release, it's time to announce WW's move. <plug>Mike should do
this.</plug>
3. Announce WW release
- This announcement will follow the migration announcement and it will be
either 1.2 or 1.3.
4. Begin work on leveraging the synergy of the merge.
- No major integration work will begin until 1.3 is released. After it is
release, a 1.3 CVS branch will be created and maintained for bug purposes.
- Integration work will be slated for 2.0 release. This work will include
leveraging synergies.
- IMO, I believe a key to OS is concise well-built building blocks. A
developer can choose to use only OS-Cache, Sitemesh, WW, FormTags,
OS-Workflow, or all of them. Abstracting out core functionality like bean
manipulation, configuration, etc. just makes sense. With core pieces
abstracted, you have a leaner, easier to maintain, easier to extend, easier
for developers to comprehend, and more popular modules. This abstraction
creates common core pieces that become rock solid because the extra review
and use they receive.
5. Synergy work
- Leverage a common infrastructure - nightly builds, build scripts,
automated tests, docs (this will be done in step 1 for web site)
- Leverage OS Core work. This includes a common bean util, configuration,
and more.
- Leverage other modules where it makes sense.
- It would be nice if the main website was redone utilizing most, if not
all, of the modules as a solid example of best practices with the modules.
Then the website itself would be a module that would be released and
available for download.
Comments on the plan?
-Matt
----- Original Message -----
From: "Joe Walnes" <jo...@tr...>
To: <web...@li...>;
<ope...@li...>
Sent: Tuesday, July 02, 2002 6:41 AM
Subject: [Webwork-user] Re: [Webwork-devel] Intergrate with OpenSymphony?
> As someone from the OpenSymphony camp and a very big fan of WebWork, you
> get my +1.
>
> Though I would like to point out that if WW is under the same umbrella as
> the other OSym tools it does not mean you have to start using them (or
> vice-versa).
>
> Oh yeah, please don't impose the com.opensymphony package namespace on
> WebWork (or in fact any rules)!
>
> Cheers,
> -Joe Walnes
>
> On Mon, 01 July 2002, ma...@sm... wrote
> > Ok. It's time to bring up a former heated subject. Back
> > in March, there was a topic concerning moving WW under
> > Opensymphony. The conclusion of the debate was just to
> > hang out and wait. Since then, a lot has changed and I
> > think it is time to bring this subject up again. I
> > think WW could benefit from the exposure, common
> > infrastructure, developers, etc.
> >
> > So, I'll start off and say +1. What do you say?
>
>
>
> -------------------------------------------------------
> 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: Matt B. <ma...@sm...> - 2002-07-04 23:09:20
|
There is an index-all.html that is one long html document. ----- Original Message ----- From: "Marc Logemann" <dev...@lo...> To: <web...@li...> Sent: Thursday, July 04, 2002 4:09 PM Subject: [Webwork-user] some notes regarding docs > Hi, > > i am just digging through your docs in order to understand WW. > While printing the docs, html-by-html page, it seems that it would > be a good idea to provide some "complete" document in pdf. Or at least > a document which you can print easily. Without navigating. > > What is your source format of the docs? I hope some kind of xml (docbook) > or something, so that it wouldnt make much work to transform to different > output format/style. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Caffeinated soap. No kidding. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user > > |
|
From: Marc L. <dev...@lo...> - 2002-07-04 22:40:19
|
Hi, perhaps some people will try to run the printed web.xml version in chapter two (velocity). But there the wrong package path for WebWorkVelocityServlet is mentioned... |
|
From: Java L. <dpj...@ho...> - 2002-07-04 21:53:00
|
Hi,
I am new to Webwork. I am writing a small test page, using JBoss 3 &
WebWork 1.1, that when it first load up, it will tell people what IP they
are coming from. In the example, it have to load a servlet first before it
can go through a request object and get the info. Is there anyway I can
display that on the initial load ... Like people would hit the site with a
default page called index.jsp. The page have no actions or anything, just a
plain home page with a login form. Any recommendation will be appreciated.
Thanks
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
From: Marc L. <dev...@lo...> - 2002-07-04 21:09:13
|
Hi, i am just digging through your docs in order to understand WW. While printing the docs, html-by-html page, it seems that it would be a good idea to provide some "complete" document in pdf. Or at least a document which you can print easily. Without navigating. What is your source format of the docs? I hope some kind of xml (docbook) or something, so that it wouldnt make much work to transform to different output format/style. |
|
From: G.L. G. <ga...@gr...> - 2002-07-04 03:37:14
|
I have a link that looks like ...
"forms.InitMyForm.action?view=3Da.oldForm"
So this calls the InitMyForm class extended from ActionSupport. The =
execute() method of this class sets up a few things, then returns =
"a.old" which is mapped in my views.properties file as ...
forms.InitMyForm.a.old=3Dvelocity.Products.action
So when my Products class defined as ...
public class Products extends ActionSupport implementsgets =
ParameterAware { ...
gets called, I get an error as follows ...
java.lang.IllegalArgumentException: The target object for property =
'view'. The target object needs to be initialized to a non-null value in =
order to set this property.
at webwork.util.BeanUtil.setProperty(BeanUtil.java:174)
at webwork.util.BeanUtil.setProperties(BeanUtil.java:124
So the problem is it's still seeing the view parameter from the initial =
link and this link is still in the URL when I was expecting =
"velocity.Products.action" in the URL. Also, "velocity.Products.action" =
doesn't have a view parameter.
Any help much appreciated.
|
|
From: Toby H. <tob...@in...> - 2002-07-04 03:34:27
|
I have been thinking about some of these issues myself recently, and actually wondering how to get web services into Webwork. I am (meant to be) doing my thesis on some aspects of web services and this stuff is rather important: Iam working on the modelling of web services, which requires developing a conceptual model of web services ... (yada yada yada). Option: WebServices as RPC to EJBs It is my understanding that many EJB containers are already providing this typeof capability or at least planning to. I am pretty sure JBoss provides a SOAP based transport to the EJB layer. Many of the infrastructure issues should therefore be resolved, albeit without much standardisation. I remember reading somewhere that the EJB2.1 spec is dealing with some of these infrastructure issues. As noted, an unresolved issue lies in the granularity of calls being made to theEJB... an adaptation of the SessionFacade pattern will definitely be required toaggregate EJB calls. ______ Option: Adapt Webwork This is my preference, based on work I have done so far*. As mentioned, Webwork seems to offer a fairly good basis for achieving this already. In thismodel, we can simply look at Web Services as an alternative to HTTP Get/Post for accessing actions. Keep the entire Action API, but just add some specific mappings to actions.xml to denote web services. The request comes in as a SOAP message, parameters are marshalled and passed to the receiving action. This model is useful because it allows the developer to use a variety of technologies under the web services (JDBC, JDO, Castor, EJB) to provide the actual work. I am not sure that the hierarchic nature of XML is such an issue,because SOAP in its current incarnation really limits requests to fairly simpleInput/Output parameters. * There is an argument raging at the moment about the definition of Web Services should they be RPC or document focussed. I think that the latter is probably where things are going to end up - it is a much more useful of granularity and meshes neatly with the existing Web architecture (or REST as documented by Fielding). > I have been doing a lot of thinking recently about web services and > whether it makes sense to adapt webwork to be called by a web service. > After some discussion with a few people I have decided to document my > thoughts here and see what people think. If this belongs in the dev > list please let me know and I'll move the discussion over there. > > The two options we have: > > 1. Adapt webwork to work on the end of a web service by creating one or > more new dispatcher servlets and a SOAP view technology. > > 2. Use RPC calls to our EJB's directly. > > I'll discuss the advantages and disadvantages separately. > > Option 1 - webwork > ------------------ > Advantages > > a. Webwork is already a good implementation of the command pattern with > validation, processing and a generic error mechanism. This could all be > reused. > > b. Webwork is a document oriented interface as opposed to a procedure > oriented interface and as such is well suited to information that > arrives in document form. > > c. Using webwork would allow our current action logic to be re-used > with little or no modification. > > d. Webwork already has an XSLT presentation capability which would be > readily adaptable to creating SOAP message bodies. > > Disadvantages > > a. Webwork action arguments are presented as a fairly flat structure > with little hierarchy. Would it be a perversion of the architecture to > adapt webwork to handle hierarchical XML input documents ? > > b. Webwork would not be well suited to application interfaces that were > procedure driven rather than document driven. > > Option 2 - RPC > -------------- > Advantages > > a. There are some good tools available to allow the packaging of EJB > methods as web services with minimum effort. > > b. RPC is a natural fit for interfaces that are procedure rather than > document driven. > > Disadvantages > > a. Our EJB method calls are too granular to be useful as web services. > Another layer would have to be constructed to provide the level of > aggregation necessary in a web services context, a level of > aggregation already present in the webwork actions. > > b. Integrated security between the servlet engine and the EJB server > would have to be unpicked and the EJB security integrated with web > services. > > c. A certain amount of processing infrastructure would have to be > created to perform validation and error marshalling. > > -- > Peter Kelley > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user |
|
From: Peter K. <yel...@ya...> - 2002-07-04 01:28:35
|
I have been doing a lot of thinking recently about web services and whether it makes sense to adapt webwork to be called by a web service. After some discussion with a few people I have decided to document my thoughts here and see what people think. If this belongs in the dev list please let me know and I'll move the discussion over there. The two options we have: 1. Adapt webwork to work on the end of a web service by creating one or more new dispatcher servlets and a SOAP view technology. 2. Use RPC calls to our EJB's directly. I'll discuss the advantages and disadvantages separately. Option 1 - webwork ------------------ Advantages a. Webwork is already a good implementation of the command pattern with validation, processing and a generic error mechanism. This could all be reused. b. Webwork is a document oriented interface as opposed to a procedure oriented interface and as such is well suited to information that arrives in document form. c. Using webwork would allow our current action logic to be re-used with little or no modification. d. Webwork already has an XSLT presentation capability which would be readily adaptable to creating SOAP message bodies. Disadvantages a. Webwork action arguments are presented as a fairly flat structure with little hierarchy. Would it be a perversion of the architecture to adapt webwork to handle hierarchical XML input documents ? b. Webwork would not be well suited to application interfaces that were procedure driven rather than document driven. Option 2 - RPC -------------- Advantages a. There are some good tools available to allow the packaging of EJB methods as web services with minimum effort. b. RPC is a natural fit for interfaces that are procedure rather than document driven. Disadvantages a. Our EJB method calls are too granular to be useful as web services. Another layer would have to be constructed to provide the level of aggregation necessary in a web services context, a level of aggregation already present in the webwork actions. b. Integrated security between the servlet engine and the EJB server would have to be unpicked and the EJB security integrated with web services. c. A certain amount of processing infrastructure would have to be created to perform validation and error marshalling. -- Peter Kelley |
|
From: <fbe...@py...> - 2002-07-02 14:10:24
|
You should look at mailing list archive for the merger discussions that took place a few months ago. Cheers, ___________________________ Francois Beauregard, b.ing. Vice-president Recherche et developpement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 fbe...@py... -----Original Message----- From: web...@li... [mailto:web...@li...]On Behalf Of Aapo Laakkonen Sent: July 2, 2002 9:59 AM To: web...@li...; ope...@li... Subject: [Webwork-user] RE: Intergrate with OpenSymphony? What side effects does this integration drag in? Currently WebWork does not have many dependencies to external 3rd party components and I think it is a good keep it as separated as possible. It makes intallation easier and WebWork is easier to understand if it does not have too many dependencies. How would this integration change things? OS has FormTags and maybe WebWork should then drop it's Taglib and focus more on HMVC architecture. Also there seems to be an interesting refactoring ahead if there are any plans to use OSCore. But for me, it's ok to integrate with OS. We already have Jira, so this sounds quite logical as a next step. Kind regards, Aapo Laakkonen ------------------------------------------------------- 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 |
3279 messages has been excluded from this view by a project administrator.
