webwork-devel — WebWork development

Re: [Webwork-devel] accessing value stack from custom servlet

[Rickard <ri...@dr...>]

Toby Hede wrote:
> I am looking at this SOAP stuff, and trying to establish my approach. C=
an
> someone please confirm that my understanding of the innards of WebWork =
is
> correct?  From my examinination of the Velocity and XSLT code:
>=20
> Map a custom servlet to a URL pattern (say *.vm)
>=20
> Map an action (INPUT/SUCCESS/ETC) to a URL corresponding to our custom
> servlet
>=20
> The custom servlet can then access the value stack using something like=
:
>=20
>   Object result =3D ValueStack.getStack(request).findValue(".");
>=20
> and process the result accordingly.

That's basically it, yes.

/Rickard

--=20
Rickard =D6berg

Re: [Webwork-devel] enhance the doc section "Action API"

[Rickard <ri...@dr...>]

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?

/Rickard

--=20
Rickard =D6berg

[Webwork-devel] SOAP and Webwork - does it make sense

[Peter K. <pe...@mo...>]

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
-- 

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

[Webwork-devel] accessing value stack from custom servlet

[Toby H. <tob...@in...>]

I am looking at this SOAP stuff, and trying to establish my approach. Can
someone please confirm that my understanding of the innards of WebWork is
correct?  From my examinination of the Velocity and XSLT code:

Map a custom servlet to a URL pattern (say *.vm)

Map an action (INPUT/SUCCESS/ETC) to a URL corresponding to our custom
servlet

The custom servlet can then access the value stack using something like:

  Object result = ValueStack.getStack(request).findValue(".");

and process the result accordingly.



----- Original Message -----
From: "Toby Hede" <tob...@in...>
To: <web...@li...>
Sent: Sunday, July 07, 2002 7:20 PM
Subject: [Webwork-devel] Re: [Webwork-user] SOAP and Webwork - does it make
sense


> An excellent suggestion. I will get moving on this ASAP, tying some Web
> Services into the MVC layer. I have downloaded Axis and will start
examining
> some of the issues.
>
>
>
>
> ----- Original Message -----
> From: "Matt Baldree" <ma...@sm...>
> To: <tob...@in...>; <web...@li...>
> Cc: <web...@li...>
> Sent: Saturday, July 06, 2002 6:58 AM
> Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense
>
>
> >
> > ----- 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 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
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> We have stuff for geeks like you.
> http://thinkgeek.com/sf
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>

Re: [Webwork-devel] velocity predefined context

[<Jim...@do...>]

The only problem would be the pain it causes those of us who have used the 
velocity contexts already. Even though our action is not RequestAware, it 
is useful to use the $req to provide debug information on the generated 
page.

I don't see that this "interferes" with the WebWork API. It simply 
augments the choices available to the developer.

jim





Marc Logemann <dev...@lo...>
Sent by: web...@li...
07/08/2002 06:08 PM

 
        To:     web...@li...
        cc: 
        Subject:        [Webwork-devel] velocity predefined context


Hi,

as WW uses the VelocityServlet as base class for its own 
WebWorkVelocityServlet
for rendering the html, i wonder if its too good to have the pre-defined
ServletRequest ($req) and ServletResponse ($res) in the velocityContext,
because this will interfere with the WW marker interfaces RequestAware and
ResponseAware. Even i like the predefined objects in context in velocity
standalone mode, i want to question them in WW-context.

In detail, even if you dont implement one of those markers, you can easily
get the full request object in the view via $req, so the designer can do 
things like
$req.getParameter("myparm") or whatever without knowledge of the 
backend-programmer
(cause he never implemented RequestAware).

This violates the "give the designer a predefined API" rule, cause the API 
is no longer
clearly defined.

So basically i am speaking of:

   protected Context createContext(javax.servlet.http.HttpServletRequest 
request,
                                   javax.servlet.http.HttpServletResponse 
response)
   {
      Context ctx = new 
WebWorkVelocityContext(ValueStack.getStack(request));
      ctx.put(REQUEST, request);
      ctx.put(RESPONSE, response);
      return ctx;
   }

its about these 2 puts....


---
Marc Logemann
(see him @ www.logemann.info)





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Oh, it's good to be a geek.
http://thinkgeek.com/sf
_______________________________________________
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel

[Webwork-devel] velocity predefined context

[Marc L. <dev...@lo...>]

Hi,

as WW uses the VelocityServlet as base class for its own WebWorkVelocityServlet
for rendering the html, i wonder if its too good to have the pre-defined
ServletRequest ($req) and ServletResponse ($res) in the velocityContext,
because this will interfere with the WW marker interfaces RequestAware and
ResponseAware. Even i like the predefined objects in context in velocity
standalone mode, i want to question them in WW-context.

In detail, even if you dont implement one of those markers, you can easily
get the full request object in the view via $req, so the designer can do things like
$req.getParameter("myparm") or whatever without knowledge of the backend-programmer
(cause he never implemented RequestAware).

This violates the "give the designer a predefined API" rule, cause the API is no longer
clearly defined.

So basically i am speaking of:

   protected Context createContext(javax.servlet.http.HttpServletRequest request,
                                   javax.servlet.http.HttpServletResponse response)
   {
      Context ctx = new WebWorkVelocityContext(ValueStack.getStack(request));
      ctx.put(REQUEST, request);
      ctx.put(RESPONSE, response);
      return ctx;
   }

its about these 2 puts....


---
Marc Logemann
(see him @ www.logemann.info)

[Webwork-devel] =?ISO-8859-1?Q?enhance_the_doc_section_=22Action_API=22?=

[Marc L. <dev...@lo...>]

Hi,

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.

1. Is this desirable to have?
2. is anyone yet working on this?
3. in which format should i write?


---
Marc Logemann
(see him @ www.logemann.info)

[Webwork-devel] Re: [Webwork-user] SOAP and Webwork - does it make sense

[Toby H. <tob...@in...>]

An excellent suggestion. I will get moving on this ASAP, tying some Web
Services into the MVC layer. I have downloaded Axis and will start examining
some of the issues.




----- Original Message -----
From: "Matt Baldree" <ma...@sm...>
To: <tob...@in...>; <web...@li...>
Cc: <web...@li...>
Sent: Saturday, July 06, 2002 6:58 AM
Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense


>
> ----- 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 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
>

[Webwork-devel] Re: [Webwork-user] SOAP and Webwork - does it make sense

[Matt B. <ma...@sm...>]

----- 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
>

[Webwork-devel] Webwork JIRA updated

[Mike Cannon-B. <mi...@at...>]

Hey all,

I've updated WebWork's JIRA install (at
http://opensource.atlassian.com/projects/webwork) to JIRA 1.3.

This means we now get:
- full text searching
- saved filters (v. useful for core developers!)
- cookie logins
- normal users can create attachments
- time tracking (not sure if we need that but I turned it on anyway)
- more that I can't remember

Enjoy!

Cheers,
Mike

-- 
ATLASSIAN - http://www.atlassian.com
Expert J2EE Software, Services and Support

[Webwork-devel] Re: [Webwork-user] SOAP and Webwork - does it make sense

[Toby H. <tob...@in...>]

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

[Webwork-devel] Bug in MultipartRequestWrapper

[Christoph K. <ki...@su...>]

Hi,

we think we found a bug in MultiPartRequestWrapper. The current version of
MultiPartRequestWrapper does not wrap parameters properly if the request is
wrapped multiple times as it occurs when using dispatcher.forward.

Attached is a patch which solves the problem and works fine for us. Could
someone take a look at it?

Thanks in advance,
Christoph

[Webwork-devel] RE: [Webwork-user] Intergrate with OpenSymphony?

[<fbe...@py...>]

Of Course +1

___________________________
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...

-----Original Message-----
From: web...@li...
[mailto:web...@li...]On Behalf Of
ma...@sm...
Sent: July 1, 2002 5:18 PM
To: web...@li...;
web...@li...
Subject: [Webwork-user] Intergrate with OpenSymphony?


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?

-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

Re: [Webwork-user] Re: [Webwork-devel] Intergrate with OpenSymphony?

[Patrick L. <pli...@ho...>]

+1 from me (not that I count from the WebWork side... hehe). I spent the
last week learning the WebWork codebase while trying to beat Matt to the
punch in getting getAsText support as well as array support. After taking a
hard look at the code, I see tons of places where WW and OS could work
together. One of the issues brought up last March was the perceived
inactivity of OS. Well, I think that can't be an issue anymore, since we've
had 3 big releases in the last few weeks and had a record month in terms of
website hits and downloads. We also re-structured our website to make it
very easy for the development team to post news and keep the content fresh.
Overall, I think now that 1.2 is out, it's a great time to make the move.

-Pat
----- Original Message -----
From: "Rickard" <ri...@dr...>
To: <ma...@sm...>
Cc: <web...@li...>;
<web...@li...>
Sent: Tuesday, July 02, 2002 6:01 AM
Subject: [Webwork-user] Re: [Webwork-devel] Intergrate with OpenSymphony?


> 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?
>
> I'm all for it. +1.
>
> /Rickard
>
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Webwork-devel] Intergrate with OpenSymphony?

[Rickard <ri...@dr...>]

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?

I'm all for it. +1.

/Rickard

Re: [Webwork-devel] Intergrate with OpenSymphony?

[<ma...@sm...>]

Of course, this assuming they still want us ;-).

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?
> 
> -Matt
> 
> 
>
-------------------------------------------------------
> 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

[Webwork-devel] Intergrate with OpenSymphony?

[<ma...@sm...>]

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?

-Matt

[Webwork-devel] 1.2 release

[<ma...@sm...>]

Ok. I think WW is about ready for another release. This
release includes the following new features/changes.
Any objections? 

For 1.3, I think we should include dreamweaver
integration and form centralized validation. Any others
I'm missing?

- Action Chaining - Added the ability to chain actions

- XHTML tags - Renamed our standard UI tags from
standard to xhtml and made them XHTML compliant

- CSS tags - Removed our CSS UI tags

- VXML tags - Moved our VXML UI tags directory location
from standard/vxml to vxml

- Modified Iterator, Subset Iterator, Sort Iterator and
Generator tags do not return exceptions if values are
null. It will be treated as an empty iterator set.

- By default, WW will load its standard prefixes
automatically. This includes webwork.action.standard
and webwork.action.test. You do not have to add these
if you add the webwork prefix property
to add your custom prefixes.

- Added the capability for you to define getAsText() in
property editors that extend WW's
ValidationEditorSupport. However, this will only work
if you register your editor. To make WW work
with property editors defined in BeanInfo, the value
stack return results will need to be refactored to
return the bean the value came from. But, if you to
register and editor, WW will use it.
This means JSP tags that try and represent a string
value of your object will call getAsText() to
return the appropriate l&f. By default, toString() is
used unless you override it to define custom formatting.

- Added primitive and object arrays support. This means
you can have Action attributes that are
primitive arrays or object arrays and WW will convert
them for you. See BeanUtil test for more details.

-Matt

[Webwork-devel] Re: webcoon

[Sven K. <sv...@im...>]

Takashi Sasagawa wrote:

> How is the status of "webcoon"? Is there any plan to merge to MAIN?
> I tried that and it was very interesting.
> 
> I am curious about that.

At the moment, the work on webcoon was halted waiting for C2's 
InputModule concept. It seems like the C2 folks just finished this. As 
time permits, I'll look how webcoon can benefit from it.

Side note: There is another upcoming feature in C2 which looks very 
promising. Simply speaking, it's a JavaScript driven view mapping. Using 
such a technology could reduce the verbosity of view mappings while at 
the same time improve its readability. Feature has yet to stand the 
reality check, of course.

As for the inclusion of webcoon in the main dist, I think it's a too 
large for that. If there proves to be a market for it, one could add it 
as separate dist on SourceForge's download area someday.

	Sven....

[Webwork-devel] webcoon

[Takashi S. <t-s...@wi...>]

Hi

How is the status of "webcoon"? Is there any plan to merge to MAIN?
I tried that and it was very interesting.

I am curious about that.

thanks

Takashi Sasagawa

Re: [Webwork-devel] Possible memory leakage in Tag

[Matt B. <ma...@sm...>]

Fixed. thx.

-Matt

----- Original Message -----
From: "Heng Sin Low" <low...@ya...>
To: "Webwork" <web...@li...>
Sent: Wednesday, June 19, 2002 4:20 AM
Subject: [Webwork-devel] Possible memory leakage in Tag


> In the latest cvs source, for both WebWorkTagSupport
> and WebWorkBodyTagSupport, ValueStack is cache and
> only set to null in the setPageContext and setParent
> method ( previously in release() method ). I think
> this could cause  memory leakage issue as tag instance
> may be cache in a pool and not destroy until the
> server is shutdown!
>
> Regards,
> Low
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> --------------------------------------------------------------------------
--
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>

Re: [Webwork-devel] Bug in Subset tag?

[Matt B. <ma...@sm...>]

Fixed SubSet as well as Generator, Sort, and Iterator tags. If the value is
null, they will log a warning but return false to hasNext().

----- Original Message -----
From: "Mike Cannon-Brookes" <mi...@at...>
To: <web...@li...>
Sent: Sunday, June 23, 2002 5:45 AM
Subject: [Webwork-devel] Bug in Subset tag?


> At the moment the subset tag throws an IllegalArgumentException if you try
> to get a subset of a parameter with value null.
>
> IMHO it should operate like the iterator tag and just return no result?
(ie
> ignore the null nicely and quietly like all other tags in ww)
>
> Is this a bug? Any reason why the current one throws IAE?
>
> Cheers,
> Mike
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>

[Webwork-devel] Bug in Subset tag?

[Mike Cannon-B. <mi...@at...>]

At the moment the subset tag throws an IllegalArgumentException if you try
to get a subset of a parameter with value null.

IMHO it should operate like the iterator tag and just return no result? (ie
ignore the null nicely and quietly like all other tags in ww)

Is this a bug? Any reason why the current one throws IAE?

Cheers,
Mike

[Webwork-devel] WebWork and Sitemesh on WLS 7

[Dion A. <di...@al...>]

Hi guys -

I am running into this problem running code that uses webwork and
sitemesh on WLS 7.x. 

I have a simple war file that shows the problem. 
With a decorator I get an empty page, if I bypass it, all works fine. 
To break things I just have a simple action that uses an iterator: 

<webwork:action name="'test'"> 
<webwork:bean name="'webwork.util.Sorter'" id="sorter"/> 
<webwork:sort source="list" comparator="@sorter/descending"> 
<webwork:iterator> 
whee 
</webwork:iterator> 
</webwork:sort> 
</webwork:action> 

To see the sample war file: http://www.almaer.com/wls7bug.war 

To test: http://localhost:7001/wls7bug/index.jsp [will not work] 
http://localhost:7001/wls7bug/nodecorator.jsp [will work] 

Has anyone found away to get around this problem?
BEA said they had a patch, but that didn't fix this particular problem.
Any ideas would be great.  Thanks for the great framework.

Cheers, 

Dion 

--
         \\|//
         (o o)
+----oOOo-(_)-oOOo---------------------------------------------------+
|   di...@mi...   |   TheServerSide J2EE Community   |
|   www.middleware-company.com    |      www.theserverside.com       |
+--------------------------------------------------------------------+

Re: [Webwork-devel] Possible memory leakage in Tag

[<ma...@sm...>]

Ok. I'll take a look at this. 

thx.

On Wed, 19 June 2002, Heng Sin Low wrote

> 
> In the latest cvs source, for both WebWorkTagSupport
> and WebWorkBodyTagSupport, ValueStack is cache and
> only set to null in the setPageContext and setParent
> method ( previously in release() method ). I think
> this could cause  memory leakage issue as tag instance
> may be cache in a pool and not destroy until the
> server is shutdown!
> 
> Regards,
> Low
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
>
----------------------------------------------------------------------------
>                    Bringing you mounds of caffeinated
joy
>                    >>>     http://thinkgeek.com/sf   
<<<
> 
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
>
https://lists.sourceforge.net/lists/listinfo/webwork-devel